HTML/XHTML and tag attributes

[Christopher Benson-Manica]

(if this isn't the place for XHTML, I'd appreciate a redirect)

According to the w3's web site, some non-HTML 4 browsers won't
properly interpret non-minimized boolean attributes, i.e.

<option value="blah" selected="selec ted">...</option>
^^^^^^^^^^^

Can anyone tell me what browsers those might be? I'm in the process
of converting some marginal HTML to something resembling XHTML, and
I'd like to maintain compatibility with a reasonable set of browsers.

And as long as I'm blithering about XHTML, to what extent do you think
use of the deprecated (HTML 4) and nonstandard (XHTML 1.0) <font> tag
is acceptable? We're not shooting for strict XHTML compliance here,
and <font> is a lot easier than XHTML's inline styles...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Peter Foti]

"Christophe r Benson-Manica" <at***@nospam.c yberspace.org> wrote in message
news:bp******** **@chessie.cirr .com...

Hm... well, as I've alluded, the vast majority of this code wasn't
written by me, and in defense of the people who did (i.e., the people
I work for), it was written several years ago, when this stuff might
still have been (marginally?) acceptable...

That's certainly understandable. I recently had the misfortune of updating
a site I had done a few years back when CSS was not widely supported by
browsers. It worked, but it was so cluttered. :)

Did you understand what I was saying though about why it's a bad thing to
create classes like "red"?

Regards,
Peter

[Christopher Benson-Manica]

Peter Foti <pe****@systoli cnetworks.com> spoke thus:

That's certainly understandable. I recently had the misfortune of updating
a site I had done a few years back when CSS was not widely supported by
browsers. It worked, but it was so cluttered. :)
Hm. CSS is okay for pretty much all browsers around these days
though, right? I think we officially support IE 4 and Netscape 4,
maybe a little lower than that...
Did you understand what I was saying though about why it's a bad thing to
create classes like "red"?

Yes, I appreciate that :) Although there are some instances where it
almost isn't worth the trouble for a whole CSS class, like in one
place where the code is <font size=-1> - is that worth a class...?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Bertilo Wennergren]

Christopher Benson-Manica:

So what's the best way to replace instances of <font color="red">red </font>

It all dependas on the _reason_ that text should be red. If it's because
that text is somehow emphazised, then this is the best solution:

<em>red</em>

With something like this in an external style sheet:

em { color: red; background: inherit; }

If you only want some of your "em"s to be red, do this:

<em class="whatever ">red</em>

With something like <this in an external style sheet:

em.whatever { color: red; background: inherit; }

If you later change your mind, and find that all those emphasized words
of the "whatever" kind, really should be blue, you just change in your
external style sheet:

em.whatever { color: blue; background: inherit; }

If all those words are not emphasized, and if there is no other HTML
element that correctly describes what they are, then use the element "span":

<span>red</span>

With something like this in an external style sheet:

span { color: red; background: inherit; }

Or:

<span class="whatever ">red</span>

With something like this in an external style sheet:

span.whatever { color: red; background: inherit; }

--
Bertilo Wennergren <be******@gmx.n et> <http://www.bertilow.co m>

[Peter Foti]

"Christophe r Benson-Manica" <at***@nospam.c yberspace.org> wrote in message
news:bp******** **@chessie.cirr .com...

Peter Foti <pe****@systoli cnetworks.com> spoke thus:

That's certainly understandable. I recently had the misfortune of updating a site I had done a few years back when CSS was not widely supported by
browsers. It worked, but it was so cluttered. :)

Hm. CSS is okay for pretty much all browsers around these days
though, right? I think we officially support IE 4 and Netscape 4,
maybe a little lower than that...

NS4 is quite obsolete. My recommendation would be to hide CSS from NS4
because it's implementation is so screwy. Thus, you would let the content
degrade gracefully for a NS4 browser... the content would still be
available, but it wouldn't be beautified by CSS.

Did you understand what I was saying though about why it's a bad thing to create classes like "red"?

Yes, I appreciate that :) Although there are some instances where it
almost isn't worth the trouble for a whole CSS class, like in one
place where the code is <font size=-1> - is that worth a class...?

Any place where you are controlling the presentation is worth handling with
CSS. For instance, maybe you had:
<font size=-1>Copyright (c) My Makebelieve Company</font>

Instead, you could do:
<span class="copyrigh t">Copyright (c) My Makebelieve Company</span>

And then control the display with CSS. Now if you decided that you wanted
to change the font size of your copyright, you don't need to modify every
single HTML page that has the copyright info on it... instead, you just make
the change in 1 place (the CSS file).

Regards,
Peter

[Alan J. Flavell]

On Thu, 20 Nov 2003, Christopher Benson-Manica wrote:

Peter Foti <pe****@systoli cnetworks.com> spoke thus:

Did you understand what I was saying though about why it's a bad thing to
create classes like "red"?
Yes, I appreciate that :)

Let's see...
Although there are some instances where it
almost isn't worth the trouble for a whole CSS class, like in one
place where the code is <font size=-1> - is that worth a class...?

No, it seems you didn't.

What does <font size="-1"> mean to a speaking browser? To an indexing
robot?

HTML doesn't have <aside> or <incidentally > or <by-the-way> tags, but
at least you could meet it half way with <small class="incident ally">
linked (if you want) to an audio stylesheet suggesting a different
voice.

[Eric Bohlman]

Christopher Benson-Manica <at***@nospam.c yberspace.org> wrote in
news:bp******** **@chessie.cirr .com:

