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="selected">...</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)cyberspace.org | don't, I need to know. Flames welcome.

[Dean Tiegs]

Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

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

You seem to have the common misconception that XHTML 1.0 has fewer
elements and attributes than HTML 4.01. In fact, the two are
identical except for the syntax details. Each has two subsets
(neglecting frames):

HTML 4.01 Transitional XHTML 1.0 Transitional
HTML 4.01 Strict XHTML 1.0 Strict

The "font" element exists and is deprecated in both Transitionals, and
does not exist in either Strict.

There is no legitimate reason in 2003 to use the "font" element, and
very few legitimate reasons to use the "style" attribute. Use an
external CSS style sheet. Once you have gone through the rather small
effort to learn CSS, you will see how much easier it is than the
alternatives.

Now for XHTML. If you serve XHTML with the right MIME type, very few
of your site's visitors will be able to use it, because the most
popular browser does not support XHTML in any useful way. The
alternatives are

(1) to serve HTML,
(2) to serve XHTML with the HTML MIME type, which often violates the
RFC and adds absolutely no benefit over (1).

My recommendation is to serve valid HTML 4.01 Strict documents.

--
Dean Tiegs, NE¼-20-52-25-W4
“Confortare et esto robustus�
http://telusplanet.net/public/dctiegs/

[Peter Foti]

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

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="selected">...</option>
^^^^^^^^^^^

Can anyone tell me what browsers those might be?
I don't know the answer to that.
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...

Avoid <font> like the plague. :) And avoid inline styles if possible. If
your markup is semantically correct, it should be very easy to apply styles
via an external stylesheet.

Regards,
Peter Foti

[Christopher Benson-Manica]

Dean Tiegs <da*@invalid.invalid> spoke thus:

There is no legitimate reason in 2003 to use the "font" element, and
very few legitimate reasons to use the "style" attribute. Use an
external CSS style sheet. Once you have gone through the rather small
effort to learn CSS, you will see how much easier it is than the
alternatives.
So <span style="color: red">red</span> is universally preferred to
<font color="red">red</font>?
My recommendation is to serve valid HTML 4.01 Strict documents.

Thanks.

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

[Christopher Benson-Manica]

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

Avoid <font> like the plague. :) And avoid inline styles if possible. If
your markup is semantically correct, it should be very easy to apply styles
via an external stylesheet.

Heh, will do... only problem is that I'm helping to maintain and
extend some CGI's from several years ago, and <font> is splattered in
various places... So what's the best way to replace instances of

<font color="red">red</font>

? External stylesheets might be the best answer, but I don't have the
luxury of making macroscopic design decisions...

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

[Peter Foti]

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

Dean Tiegs <da*@invalid.invalid> spoke thus:

There is no legitimate reason in 2003 to use the "font" element, and
very few legitimate reasons to use the "style" attribute. Use an
external CSS style sheet. Once you have gone through the rather small
effort to learn CSS, you will see how much easier it is than the
alternatives.

So <span style="color: red">red</span> is universally preferred to
<font color="red">red</font>?

No, avoid the style attribute. You are better off doing something like:

<span class="error">This is an error</span>

And then using an external stylesheet to apply style to the error class:

..error { color: red; background-color: yellow; }

And please, don't create a class named "red"... that would be bad.

Regards,
Peter Foti

[Christopher Benson-Manica]

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

No, avoid the style attribute. You are better off doing something like:
<span class="error">This is an error</span>
And then using an external stylesheet to apply style to the error class:
.error { color: red; background-color: yellow; }
Sounds like a plan...
And please, don't create a class named "red"... that would be bad.

Why is that? If that's the class' only purpose (to make itself red),
why not just name it that?

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

[Peter Foti]

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

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

No, avoid the style attribute. You are better off doing something like:
<span class="error">This is an error</span>
And then using an external stylesheet to apply style to the error class:
.error { color: red; background-color: yellow; }

Sounds like a plan...

And please, don't create a class named "red"... that would be bad.

Why is that? If that's the class' only purpose (to make itself red),
why not just name it that?

I just posted a reply to another message in this thread explaining why
that's bad. :) Check that post.
Pete

[Peter Foti]

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

Heh, will do... only problem is that I'm helping to maintain and
extend some CGI's from several years ago, and <font> is splattered in
various places... So what's the best way to replace instances of

