- From: cr <_@whats-your.name>
- Date: Wed, 8 Aug 2007 18:57:14 +0000
> > 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.. 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.. discovering/parsing RDFa is simpler than microformats as it doesn't need to be special-cased for each scenario, and unlike microformats is infinitely flexible in what it can represent - doing so without requiring predefined classes or risking name conflict with existing 'non-semantic' classnames. 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.. so, everything you describe is solvable, and has already been thought about and solved in at least one way.. 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.. RDFa is potentially a solution to your problems. the HTML5 validator says my 'property' and 'about' and 'content' attributes are invalid, but thats no big deal - trivial and benign compared to all the existing semweb tools failing on parsing my RDFa because the document isnt valid XHTML. they made the same mistake with GRDDL... > > So either we fix class, or we create a new attribute (role) (and leave > > class as a purely presentational hook for CSS? Hurk!). The advantage of > > class is that it's a lot easier to use in CSS selectors, making authors > > more likely to use them. The advantage of role is that it begins in a > > clean state, which could mean less false-positive -- I'm not sure this > > will stay true in the long run however, especially if people see role as > > "more semantic" than class and start to use it inconsiderably... > > I agree entirely with the sentiment given above, but I don't know what to > do about it. Suggestions? Is there some way to change the phrasing of the > spec for class="" to help here?
Received on Wednesday, 8 August 2007 11:57:14 UTC