(if this isn't the place for XHTML, I'd appreciate a redirect)
This is the appropriate place.
And as long as I'm blithering about XHTML, to what extent do you think
use of the deprecated (HTML 4) and nonstandard (XHTML 1.0) <font> tag
is acceptable?
IMHO, to no extent.
We're not shooting for strict XHTML compliance here,
and <font> is a lot easier than XHTML's inline styles...

Not really. It will *seem* to be easier if you don't yet understand CSS,
but once you understand CSS, <font> will actually seem a lot harder. The
big problem with <font> is that it scatters font-size and font-family
decisions all over your site, whereas CSS lets you put them all in one
place.

You're right that inline styles are awkward, but then they're generally the
worst way to do author-written styling (IMHO, inline styles should be used
only for script-driven dynamic styling). But once you learn how to gather
presentational directives into one (or maybe a few for large sites)
stylesheet(s), you'll wonder how you ever managed to cope with having
styling information distributed all over lots of individual documents.
You'll find yourself doing a lot more styling experiments once you learn
how to change every page in your site by changing a few lines in a single
file, and that will ultimately result in better design because the cost (in
time and effort) of improving your design will be so low.

[Bertilo Wennergren]

Alan J. Flavell:

HTML doesn't have <aside> or <incidentally > or <by-the-way> tags, but
at least you could meet it half way with <small class="incident ally">
linked (if you want) to an audio stylesheet suggesting a different
voice.

Are there any user agents of programs around that are able to find any
meaning in 'class"incident ally"'? Actually it's just as meaningless as
"<font>". Using "class" is still better practice, but we shouldn't fool
ourselves that it conveys any meaning, except perhaps to a human that
has a look at the HTML code.

--
Bertilo Wennergren <be******@gmx.n et> <http://www.bertilow.co m>

[Philipp Lenssen]

Bertilo Wennergren wrote:

Alan J. Flavell:

HTML doesn't have <aside> or <incidentally > or <by-the-way> tags,
but at least you could meet it half way with <small
class="incident ally"> linked (if you want) to an audio stylesheet
suggesting a different voice.

Are there any user agents of programs around that are able to find
any meaning in 'class"incident ally"'? Actually it's just as
meaningless as "<font>". Using "class" is still better practice, but
we shouldn't fool ourselves that it conveys any meaning, except
perhaps to a human that has a look at the HTML code.

Which is also a problem when it comes to the concept of
user-stylesheets. And why they won't really ever work except for the
most basic h1, h2, p, etc., which is just not enough to mark-up a
richly formatted site.

It would be nice if there would at least be tags or a class-standard
for the most-needed types of structure, like footnote, navigation, tip,
toc, note, warning, announcement, moreInfo, or whatever you may call
those*. Even I myself when working with my own stylesheets sometimes
can't remember what I called this or that class (because there are
thousands of pages out there created at different times etc.).

On the other hand HTML includes some phrase-elements which I rarely or
never use, such as samp, kbd, var, code, and so on. It seems a bit like
those were created from the point-of-view of writing technical
tutorials. On the other hand, for really basic mark-up there should be
less elements rather than more. (I could really give up on samp etc.,
though I sometimes use them.) And then there's the unnecessary
"acronym" (which is needed pretty much only for IExplorer 'cause it
doesn't understand "abbr")...

*<http://groups.google.com/groups?selm...41%40news.t-on
line.com&oe=UTF-8&output=gplain >

[Christopher Benson-Manica]

Peter Foti <pe****@systoli cnetworks.com> spoke thus:

NS4 is quite obsolete. My recommendation would be to hide CSS from NS4
because it's implementation is so screwy. Thus, you would let the content
degrade gracefully for a NS4 browser... the content would still be
available, but it wouldn't be beautified by CSS.
(un)Fortunately , the HTML in question is actually being generated by
CGI's, so I can actually use the <font> tag for NS4 and a stylesheet
for IE4+ and NS6 without issue (right?).

As far as obsolescence is concerned, it could be worse - for awhile we
had people using IE 3 (courtesy of WebTV or something)... *that* was
unpleasant ;)
Any place where you are controlling the presentation is worth handling with
CSS. For instance, maybe you had:
<font size=-1>Copyright (c) My Makebelieve Company</font>
Unfortunately not - these are all just random places where we
basically said "Hey, these two words need to be smaller than the
others." So each page touched by my tainted hand will have its own
<style> tag...
And then control the display with CSS. Now if you decided that you wanted
to change the font size of your copyright, you don't need to modify every
single HTML page that has the copyright info on it... instead, you just make
the change in 1 place (the CSS file).

As lovely as that sounds, I don't have the luxury...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Alan J. Flavell]

On Fri, 21 Nov 2003, Bertilo Wennergren wrote:

Alan J. Flavell:

HTML doesn't have <aside> or <incidentally > or <by-the-way> tags, but
at least you could meet it half way with <small class="incident ally">
linked (if you want) to an audio stylesheet suggesting a different
voice.
Are there any user agents of programs around that are able to find any
meaning in 'class"incident ally"'?

No: it's a human-meaningful token for tying the stylesheet to the
HTML.

I'm sorry if I didn't make my meaning clear in that regard.
Actually it's just as meaningless as "<font>".
Mark-up doesn't care what the content means, either. But an author or
sub-editor can make good use of human-meaningful linkages IMHO.
Using "class" is still better practice, but we shouldn't fool
ourselves that it conveys any meaning, except perhaps to a human that
has a look at the HTML code.

I've no argument there, but would it _really_ be better for humans if
all the class names were meaningless gibberish? We shouldn't fool
ourselves that human-meaningful class names are of significance to the
program - that's your point - but don't knock the idea of them being
human-meaningful. A lot better than class="smallgre enverdana" anyway.