<font color="red">red</font>

If you actually have places in the code that look like this, you're worst
off than I imagined. ;)

You would never want to create a style class named "red", because the point
of CSS is that you can change the presentation without the need to change
your HTML code. For example, suppose I want to display an error message,
and I know that I want my error message to have red text with a yellow
background. I could define a CSS style like this:

..redwithyellowbg { color: red; background-color: yellow; }

but the problem with this approach is that if I ever decide I want my error
messages to have white text on a black background, then I would change my
class definition to read:

..redwithyellowbg { color: white; background-color: black; }

As you can see, the class name no longer makes any sense. In my HTML code I
will see something like:

<span class="redwithyellowbg">Hey, this is white on black error
message!</span>

A better solution would have been to name the class according to what the
item represented, not according to the style that I want to represent. For
example:

..error { color: red; background-color: yellow; }

Now it doesn't matter how I change the color because my HTML code makes
sense now.

So, to answer your question... it really depends on what it is that's
between the <font></font> tags? If you have the word "red" between the font
tags like your example, then this could be something that allows the user to
select a color? In which case, you might do:

Pick a color:
<span class="colorred">red</span>, <span class="colorblue">blue</span>

And define styles for those classes in an external stylesheet.

If this is something that says "Items in <font color="red">red</font> are
required"... well, that's bad design because you might have someone with a
monocrome monitor, or someone who is color blind. For those cases, you
would be better off doing something like "* indicates required items" and
then put a * next to those items.

Hope this helps.
Peter

[Christopher Benson-Manica]

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

<font color="red">red</font>

If you actually have places in the code that look like this, you're worst
off than I imagined. ;)
Um... I'm looking directly at code like

<font size=+2><b>blah</b></font>

(yes, that's without double quotes around +2...). So yeah, it's not
the best code ;) (I didn't write it!!!)
If this is something that says "Items in <font color="red">red</font> are
required"... well, that's bad design because you might have someone with a
monocrome monitor, or someone who is color blind. For those cases, you
would be better off doing something like "* indicates required items" and
then put a * next to those items.

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

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

[Peter Foti]

"Christopher Benson-Manica" <at***@nospam.cyberspace.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****@systolicnetworks.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)cyberspace.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.net> <http://www.bertilow.com>

[Peter Foti]

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

Peter Foti <pe****@systolicnetworks.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="copyright">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****@systolicnetworks.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="incidentally">
linked (if you want) to an audio stylesheet suggesting a different
voice.

[Eric Bohlman]

Christopher Benson-Manica <at***@nospam.cyberspace.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="incidentally">
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"incidentally"'? 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.net> <http://www.bertilow.com>

[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="incidentally"> 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"incidentally"'? 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****@systolicnetworks.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)cyberspace.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="incidentally">
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"incidentally"'?

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="smallgreenverdana" anyway.

[Bertilo Wennergren]

Philipp Lenssen:

Bertilo Wennergren wrote:

Are there any user agents of programs around that are able to find
any meaning in 'class"incidentally"'? 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.

True. But there are would be some wider possibilities if the practice of
adding "CSS signatures" would become widespread.

<URL:http://archivist.incutio.com/viewlist/css-discuss/13291>

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Bertilo Wennergren]

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="incidentally">
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"incidentally"'?

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.
Thanks for the clearification. I thought you'd lost it there for a
moment. :)
I've no argument there, but would it _really_ be better for humans if
all the class names were meaningless gibberish?
They'd better be meaningful for humans. That's why

<span
"class='something-meaningful-in-order-to-remember-why-this-had-to-have-a-special-style'"Whatever</span>
is a lot better in the long run, e.g. for site maintenance.
At least it seems handier than this:

<font color="red">Whatever</font><!-- "Something meaningful in
order to remember why that had to stand out with red color" -->
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.
I surely don't.
A lot better than class="smallgreenverdana" anyway.

I once tried to explain to our designer why such class names wouldn't be
good in the long run. I failed...

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Brian]

Christopher Benson-Manica wrote:

(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?).
And how to you plan on accomplishing that? How will you know who is
using N4, who is using N6, and who is using IE? Surely not ua strings....

And what about Opera users? NS7 users? Lynx? IE/Mac? Safari? Are
they all s--- outta luck?
Unfortunately not - these are all just random places where we
basically said "Hey, these two words need to be smaller than the
others."

