Multiple ID instances

More curiosity than a real problem, but...

I've been abusing HTML ID attributes slightly.

..box {
margin: 10px;
}

#red {
background-color: #ff0000;
}

#green {
background-color: #00ff00;
}

<div class="box" id="red"></div>
<div class="box" id="green"></div>
<div class="box" id="red"></div>

To get a red box followed by a green box and another red box.

HTML validators complain because id attributes are supposed to be unique,
but the big three browser engines let me get away with it.

What's the "right" way to do this? Should I just have boxred and boxgreen
classes? That seems a little wasteful when I only want to change one
property.

qwe <_12Rounds (AT) yahoo (DOT) com> wrote:

I've been abusing HTML ID attributes slightly.

.box {
margin: 10px;
}

#red {
background-color: #ff0000;
}

#green {
background-color: #00ff00;
}

div class="box" id="red"></div
div class="box" id="green"></div
div class="box" id="red"></div

To get a red box followed by a green box and another red box.

HTML validators complain because id attributes are supposed to be unique,
but the big three browser engines let me get away with it.

They let you get away with all sorts of things, but will they continue
to do so in the next version?

What's the "right" way to do this? Should I just have boxred and boxgreen
classes? That seems a little wasteful when I only want to change one
property.

Change red and green to classes and apply multiple classes to the
divs. Some older browsers will not apply either class.

<div class="box red"></div>
<div class="box green"></div>
<div class="box red"></div>

Or use classes as you suggest but give the shared and differeing
properties in different styles e.g.

