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

On Sat, 2 Aug 2008, Sam Ruby wrote:
> Ian Hickson wrote on 08/02/2008 05:52:10 AM:
> >
> > There is currently no mechanism for including non-visible proprietary 
> > metadata intended for use by user agents in HTML documents without 
> > discussing the extension with user agent vendors and the wider Web 
> > community, but I posit that this is a good thing. We don't want user 
> > agents inventing their own attributes without working with interested 
> > parties to make sure their feature is well designed.
> 
> My read of the HTML5 document differs from yours.  For example, given:
> 
>   http://www.whatwg.org/specs/web-apps/current-work/#custom
> 
> Which of the following are true about custom data attributes:
>  * they are always visible
>  * they are limited to recording non-proprietary data
>  * they are limited to data (vs. metadata)
>  * they are not attributes

None. What would be true is:

 * they are limited to data that is not for use by user agents


> From what I can see, HTML5 has a number of places whereby proprietary 
> meta data can be stashed, the two key limitations remaining are that 
> there is no mechanism defined for preventing new vocabularies from 
> colliding

Anywhere that you can put a name, you can use a name that has a domain 
name in it, as in:

   data-ch.hixie.price="23"
   data-ch.hixie.currency="CHF"


> and no means to define which elementes in embedded content effectively 
> are processed with a self-closing flag set.

The syntax for a self-closing element is for the element to be immediately 
followed by a close tag, for example, what in proprietary XML might be 
written as:

   <foo xmlns="http://example.com/" />

...can be written in HTML5 as:

   <div class="com.example.foo"></div>


> Beyond that there are a number of secondary considerations: case 
> sensitivity of element/attribute names

Why do these matter? Surely if all we're doing is inventing new 
containers, it doesn't really matter whether they're case sensitive or 
not. (As it happens, class names are case-sensitive, and data-* attributes 
are not, but we're somewhat forced into that situation.)


> and the semantics of DOM APIs whose name end in capital 'N' capital 
> 'S').

These are only needed for handling prefixed or default-namespace based 
namespacing mechanisms, so if we just put the name into the element, we 
don't need them. We already have getElementsByClassName() for simple 
selection of elements based on class rather than tag name.


> And, for the record, the royal "we" in the final sentence in the above 
> does not include me.

Ok.


> I'm much more inclined to support the idea of evolution than the notion 
> of intelligent design.  Yes, my experience in XML indicates that a 
> syntax that permits default and prefixed elements to be used 
> interchangably is confusing, but when the expectation is set that all 
> elements in the base vocabulary are not-prefixed, and all elements in 
> extensions are, confusion disappears.  I've analyzed a lot of feed 
> errors over a long period of time, and such confusion just does not 
> happen.

Our experience differs here too.


> As I see it, the first step is to agree that the designers of HTML5 will 
> never define a vocabulary element with a name containing a colon in it, 
> as such are reserved for extensions.

I can guarantee that no HTML5 element or attribute name will ever have a 
colon in it.


> And to treat elements as foreign elements.

I'm not sure what this means.


I look forward to also seeing your reply to my earlier questions:

   http://lists.w3.org/Archives/Public/public-html/2008Aug/0054.html

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

Received on Saturday, 2 August 2008 19:45:57 UTC