So you have words that you want to appear smaller, with no reason
whatsoever? Or do you mean something else by "random?"

It sounds like there are problems in the conception of authoring for
the www.

--
Brian
follow the directions in my address to email me

[Brian]

Bertilo Wennergren wrote:

Philipp Lenssen:

Bertilo Wennergren wrote:

Are there any user agents of programs around that are able to find
any meaning in 'class"incidentally"'? 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.

True. But there are would be some wider possibilities if the practice of
adding "CSS signatures" would become widespread.

<URL:http://archivist.incutio.com/viewlist/css-discuss/13291>

Neat! Especially since I starting doing this several months ago
without having ever read that article. :) The idea came to me when I
wanted to undo some user-unfriendly styles on one particular site
without it affecting others. I had to cobble things together using
[att] selectors. Now, on any page I author, the body element's id is
set to the 2nd level domain name of the site.

<BODY ID="tsmchugh"> for www.tsmchughs.com
<BODY id="bonfete"> for www.bonfete.biz

etc. Eric Meyer uses the longer <body id="www-meyerweb-com">. I
suppose that makes writing a user stylesheet self-documenting.
Perhaps I'll adopt that method.

--
Brian
follow the directions in my address to email me

[Matthias Gutfeldt]

Bertilo Wennergren wrote:

Philipp Lenssen:

Bertilo Wennergren wrote:

Are there any user agents of programs around that are able to find
any meaning in 'class"incidentally"'? 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.

True. But there are would be some wider possibilities if the practice of
adding "CSS signatures" would become widespread.

<URL:http://archivist.incutio.com/viewlist/css-discuss/13291>

It's kinda cute to play with these things, sure. But the practical value
is a bit limited; I seriously doubt anybody but webdesigners is going to
use them so.

Speaking for myself, I'm not going to create special rules for each of
those dozens of sites that don't suit my personal preferences or
requirements; I just disable stylesheets altogether and be done with it.
Matthias

[Christopher Benson-Manica]

Brian <us*****@julietremblay.com.invalid-remove-this-part> spoke thus:

And how to you plan on accomplishing that? How will you know who is
using N4, who is using N6, and who is using IE? Surely not ua strings....
No, surely not. Like I said, these pages are CGI-generated (by some
rather involved C++ code), and that code can determine what browser is
viewing the page.
And what about Opera users? NS7 users? Lynx? IE/Mac? Safari? Are
they all s--- outta luck?
Yes. We "officially" support certain browsers, and any others (with
exception of NS7, which of course I meant to include in my previous
description) are going to have to deal...
So you have words that you want to appear smaller, with no reason
whatsoever? Or do you mean something else by "random?"
Well, it happens in enough different places that it would be
impossible to create a single class with a name other than "smalltext"
or something.
It sounds like there are problems in the conception of authoring for
the www.

Perhaps...

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

[Bertilo Wennergren]

Matthias Gutfeldt:

Bertilo Wennergren wrote:

True. But there are would be some wider possibilities if the practice
of adding "CSS signatures" would become widespread. <URL:http://archivist.incutio.com/viewlist/css-discuss/13291>

It's kinda cute to play with these things, sure. But the practical value
is a bit limited; I seriously doubt anybody but webdesigners is going to
use them so.
They could/would also be used be some people who really need them, such
as people with bad eye-sight and others will various special needs. It
doesn't matter much if they would be many of few. Matters that it would
be of immense use to them.
Speaking for myself, I'm not going to create special rules for each of
those dozens of sites that don't suit my personal preferences or
requirements; I just disable stylesheets altogether and be done with it.

Sometimes you might want something of special importance to you, look
very special for you, on a certain site you're visiting frequently
(perhaps your bank or something similar). Disabling stylesheets won't
help with that.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Brian]

Christopher Benson-Manica wrote:

Brian spoke thus:

How will you know who is using N4, who is using N6, and who is
using IE? Surely not ua strings....

No, surely not. Like I said, these pages are CGI-generated (by
some rather involved C++ code), and that code can determine what
browser is viewing the page.

How does the cgi program determine the browser? How can it if some
user are behind a proxy?

And what about Opera users? NS7 users? Lynx? IE/Mac? Safari?
Are they all s--- outta luck?

Yes. We "officially" support certain browsers, and any others
(with exception of NS7, which of course I meant to include in my
previous description) are going to have to deal...