..boxred, .boxgreen { margin: 10px; }
..boxred { background-color: #ff0000; }
..boxgreen { background-color: #00ff00; }

Or set the background-color of .box to red and just have #green
override it in the one exception.
<div class="box"></div>
<div class="box" id="green"></div>
<div class="box"></div>

The best solution will depend on you actual situation rather than on
the simplified examples being used here.

BTW you should always set a color when you set a background-color.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve (AT) pugh (DOT) net> <http://steve.pugh.net/>

On Tue, 05 Aug 2003 07:52:05 +0100, Steve Pugh <steve (AT) pugh (DOT) net> wrote:

They let you get away with all sorts of things, but will they continue
to do so in the next version?

Yes; as long as there is competition in the market, the browser that is
least strict will have an edge.

.boxred, .boxgreen { margin: 10px; }
.boxred { background-color: #ff0000; }
.boxgreen { background-color: #00ff00; }

I think that's exactly what I was looking for... thanks. The other examples
were useful too.

qwe <_12Rounds (AT) yahoo (DOT) com> wrote:

.box {
margin: 10px;
}

#red {
background-color: #ff0000;
}

#green {
background-color: #00ff00;
}

div class="box" id="red"></div
div class="box" id="green"></div
div class="box" id="red"></div

To get a red box followed by a green box and another red box.

HTML validators complain because id attributes are supposed to be unique,
but the big three browser engines let me get away with it.

What's the "right" way to do this? Should I just have boxred and boxgreen
classes? That seems a little wasteful when I only want to change one
property.

..box{margin:10px}
..red{background-color:#ff0000}
..green{background-color:#00ff00}

<div class="box red"></div>
<div class="box green"></div>
<div class="box red"></div>


Headless

--
Email and filter list: http://www.headless.dna.ie/usenet.htm

qwe <_12Rounds (AT) yahoo (DOT) com> writes:

On Tue, 05 Aug 2003 07:52:05 +0100, Steve Pugh <steve (AT) pugh (DOT) net> wrote:
They let you get away with all sorts of things, but will they continue
to do so in the next version?

Yes; as long as there is competition in the market, the browser that is
least strict will have an edge.

Yes, but which edge? Guessing the meaning of invalid code *wrongly*
isn't going to do much for their reputation as a reliable UA.

--
Chris

On Tue, Aug 5, Chris Morris inscribed on the eternal scroll:

Yes, but which edge? Guessing the meaning of invalid code *wrongly*
isn't going to do much for their reputation as a reliable UA.

The problem here is that the kind of author who relies on browser
guessing will optimise their page for the browser that does the most
guessing (YKWIM), and then complain about all the others being
"wrong".

--
"In the hardest of cases, I show them the W3C membership list: as
soon as the customer sees that MS is a member, then everything the
W3C says is good, and typically they even demand conformance with
W3C written into the contract" - (Matthias Esken, freely translated)

qwe <_12Rounds (AT) yahoo (DOT) com> writes:

On Tue, 5 Aug 2003 08:01:05 +0000 (UTC), "Jukka K. Korpela"
jkorpela (AT) cs (DOT) tut.fi> wrote:
Really? Meanwhile on Earth, the versions of the most popular browsers have
been getting _stricter_ in the last few years, both as regards to HTML and

Yeah, I thought that would get a bite.

Look at it like this. You're an end-user. Browser A renders your favourite
site perfectly, Browser B shows you a blank page. Which browser will you
use?

Given that I switch browser based on what machine I'm currently using,
I'd probably never have chosen it as a favourite site.

(Example off the top of my head: Netscape 4 is really picky about </td
tags. Mozilla 1 will correctly render the page if you ignore them.)

table border="1"
tr><td>1<td>3<tr><td>2<td>4
/table

http://www.w3.org/TR/html401/struct/....html#h-11.2.5

End tags for <td> and <tr> are optional in HTML 4. Netscape 4 ignores
the spec and goes wrong, Mozilla 1 follows the spec and gets it right.

Your point?

--
Chris

qwe wrote:

HTML validators complain because id attributes are supposed to be unique,
but the big three browser engines let me get away with it.

What's the "right" way to do this? Should I just have boxred and boxgreen
classes? That seems a little wasteful when I only want to change one
property.

Elements can have multiple classes.

class="box red"

Which would match .red { } AND .box { }

--
David Dorward http://david.us-lot.org/
Which is stupider: Pop-up ads claiming they'll stop spam, or spam claiming
it'll stop pop-up ads? -- Dork Tower

On 05 Aug 2003 12:15:30 +0100, Chris Morris <c.i.morris (AT) durham (DOT) ac.uk> wrote:

Obviously they're both required in XHTML 1.0, but since Netscape 4
predates XHTML this comparison is beginning to get silly.

Yup.

Sending it as text/html it isn't surprising it treats it as HTML, most
browsers not going to the trouble of downloading (or otherwise
obtaining) the DTD and performing a validation before displaying the
page.

Interesting. I suppose there are no hard and fast rules about what to do
when the content-type and doctype disagree, because they're in seperate
specs.

There is a principle of 'be conservative in what you send, be liberal
in what you accept', but the problem is that if you're the wrong

I was thinking of the law of least surprise, but that fits too.

liberal things get even worse than if you'd rejected it initially.

Unless you hold 90% of the market, of course... then you become a de facto
standard.

The rest snipped because I think you've proved your points pretty
succesfully.

qwe <_12Rounds (AT) yahoo (DOT) com> writes:

On 05 Aug 2003 12:15:30 +0100, Chris Morris <c.i.morris (AT) durham (DOT) ac.uk> wrote:
Sending it as text/html it isn't surprising it treats it as HTML, most
browsers not going to the trouble of downloading (or otherwise
obtaining) the DTD and performing a validation before displaying the
page.

Interesting. I suppose there are no hard and fast rules about what to do
when the content-type and doctype disagree, because they're in seperate
specs.

Try Content-type: text/plain for an example.

Any standards-compliant browser will go for the content type and if
the text document sent happens to contain a doctype and some HTML
elements, so what. The HTTP rules say content-type headers are the
ones to go for in determining what the document is.

Any horribly broken operating system component will go for the fact
that it 'looks a bit like a HTML document' over the content type, and
all sorts of things can go interestingly wrong, of course.

--
Chris