[whatwg] Add 'type' attribute to <mark>

[Tab Atkins Jr.]

On Sun, Nov 2, 2008 at 3:53 AM, Pentasis <pentasis at lavabit.com> wrote:

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


No, you're misunderstanding.  *Why* are you styling some footnotes
differently?

Is it because they're in a different section, and you want them to match
with the section-wide style?  In that case, there's no need for extra
classes.  As long as each section is wrapped in a container with an
appropriate class or id, you can then use a contextual selector to target
footnotes in each section and style them differently.

Is it because they are fundamentally a different kind of footnote?  Then of
course you need more classes.  Just giving them a single "footnote" class is
obviously not expressing your semantics appropriately.  This doesn't require
any style-oriented classes, just some additional classes that more
specifically express the separate roles your footnotes are filling.

Is it because you've decided you want your footnotes to have different
styles for purely aesthetic reasons?  Then yes, in this case you either need
to tag every footnote with an #id and style them directly, or give out
purely aesthetic classes.  Either way will require a lot of work - up-front
with the id strategy, and continuing with the class strategy (since you'll
need to go back in and change every class as you change your mind on
aesthetics).

Don't get me wrong - there is obviously a correlation between semantics and
style in that the amount of semantics I put into a document is a reflection
of how much style control I want.  This is not because I invent semantics
just for styling, but rather because I am lazy and don't have the time or
patience to accurately describe all of the semantics of the document
(actually, this is likely an impossible task, as the semantics of a document
change when used in different ways).  Thus, I describe what is useful to me,
which generally means what will help me target my styles and scripts.


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


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


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


Why does the spec need to provide you with a "proper element"?  You can just
assign a class!  In CSS or scripting terms there is absolutely no
difference.


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

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081102/2ffe26f4/attachment.htm>