In other words, you're authoring for "certain browsers," and not
authoring for the www. Thus, you are "officially" off topic. ;-)

BTW, Alan Flavell's perennial question seems pertinent here: Do you
believe that the browsers you selected are incapable of properly
rendering html documents?

So you have words that you want to appear smaller, with no reason
whatsoever? Or do you mean something else by "random?"

Well, it happens in enough different places that it would be
impossible to create a single class with a name other than
"smalltext" or something.

<html>
<body>
<p>normal text, whose size is 100% of user's default.
lorem ipsum dolor etc. <span class="bytheway">the "lorem..." text is
latin.</span>
</p>
<p class="note">This is a short, unimportant note.</p>
<!-- other html -->
<div id="copyright">copyright &copy; 2003</div>
</body>
</html>

body {
font-size: 100%;
}

#copyright, .note, .bytheway {
font-size: 95%;
}
--
Brian
follow the directions in my address to email me

[Philipp Lenssen]

Bertilo Wennergren wrote:

Sometimes you might want something of special importance to you, look
very special for you, on a certain site you're visiting frequently
(perhaps your bank or something similar). Disabling stylesheets won't
help with that.

And if that site doesn't support "CSS signatures"?
And if they do, what if they change their HTML?
I don't think it's the job of a site-visitor to write user-stylesheets
all the time. I think the concept of user-stylesheets is pretty much
flawed. Even on perfectly valid HTML strict sites. And hey, there's not
too many of them out there in the first place. And let's face it those
sites you would want to have a user-stylesheet the most are the same
ones that would be the last to support any strict/ CSS Signatures/
valid & accesible stuff.

[Christopher Benson-Manica]

Brian <us*****@julietremblay.com.invalid-remove-this-part> spoke thus:

How does the cgi program determine the browser? How can it if some
user are behind a proxy?
I have no idea (I didn't write the code...) - presumably it works well
enough for enough of our customers...
In other words, you're authoring for "certain browsers," and not
authoring for the www. Thus, you are "officially" off topic. ;-)
Ahh, the dreaded "off topic" pronouncement... ;) Sorry...
BTW, Alan Flavell's perennial question seems pertinent here: Do you
believe that the browsers you selected are incapable of properly
rendering html documents?
INcapable...? I believe that the browsers that we support render HTML
in some way that makes (nearly) everyone happy... whether they render
strict HTML 4.01 is doubtful...
#copyright, .note, .bytheway {
font-size: 95%;
}

Oh! *sheepish* Thanks... So what percentage is <font size="-1">
equivalent to?

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

[Andreas Prilop]

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:

So what percentage is <font size="-1"> equivalent to?

Don't bother; just write <small>.

[Bertilo Wennergren]

Philipp Lenssen:

Bertilo Wennergren wrote:

Sometimes you might want something of special importance to you, look
very special for you, on a certain site you're visiting frequently
(perhaps your bank or something similar). Disabling stylesheets won't
help with that.

And if that site doesn't support "CSS signatures"?
Then it will not be possible (or difficult). Look, that was all in the
context of what would be possible if the use of CSS signatures would
become widespread.
And if they do, what if they change their HTML?
Then you're out of luck - or you adapt your CSS. It will help as long as
it works. It will never damage anything.
I don't think it's the job of a site-visitor to write user-stylesheets
all the time.
Who said anything about "all the time". Some people will need such
possibilities, and will welcome them. Some of them will will profit a
lot from that. All others can just ignore it.
I think the concept of user-stylesheets is pretty much
flawed. Even on perfectly valid HTML strict sites.
I use such a stylesheet al the time. It works very well for me. It's not
flawed at all.
And hey, there's not
too many of them out there in the first place. And let's face it those
sites you would want to have a user-stylesheet the most are the same
ones that would be the last to support any strict/ CSS Signatures/
valid & accesible stuff.

True. We're talking of what would be possible, if some things became better.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Jukka K. Korpela]

Dean Tiegs <da*@invalid.invalid> wrote:

There is no legitimate reason in 2003 to use the "font" element,

That's at least 99 % true, but when the content discusses presentational
things, it is adequate to use presentational markup. For example, if you
write _about_ the Verdana font (e.g., why it should be avoided in author
style sheets), it would be suitable to use <font face="Verdana">...</font>
to show what Verdana looks like when available in the user's system,
preferably with an image for comparison.

