W3C home > Mailing lists > Public > public-html@w3.org > June 2007

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

From: Josh Sled <jsled@asynchronous.org>
Date: Thu, 21 Jun 2007 19:14:06 -0400
To: liorean <liorean@gmail.com>
Cc: "HTML WG" <public-html@w3.org>
Message-ID: <87ir9gx5mp.fsf@phoenix.asynchronous.org>
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}

Received on Thursday, 21 June 2007 23:15:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:01 GMT