Multiple ID instances

[qwe]

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.

[Steve Pugh]

qwe <_1*******@yaho o.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 <st***@pugh.net > <http://steve.pugh.net/>

[qwe]

On Tue, 05 Aug 2003 07:52:05 +0100, Steve Pugh <st***@pugh.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.

[Headless]

qwe <_1*******@yaho o.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:10 px}
..red{backgroun d-color:#ff0000}
..green{backgro und-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

[Chris Morris]

qwe <_1*******@yaho o.com> writes:

On Tue, 05 Aug 2003 07:52:05 +0100, Steve Pugh <st***@pugh.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

[Alan J. Flavell]

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)

[Chris Morris]

qwe <_1*******@yaho o.com> writes:

On Tue, 5 Aug 2003 08:01:05 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tu t.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

[David Dorward]

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

[Chris Morris]

qwe <_1*******@yaho o.com> writes:

On 05 Aug 2003 10:47:13 +0100, in comp.infosystem s.www.authoring.stylesheets
you wrote:

qwe <_1*******@yaho o.com> writes:

(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.)

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.

Hmm... you could be right. What about XHTML 1.0? I was under the impression

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

To bring things slightly back on topic with stylesheets, closing all
non-empty elements is very good to avoid Netscape 4 CSS confusion.
it was an XML application, though I confess I didn't test Mozilla's reaction
with the correct doctype in place. One moment...
XML Parsing Error: mismatched tag. Expected: </td>.
Location: http://dinopsis/~cim/xhtmltest
Line Number 9, Column 8:
</table>
-------^

Of course, that was sending it with the application/xhtml+xml content-type.

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.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<body>
<table border="1">
<tr><td>1<td> 3
<tr><td>2<td> 4
</table>
</body>
</html>

renders as (un?)expected in Mozilla 1.3, IE 6.02 and Opera 7.0, all on Win.
Sent as application/xhtml+xml, IE offered to save
it to disk, and Opera did something similar to Mozilla (except the
error report was a little more helpful).
Possibly I'm missing a "be really anal" switch in one or another of them,
but even if it exists then it's off by default and my point still stands -
browser vendors place "what the author meant to say" over "what the author
really said".
TelepathicML, excellent. It's when they get it wrong that the
problems come in. (previous comments about a certain application
'training' authors for its bugs accepted, though)
Now I come to think about it, that may even be the Right Thing
from a usability POV - hmm.
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
liberal things get even worse than if you'd rejected it initially.
I just don't see a time when a major browser will refuse to render <br> or
<hr> in an XHTML doc.

XML Parsing Error: mismatched tag. Expected: </br>.
Location: http://dinopsis/~cim/xhtmltest
Line Number 9, Column 3:

The future is now?

--
Chris

[qwe]

On 05 Aug 2003 12:15:30 +0100, Chris Morris <c.********@dur ham.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.