In such a case, using CSS for the purpose would not be optimal, since here
presentation _is_ content and we would prefer having it shown as often as
possible, i.e. including non-CSS browsing situations. Well, for really
maximal coverage, a cautious author would _also_ use CSS with !important, to
override the effects of user style sheets as far as possible.

Similarly, if your document discusses some printed material where some words
appear in red and you raise the question what the use of red means there,
wouldn't it be adequate to use <font color="red">...</font> in your
reproduction of the material in HTML? (Again, an image might be shown too,
but that's a different issue, and the HTML alternative is often sufficiently
similar to the original and more useable than an image [or PDF] format.)

(Anyone seen my Purist's badge lately?)

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Brian]

Christopher Benson-Manica wrote:

Brian spoke thus:

How does the cgi program determine the browser? How can it if some
user are behind a proxy?

I have no idea (I didn't write the code...) - presumably it works well
enough for enough of our customers...

Err, that doesn't make sense. The browser sniffing code is for you,
the authors, since the visitors presumably know what browser they are
using and don't need to be told by a cgi program. The point I'm
making is that, while the programmers might *believe* that they can
reliably determine the browser, they most certainly cannot.

http://webtips.dantobias.com/brand-x/useragent.html

In other words, you're authoring for "certain browsers," and not
authoring for the www. Thus, you are "officially" off topic. ;-)

Ahh, the dreaded "off topic" pronouncement... ;) Sorry...

Well, why not go back on-topic and discuss authoring for the www?
That means creating documents that any reasonably conforming browser
can render.

BTW, Alan Flavell's perennial question seems pertinent here: Do you
believe that the browsers you selected are incapable of properly
rendering html documents?

INcapable...? I believe that the browsers that we support render HTML
in some way that makes (nearly) everyone happy... whether they render
strict HTML 4.01 is doubtful...

Lynx renders html 4.01 strict. So does Opera. And so does Mozilla
1.x. If you write valid, robust html, then you've accomplished alot.

#copyright, .note, .bytheway {
font-size: 95%;
}

Oh! *sheepish* Thanks...

yw. sensible html, used with sensible css, can accomplish quite a
bit, really.
So what percentage is <font size="-1"> equivalent to?

Forget about font size using the font element. Get it out of your
head. Start with 100% font-size for the body of your html, and use
css to make other elements larger or (only occasionally) smaller,
relative to the body size.

--
Brian
follow the directions in my address to email me

[Brian]

Matthias Gutfeldt wrote:

there are would be some wider possibilities if the practice of
adding "CSS signatures" would become widespread.

<URL:http://archivist.incutio.com/viewlist/css-discuss/13291>
It's kinda cute to play with these things, sure. But the practical value
is a bit limited; I seriously doubt anybody but webdesigners is going to
use them so.

Perhaps. But it does no harm. And I have wished that other sites had
implemented them.
Speaking for myself, I'm not going to create special rules for each of
those dozens of sites that don't suit my personal preferences or
requirements;
I'd only use it for sites I visit frequently.
I just disable stylesheets altogether and be done with it.

I could. But it'd be one less step when visiting it, and then I
wouldn't lose the styling that I like.

--
Brian
follow the directions in my address to email me

[Christopher Benson-Manica]

Brian <us*****@julietremblay.com.invalid-remove-this-part> spoke thus:

Err, that doesn't make sense. The browser sniffing code is for you,
the authors, since the visitors presumably know what browser they are
using and don't need to be told by a cgi program. The point I'm
making is that, while the programmers might *believe* that they can
reliably determine the browser, they most certainly cannot.
Mkay.. well, in any case, it seems to work differentiate between
Netscape 4 and our "other" supported browsers well enough.
Well, why not go back on-topic and discuss authoring for the www?
That means creating documents that any reasonably conforming browser
can render.
Would you classify NS4+ and IE4+ as "reasonably conforming?"

So what percentage is <font size="-1"> equivalent to?

Forget about font size using the font element. Get it out of your
head. Start with 100% font-size for the body of your html, and use
css to make other elements larger or (only occasionally) smaller,
relative to the body size.

Well, I ask because the current code *uses* the tag I supplied. I
wanted to know what style attribute (be it percentage, or "small", or
"smaller", or whatever) would get me exactly the same thing.

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

