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

On Sat, 2 Aug 2008, Julian Reschke wrote:
> > 
> > If you wanted to disambiguate your "price" from other people's, you 
> > could use a URI instead:
> > 
> > <span class="http://ns.intertwingly.net/price">$7.99</span>
> 
> 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.

It solves the problem of chattiness, but unfortunately causes such huge 
problems for authors in terms of understanding it that it's probably not 
worth it. There are other ways of avoiding chattiness though, that don't 
require prefixes nor have the problems associated with prefixes.

For instance, there's no reason we need to use a URI. People could just do 
this instead:

   <span class="intertwingly.net-price">

...or even:

   <span class="intertwingly-price">

...or some such. It's highly unlikely that two groups with similar domain 
names would both come up with clashing names.


> 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.

We could add:

   Authors may use their domain name, or some other identifying or unique 
   information, as a way to disambiguate class names they invent from 
   class names used by other people. This allows class names invented by 
   multiple groups to eventually be used on pages together, without 
   clashes. Author inventing class names should avoid including domain 
   names or other identifying information that would clash with another 
   author's.

   For example, an author at example.org could use class names like 
   "price.example.org" or "currency.example.org", and an author at 
   example.com could use class names like "com.example.price" and
   "com.example.stock". Their "price" class names are then 
   distinguishable. However, it would be considered inappropriate for the 
   author of example.org to then invent a class name 
   "com.example.quantity" without first getting permission from the author 
   of example.com.

Would that satisfy your request?


> > With HTML5, you can even have custom attributes on your element:
> > 
> > <span class="price" data-currency="XCD">$7.99</span>
> 
> If the currency information is for anything except scripts within the 
> page, it would be an abuse of that attribute, right?

Not necessarily scripts, just not something that is to be used by a user 
agent. It's for private data, but that doesn't mean it can't be used by 
tools specific to that site or its affiliates.


> > 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.

As far as I can tell, use of Dublin Core metadata rarely if ever uses the 
scheme="" attribute. In fact insofar as I can determine from reading 
RFC2741, there are no normative requirements on the use of "scheme", it is 
purely at the whim of the author. So this doesn't break anything.


> Another one is GRDDL, and HTML5 breaks it by removing the profile 
> attribute on head.

GRDDL's use of the profile attribute is an abuse of the profile attribute 
(it requires custom profiles, not the official profiles for the 
Microformats it supports) and in addition is frankly just a bug in GRDDL 
(authors rarely use the profile="" attribute when using Microformats so to 
work with real content GRDDL should be designed to handle content 
irrespective of the profile="" attribute). In any case, <link rel=profile> 
is available as a workaround if GRDDL's maintainers decide not to actually 
fix the real underlying bug in GRDDL.


> 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???

My understanding is that this is present because HTML4 theoretically 
requires profile="" and HTML5 isn't done yet.


> > > 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.

A defined parsing mechanism, whether it was based on defining an 
extensibility mechanism or just based on defining a simple parsing 
mechanism like HTML5 has today, would have prevented browsers from being 
inconsistent in handling unrecognised tags.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 2 August 2008 06:50:26 UTC