The problem with your entire reply is that you take the last remarks and
respond to them out of context, but just on a final note:
No, you're misunderstanding. *Why* are you styling some footnotes
differently?
I never said I am styling footnotes differently. I merely poiiunted out that
if we want to style something with the same class diferently we need to assigne
extra classes to it.
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.
You are correct. They *are* pure semantics and have nothing to do with
style. Your conclusion that they should thus not use title or class attributes
is begging the question, however - you're assuming that classes are purely
stylistic from the start. Microformats were meant to be an example against
that - a case where @class is used completely semantically in a way that UAs
can understand, rather than the standard effect of a semantic language that
only the author understands.
Sure, classes can be used that way, but I quoted the HTML4 spec earlier and
have not seen anyone contradict the fact that it does not provide that
functionality to the class-attribute. Now, perhaps it does in the HTML5 spec,
if so, I stand corrected.
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.
I wish I'd responded to your earlier message here. "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")" is
entirely incorrect. Who would you get in trouble from, the semantics police?
No, from exactly what you describe below. That was my point. The other point
I make here is that no matter how semantically correct I name my class it is
still a stylesheet hook.
The reason you use classes like "footnote" rather than "red" is because
with the former you can change the appearance of your footnotes and the class
still makes sense. With the latter, if you change your styling (to make it
blue, say) you either have to go into the code and change the class to blue, or
you have to change the "red" style itself and render it completely nonsensical.
All CSS is providing you at this point is a shortcut for the <font> tag, which
is completely wasting the potential of the language.
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.
Why does the spec need to provide you with a "proper element"?
Because I was under the impression we want a semantic web?
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).
Just a day or two ago Ian sent out a reminder of what the process is for
getting something new added to the spec. "Why not?" is *not* part of the
process. If it was, the spec would already have gone down in flames as a
bloated piece of "me too!"-riddled crap. You need to provide *strong reasons*
to get something into the spec, reasons that actually make the lives of a
significant number of authors significantly easier. If something is a fairly
niche area without much direct benefit and which can already be done well by
styling and/or scripting alone, then generally it's not worth adding to the
spec. You can just do it yourself in the rare times that you need it.
I did not start out this discussion with a "why not" question. But sofar all
the arguments I have been given do not add up logically. And if you say "why
should it"? I can most definatly respond with "why not?"
For me the discussion ends here since I don't think it is worth the trouble.
All I can say is that I think discussions on this list are of a very closed,
almost defensive nature. But perhaps that is my own fault.