[Brian]

Christopher Benson-Manica wrote:

Brian spoke thus:

while the programmers might *believe* that they can reliably
determine the browser, they most certainly cannot.
Mkay.. well, in any case, it seems to work differentiate between
Netscape 4 and our "other" supported browsers well enough.

No, it doesn't. Browser sniffing is unreliable. But if you want to
believe otherwise, go right ahead.

why not go back on-topic and discuss authoring for the www? That
means creating documents that any reasonably conforming browser
can render.

Would you classify NS4+ and IE4+ as "reasonably conforming?"

What I think doesn't matter; I'm not creating special documents for
those browsers. But since you asked...
NS4+
NS4+ is not a single browser. NS4 is one browser. NS6/7, which was
built from the ground up, using nothing from the NS4 code base, is a
completely different browser.

NS4 can render html reasonably well, but you should take care to right
robust code. That means valid code, with the additional work of
closing elements even where the closing tag is optional.

Don't:
<ul>
<li>item 1
<li>item 2
</ul>

Do:
<ul>
<li>item 1</li>
<li>item 2</li>
</ul>

You didn't ask about css, but perhaps you're interested all the same.
NS4's css support is terrible. It parses far more than it can
actually handle. Best bet is to hide all css from it, and give NS4
users plain html. But you can hide only those styles it chokes on, if
you want to go through a lot of work for a very small percent of
users. I can give you examples of both approaches, if you're interested.

NS 6 was based on Mozilla, 0.9 I think. A good effort, but there were
some bugs that should have been worked out before a proper release.
Despite the bugs, I would still call it "reasonable."

NS 7.x, based on Mozilla 1.x, is arguably the browser which conforms
most closely to the standards, both html and css.
and IE4+ as "reasonably conforming?"

Again, you're describing more than 1 browser. IE 5/Mac is a
completely different browser than any Win version.

IE4
I've never used it, so I cannot comment. It's reputation for css is
quite bad.

IE 5/5.5/6/Win
Still lacking some crucial support for standards. Still gets some
things hopelessly wrong. Despite their flaws, many people have
successfully authored html documents that render on them.

IE 5/Mac
Much better. Some bugs, to be sure, in css support, but quite capable.

So what percentage is <font size="-1"> equivalent to?

Forget about font size using the font element. Get it out of
your head. Start with 100% font-size for the body of your html,
and use css to make other elements larger or (only occasionally)
smaller, relative to the body size.

Well, I ask because the current code *uses* the tag I supplied. I
wanted to know what style attribute (be it percentage, or "small",
or "smaller", or whatever) would get me exactly the same thing.

Play with different percentages until you find what works. But do use
100% for the body; never go too far below 100% (I never use less than
90%); and only use smaller fonts sparingly.

--
Brian
follow the directions in my address to email me

[Christopher Benson-Manica]

Brian <us*****@julietremblay.com.invalid-remove-this-part> spoke thus:

No, it doesn't. Browser sniffing is unreliable. But if you want to
believe otherwise, go right ahead.
Well, what I mean to say is, my boss wrote the code, and is
responsible for it and dealing with customer complaints if it doesn't
work correctly. Unreliable or not, it seems to keep the complaint
flow reasonable.
NS4 can render html reasonably well, but you should take care to right
robust code. That means valid code, with the additional work of
closing elements even where the closing tag is optional.
I'm fixing all the instances of <option>...<option> and the like that
I run across.
You didn't ask about css, but perhaps you're interested all the same.
NS4's css support is terrible. It parses far more than it can
actually handle. Best bet is to hide all css from it, and give NS4
users plain html. But you can hide only those styles it chokes on, if
you want to go through a lot of work for a very small percent of
users. I can give you examples of both approaches, if you're interested.
From what I'm gathering, we're on the verge of "de-supporting" NS4,
but I wouldn't be much of a computer programmer if I weren't
interested in seeing both approaches ;) (if you wouldn't mind...).
FWIW, some of our pages do use some simple <style> elements (link
colors, mainly) and NS4 seems moderately pleased with those. On the
other hand, it choked horribly when I tried to write a <span
style="..."> tag with JavaScript...
Again, you're describing more than 1 browser. IE 5/Mac is a
completely different browser than any Win version.
Understood - my mistake. I'm speaking of IE for Windows here (Mac
users are on their own).
Play with different percentages until you find what works. But do use
100% for the body; never go too far below 100% (I never use less than
90%); and only use smaller fonts sparingly.

