Re: <code type="...">

liorean <liorean@gmail.com> writes:
> Further, do we have a reason for assuming that a class attribute
> doesn't deal with this adequately?
[...]
> However, I don't really see what a type attribute adds that a class
> attribute could not be used to provide instead.

@class would work in practice, yes.

In a simple experiment with firefox, it seems like one would need to use
the CSS selector code[class~="application/javascript"] rather than
code.application/javascript, but so what.

Thinking about code that enumerated <code> elements looking for those typed
appropriately, I guess one would need to list all the tokens in the @class,
and look for those that matched the regexp '[^ ]+/[^ ]+', or maybe
'(application|text)/[^ ]+', or maybe just compare to the list that the tool
knows it supports.  That's less direct than looking at a 'type' attribute,
but has the advantage of being possible right now with no changes. :)

At the same time, a particular fragment could have multiple types that it
conformed to (text/plain and text/x-restructured-text, application/javascript
and application/json), and @class will allow both.

More generally, it seems unfortunate (as in Microformats as well) to keep
shoving all this specific data-type information as undifferentiated string
tokens in the class attribute, without meaning or name-spacing.  But it does
seem to work in practice.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}