Extensibility strategies, was: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

Ian Hickson wrote:
> ...
> The mechanism is the class attribute. Say you wanted to introduce a new 
> element for marking up prices in HTML. You could take an existing fragment 
> of HTML like this:
> 
>    <p>The peas cost $7.99.</p>
> 
> ...and then you could mark up the "price" bit with a custom container with 
> the name "price":
> 
>    <p>The peas cost <span class="price">$7.99</span>.</p>
> 
> If you wanted to disambiguate your "price" from other people's, you could 
> use a URI instead:
> 
>    <p>The peas cost <span class="http://ns.intertwingly.net/price">$7.99</span>.</p>
 > ...

Hey, that's an interesting proposal. I haven't seen that before.

It has the drawback of being very chatty if you have it occur frequently 
in a page, though. Prefix support would solve that.

Anyway: if this is a serious suggestion, we should discuss adding advice 
to HTML5 telling people that if they choose a URI as class name, they 
need to be sure that they have the authority to use it.

> ...
> You could select this element from CSS -- if it's a simple name, for 
> example, it would look like this:
> 
>    .price { color: blue; }
> 
> With HTML5, you can even have custom attributes on your element:
> 
>    <p>The peas cost <span class="price" data-currency="XCD">$7.99</span>.</p>
> ...

If the currency information is for anything except scripts within the 
page, it would be an abuse of that attribute, right?

Remember:

"Custom data attributes are intended to store custom data private to the 
page or application, for which there are no more appropriate attributes 
or elements." -- <http://www.w3.org/html/wg/html5/#custom>

 > ...
> HTML has multiple mechanisms for including metadata information, and 
> similarly has had thousands of extensions invented and several widely 
> used. That use case appears appropriately handled so far by HTML5.
> ...

One of these extensions was RFC 2731, and HTML5 breaks it by removing 
the scheme attribute on meta. Another one is GRDDL, and HTML5 breaks it 
by removing the profile attribute on head.

And hey, another one are microformats, which claim to require profile as 
well:

"In hcalendar-issues, it is ACCEPTED that each microformat should have a 
profile URI, like the XFN profile." -- 
<http://microformats.org/wiki/profile-uris>

I realize this doesn't reflect reality, but then why is nobody fixing 
the web page???

> ...
>> The reality is that browsers aren't consistent in how they handle 
>> unrecognized tags.
> 
> Indeed. This is mostly due to the lack of defined error handling in 
> earlier versions of HTML. We have addressed this in HTML5.
> ...

It is mostly because of the lack of the extensibility mechanism. If 
there would have been one, people wouldn't have needed to rely on error 
handling in the first place.

 > ...
> Here are quotes from a conversation on #microformats last night (I did 
> not take part in this conversation, I just saw it in my logs):
> 
>    <bennewarde> I don't think I've _ever_ seen someone wanting custom 
>    elements
> ...

I see that a lot on certain IRC channels -- people claiming that certain 
other people or things do not exist, although this is clearly incorrect :-)

 > ...
>    <tantek> the point of microformats was not infinite extensibility
> ...

Not sure what the point was, but he's correct in that microformats do 
not provide infinite extensibility.

 > ...
>    <tantek> and btw, we have always intended microformats to be limited, 
>    in both number, and usefulness, and have pursued them knowing this. 
>    it's their limitations that make them achievable, useful, implementable.
> 
> HTML5 has been working with the Microformats community to address major 
> problems, and so far the only issue that's really come up has been the 
> issue with how to encode time, and we handled with with <time>. Indeed, 
> the Microformats community is a testament to the strong extension 
> mechanisms that HTML already has. Certainly I have not heard any requests 
> from that community for anything like what you have been requesting.
> ...

That's probably because that community does not believe in infinite 
extensibility (see above), and thus doesn't include people that could 
make this kind of request.

> ...

BR, Julian

Received on Saturday, 2 August 2008 06:19:19 UTC