On Fri, Oct 31, 2008 at 4:52 PM, Pentasis <[EMAIL PROTECTED]> wrote:
I hope I am doing this right, I am not used to mailing lists ;-)
Anyway, following some discussions on the web regarding footnotes/side
notes
I have found that there is a need for some form of element to mark these
up.
The most commonly accepted element at the moment seems to be to use the
<small> element. But this is clearly a wrong use of semantics.
As the <mark> element has different usages defined on it already why not
include a "type" attribute (or similar) that defines what it is used for.
One of these types would then be "footnote", others could be (relating to
what is already in the spec) "term", "highlight" etc. (I am sure others
would be much better at thinking up names than I am).
Esp. in light of the fact that the spec states that UA will probably have
to
provide cross-linking would make this an ideal element for footnotes/side
notes.
Bert
Although I agree with the overall idea, I have to mention that the
"type" attribute itself wouldn't be a good match for this purpose: it
is already used for something different (marking the content type for
stuff like <script>, <img>, <object>, the new <audio> and <video>, and
so on, often expressed as a Mime type). In general, I think
overloading an attribute with different meanings (semantics) is not a
good idea (we should leave the <input> case aside of this
generalization, mostly because it's been using the attribute for over
a decade by now). IMHO, a "role" attribute would match exactly what
you are asking for, although I sent some feedback about it a while ago
and got no responses (it probably went unnoticed, since there were
several discussions running on by the time, and a few of them were
quite heated). Maybe now that you are raising this issue I should try
to bring back the relevant parts of those mails?
OTOH, if a "type", "role", or similar attribute was added, we should
question the need of the <mark> element (and many others) at all: what
would it provide that a <span> with the same "type" or "role" doesn't?
Also, I've seen some comments suggesting that class should be used for
these purposes, and not just as a hook for CSS. If the spec is clear
enough about this broader semantics of the class attribute, and UAs
are aware of it, the only practical difference between class and
type/role will be whether the author can come up with any arbitrary
value (class), or has to choose between a pre-defined set (type/role).
I'm not sure which approach would be better for this specific case.
Have **you** considered using "class" for the purpose you are
suggesting? If you have, and you still feel it's not enough, maybe
explaining *why* would be helpful to figure out what the best solution
would be.
Just my thoughts.
Well, first of all, my personal "ideal" situation would be to provide a
<footnote> element, that UAs would have to render with a footnote
superscripted automatically numbered reference-link. a href-attribute would
indicate where to link to.
But I guess that is out of the question ;-)
I would never opt for using "class" for anything other than CSS styling. The
reason for this being that I feel that neither "id" nor "class" should
contain keywords, but only author defined words. For me a "type" or "role"
attribute would be like an "id" or "class" only it would contain keywords
and be not style-related but content related.
Bert
