W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Decentralised extensibility idea (ISSUE-41)

From: Philip Jägenstedt <philipj@opera.com>
Date: Fri, 15 Jan 2010 18:13:09 +0100
To: "Leif Halvard Silli" <xn--mlform-iua@xn--mlform-iua.no>
Cc: "Toby Inkster" <tai@g5n.co.uk>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.u6k3f7c8atwj1d@sisko.linkoping.osa>
On Fri, 15 Jan 2010 17:29:21 +0100, Leif Halvard Silli  
<xn--mlform-iua@målform.no> wrote:

> Philip Jägenstedt, Fri, 15 Jan 2010 10:06:19 +0100:
>> On Fri, 15 Jan 2010 00:30:21 +0100, Toby Inkster wrote:
>>> This is a sketch of a proposal for decentralised extensibility (DE) in
>>> HTML5. If there is interest in it, I'll be happy to write it up as a
>>> change proposal, but I'd like to see what people think first.
>> I like the overall goal, because it is exactly like microdata.
> It is perhaps even closer to microformats = HTML4 profiles.
> So, if it is true that it is "exactly like microdata", then isn't it
> ironic that microdata probably would have had bigger chance of becoming
> a success (= been part of HTML5) if it had been designed around
> @profile instead of reinventing a wheel? (Toby is not the first to
> suggest to allow @profile on any element.)
> And why, at all, obsolete @profile if the approaches are so similar?
> Where is the sense?

It's not too late to reuse @profile for microdata if it would somehow  
help. Do you have some specific design in mind?

>> Comments below.
>>> The class attribute has traditionally been used mostly by authors for
>>> their own purposes. That doesn't need to conflict with this solution,  
>>> as
>>> I will later indicate a mechanism for documents to specify which
>>> otherspec(s) they are making use of.
>> Overloading the class attribute (like microformats) isn't a very good
>> idea, it *will* clash with existing markup. The world doesn't end,
>> but it's best to avoid, and in fact easy to avoid.
> It is not clear to me if by "easy to avoid" you meant "easy for authors
> to avoid" or "easy for Toby to design DE so that the problem is
> avoided".

I mean it's easy to avoid in language design, which means authors get to  
keep their class attributes for whatever they want.

>>> So, my original XML-style <car/> element could be written as:
>>> 	<span
>>> 		profile="http://example.com/CarML/html5"
>>> 		class="Car"
>>> 		data-engine-size="1.8L"
>>> 		data-colour="blue">Mazda</span>
>> <span itemscope itemtype="http://example.com/CarML/html5#Car">
>> <span hidden itemprop="engine-size">1.8L</span>
>> <span hidden itemprop="colour">blue</span>
>> Mazda
>> </span>
> So, in a summary, the different approaches are that DE only points to a
> spec. Whereas MD points to an item in a glossary. (Markup language
> verus glossary language.) And thus MD also avoids clashes.  However, I
> wonder, if not many authors in practise would not also add the "Car"
> class? :
> <span class=Car itemscope itemtype=http://example.com/CarML/html5#Car>

Yes, a benefit of letting @class serve double purposes is that sometimes  
those align. However, you could just as well use  
*[itemtype=http://example.com/CarML/html5#Car] as your CSS selector if you  
have no other use for the class attribute than styling.

Philip Jägenstedt
Core Developer
Opera Software
Received on Friday, 15 January 2010 17:16:55 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:57 UTC