Thanks.. I hope I'm not trying your patience too much ;)

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

[Alan J. Flavell]

On Fri, 21 Nov 2003, Christopher Benson-Manica wrote:

Well, what I mean to say is, my boss wrote the code, and is
responsible for it and dealing with customer complaints
Who are the "customers" here? Are you talking about the end users of
the web pages, or are you talking about clients who are paying you to
create web pages for them?
if it doesn't work correctly. Unreliable or not, it seems to keep
the complaint flow reasonable.
It's an extremely bad plan to use the end users as one's test of
technical competence. They look to _you_ to provide the technical
competence.

If you found some user who was technically competent to comment on the
above approach, and if they realised that you were making your web
pages dependent on server-side inspection of client agent strings,
they might very well conclude that it was a complete waste of time to
write to anyone who would implement such a misconceived "solution".

In any case, most end users will only get to see your pages on one
browser/version, so they would have no idea how well it might or might
not adapt to other browser/versions. Either it will present a usable
page for the browser they happen to be using, or it won't: that's the
limits of what they'll get to test for you.
From what I'm gathering, we're on the verge of "de-supporting" NS4,
but I wouldn't be much of a computer programmer if I weren't
interested in seeing both approaches ;)

You'd be better advised to read previous discussions on the
*stylesheets* group, but a standard cite at this point would be:

http://w3development.de/css/hide_css_from_browsers/

[Kris]

In article <Xn*****************************@193.229.0.31>,
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

(Anyone seen my Purist's badge lately?)

Yeah, I have it. Picked it up when you dropped it, on that night we were
out on the town, molesting Flash authors. I remember we had a lot of
fun; you even got to woop your bicycle chain over some guy who insisted
on using JavaScript for form validation.

--
Kris
kr*******@xs4all.netherlands (nl)

[Tim]

On 21 Nov 2003 16:42:35 GMT,
"Philipp Lenssen" <in**@outer-court.com> wrote:

I think the concept of user-stylesheets is pretty much flawed.

I agree that you're quite limited, but I do use a couple. I've got one
that removes all colouring and font size changes, so that I can read
stuff on annoying sites, and I have some others that are fairly similar
to suit my needs. They're nothing special, but I can't really achieve
the same thing by playing with the browser default settings.

--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.

[Tim]

"Philipp Lenssen" <in**@outer-court.com> wrote:

I think the concept of user-stylesheets is pretty much flawed.

Tim <ad***@sheerhell.lan> wrote:
I agree that you're quite limited, but I do use a couple.

Oops, that's supposed to say "they're" limited, not "you're."

--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.

[Philipp Lenssen]

Jukka K. Korpela wrote:

Dean Tiegs <da*@invalid.invalid> wrote:

There is no legitimate reason in 2003 to use the "font" element,

That's at least 99 % true, but when the content discusses
presentational things, it is adequate to use presentational markup.
For example, if you write about the Verdana font (e.g., why it should
be avoided in author style sheets), it would be suitable to use <font
face="Verdana">...</font> to show what Verdana looks like when
available in the user's system, preferably with an image for
comparison.

I would say images of the font are the way to go in this case. I don't
know how a deprecated element would be more suited if the font really
needs to be there in the document. Especially when it's a font I don't
have whatever you do won't help me see it.

[Salagir]

On Fri, 21 Nov 2003 18:40:27 +0000 (UTC), in
comp.infosystems.www.authoring.html, Jukka K. Korpela wrote:

There is no legitimate reason in 2003 to use the "font" element, For example, if you
write _about_ the Verdana font (e.g., why it should be avoided in author
style sheets), it would be suitable to use <font face="Verdana">...</font>
to show what Verdana looks like when available in the user's system,
preferably with an image for comparison.

And what about <span style="font-family: Verdana">...</span> ?
Similarly, if your document discusses some printed material where some words
appear in red and you raise the question what the use of red means there,
wouldn't it be adequate to use <font color="red">...</font>
same with <span style="color:red">...</span>
(Anyone seen my Purist's badge lately?)

I stole it hiahahahahahahark

--
++++++++ Zelda, Dragon Ball, Mana and my (art)work at www.salagir.com ++++++++
Buffy: Last night was the most perverse, degrading experience of my life.
Spike: [smiles fondly] Yeah. Me too.
-+- Two lovers in Buffy The Vampire Slayer, 6x10 - Use condoms. -+-

[Jukka K. Korpela]

Salagir <Sa*****@jeruCITEDELESPACE.org.invalid> wrote:

And what about <span style="font-family: Verdana">...</span> ?

When you know that you are actually using an element for the sole purpose of
making some text appear in a specific font, would <span> really be adequate
when <font> is available? After all, <span> or <div> effectively means that
an author designates an element (inline element or block element,
respectively) and says that there is no other markup in HTML as currently
defined that would be descriptive of the element.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Jukka K. Korpela]

"Philipp Lenssen" <in**@outer-court.com> wrote:

I would say images of the font are the way to go in this case. I don't
know how a deprecated element would be more suited if the font really
needs to be there in the document.
I don't know how an image format would be more suited if we know that the
context is actually text, just to be rendered in a specific font, and
perhaps only used to exemplify that font.
Especially when it's a font I don't
have whatever you do won't help me see it.

And an image does not help me if I am browsing with image loading turned
off. But a fair comment - it would be best to use _both_ an image _and_
<font> markup when discussing font samples. If you consider sticking to
<img> only, you would be faced with the issue of alt text, and the logical
approach would then be
<font face="Verdana"><img alt="Sample text" src="sample.gif"></font>
but, as we know, IE fails to get it.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Brian]

