* As a style sheet selector (when an author wishes to assign style
information to a set of elements).
* For general purpose processing by user agents."
The first role is clear, it is used for styles (not semantics)
Ian answered to this. You'll similarly or identically style elements
with similar or identical meaning; in other words, you'll attach style
to semantics, so your class names are likely to markup your document
with additional semantics.
That is exactly why I think it is wrong. It gives me less flexibility. It
means I must either style all footnotes (or whatever) the same, or introduce
more classes/ids to style them differently and in that case I create a
situation in which some classes are pure semantic and others are only there
for style reasons and have a less than perfect semantic name
("footnote-style-1" for example).
the second is
a bit more muddy I think, but the important part there is: "processing BY
user agents". User agents have no interest in semantics, so I fail to see
here also why classes may be used to define semantic roles.
Microformats.
Don't get me wrong, microformats are a good idea, but they lack the
construct in standards to be used efficiently. They should not use title or
class attributes. They specify a role and pure semantics and have absolutely
nothing to do with styling on their own.
The fact that a class should be named "footnote" for example is only so
you
will not get in trouble (unlike when you use a name like "red" or
"left").
But this only tells me (the author) that this element should be styled
like
a footnote and for the user agent that it should render it like a
footnote.
It should not tell me (or anything else) that it IS a footnote. This
would
lead inevitably to inflexibility.
Why not enclose your footnotes in <aside> elements?
Because it isn't an aside.
Moreover, a note is not necessarily presented as a "footnote" (i.e.
moved to the end of the "page"), it can be shown in the margin (as in
the WHATWG version of the HTML5 spec) or in popup panels when you
click on a word or "footnote reference" (similarly to definitions in
the old HTMLHelp on Windows).
Very true, that is exactly what I have been saying. The current spec does
not take this into account. As it stands now, I must assign a class-name to
the footnote and then style (and perhaps script) based on that
class-reference. But it fails to give me a proper element to do this. Like I
said, I think the Mark element would be great, but then either it should get
a "role" atribute or the examples given in the spec should give it a more
flexible meaning.
Footnotes (and the likes) fall in the same catagory as definitions, so why
not give it an element just like it? (or broaden the meaning of the
dfn-element).
Bert
