W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2007

[whatwg] Predefined classes are gone

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 8 Aug 2007 23:30:45 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.0708082323210.26028@dhalsim.dreamhost.com>

I'm not exactly sure what the context of this e-mail was (it seemed to be 
a non-sequitur relative to its parent e-mail in the thread). It seems, 
however, that it was attempting to suggest a solution without describing 
the problem being solved, which makes it difficult to evaluate. I've 
mostly addressed the syntactical and factual statements in the e-mail 
below, but since it wasn't clear what problem was being addressed, no 
changes have been made to the spec.

On Wed, 8 Aug 2007, cr wrote:
> > >
> > > the start. I think the initial idea was that the class attribute 
> > > would cover the the semantics while CSS the presentation of those 
> > > semantics. The only problem is that earlier specs left those 
> > > semantics undefined, with no way to define them unambiguously
> 
> you can unambiguously define the semantics of an element w/ RDFa..

You can unambiguously define the semantics of an element with many 
features, such as RDFa, class attributes, structured prose, etc. All it 
takes is a well-defined specification describing the conventions of the 
way the semantics are conveyed.


> one might think of an element class='author' being short for 
> 'formattedAuthorValue'. where does 'formatted value' of this come in? 
> the stylesheet. but this is all vague and based on assumptions. if your 
> use case is common enough a standard way to describe it has been layed 
> out on a microformat wiki somewhere..

I don't really follow.


> discovering/parsing RDFa is simpler than microformats as it doesn't need 
> to be special-cased for each scenario,

I don't really see why you think RDFa needs any less special-casing than 
your typical Microformat.


> and unlike microformats is infinitely flexible in what it can represent 

Some might argue that the inflexibility of Microformats is part of its 
appeal, however.


> - doing so without requiring predefined classes or risking name conflict 
> with existing 'non-semantic' classnames.

In practice, though, this hasn't really been a problem.


> attribute :property describes the property, so theres no confusion as to 
> whether the class was just thrown in for styling purposes or was 
> supposed to mean something specific. the properties themselves are 
> resolvable to URIs. eg, dc:modified becomes 
> http://purl.org/dc/terms/modified, the agent can look up a document at 
> this URL, discover the class is a subclass of 'dc:date', then 
> automatically display the modified times on a calendar or timeline. 
> likewise, you could define a 'horror:killed' attribute, benefit from the 
> existing agents without requiring approval from the microformat gods..

Requiring "approval" (or rather, requiring a broad consensus) is always 
going to be important for the conveying of semantics to a wide audience, 
regardless of the syntax. Equivalently, when your audience is small, you 
don't need anyone's approval to do anything to convey semantics, again 
regardless of what your syntax is.


> so, everything you describe is solvable, and has already been thought 
> about and solved in at least one way..

Indeed, many ways.


> also, microformats ses the automatically-tooltipped/human-readable 
> 'title' attribute for the machine-readable encoded format (and the 
> contents of this field are definitely not the 'title' but some sort of 
> attribute value), which is bizarre on several levels... RDFa uses the 
> 'content' attribute for this, preferring that over the innerHTML for the 
> machine-readable format when it is available. im not sure whats worse - 
> the nameclashing with existing web content, the unextensibility, or the 
> reuse of existing attributein unidiomatic ways..

I recommend bringing up such issues with the Microformats community.


> RDFa is potentially a solution to your problems.

We're still trying to work out what the problems are, so it's not clear 
that one can establish what the solutions can be yet.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 8 August 2007 16:30:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:36 UTC