Kris wrote:

In article <Xn*****************************@193.229.0.31>, "Jukka
K. Korpela" <jk******@cs.tut.fi> wrote:

(Anyone seen my Purist's badge lately?)

Yeah, I have it. Picked it up when you dropped it, on that night we
were out on the town, molesting Flash authors. I remember we had a
lot of fun; you even got to woop your bicycle chain over some guy
who insisted on using JavaScript for form validation.

rotfl
This gets my vote for funniest post of the week (month?).

--
Brian
follow the directions in my address to email me

[Bertilo Wennergren]

Jukka K. Korpela:

And an image does not help me if I am browsing with image loading turned
off. But a fair comment - it would be best to use _both_ an image _and_
<font> markup when discussing font samples.

Hmmm... Is the _meaning_ of the "font" element really "a sample of the
font indicated with the 'face' attribute"? I don't think so.

The HTML 4.01 Spec say:

The FONT element changes the font size and color for text in its
contents.

Nothing about meaning there. It just changes (or suggests a change of)
the display font. It's purely presentational.

It would of course be a tad better, if "font" acually were a meaningful
element. That would put it in with "kbd", "samp" and other esoteric
elements: of little use, but quite OK when it's actually needed once in
a blue moon. But that's just dreaming.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Alan J. Flavell]

On Mon, 24 Nov 2003, Jukka K. Korpela wrote:

And an image does not help me if I am browsing with image loading turned
off. But a fair comment - it would be best to use _both_ an image _and_
<font> markup when discussing font samples. If you consider sticking to
<img> only, you would be faced with the issue of alt text, [...]

As a practical example, I give you
http://www.xs4all.nl/~sbpoley/webmatters/verdana.html

I think the author has approached the problem with good compromises,
considering the purpose of the page. The demonstrations are never
going to prove anything on a character-cell browser (Lynx etc) or
screen reader anyway, so those kinds of user are going to just have to
believe what he tells them in the text ;-)

The idea of specifying the exact desired font, followed by monospace
fonts as fallback, was particularly ingenious ;-)

[Jukka K. Korpela]

Bertilo Wennergren <be******@gmx.net> wrote:

The HTML 4.01 Spec say:

The FONT element changes the font size and color for text in its
contents.
You spotted an interesting oddity. The wording reflects HTML 3.2, which did
not allow the face attribute (though mentioned it!). The intent is, of
course, to say "font size or color or face".
Nothing about meaning there. It just changes (or suggests a change of)
the display font. It's purely presentational.

Well, it specifies the preferred font, and that's exactly the desired
meaning in my example. There's a difference between using some
presentational feature (for some effects) and discussing the feature itself.

It's actually odd (and I'm not the first one to say this) that <font> is
deprecated, and so is <u>, but <b> and <i> and <tt> and <small> and <big>
are not.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html