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

Ian Hickson wrote:
> ...
> 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.
> ...

I do not agree these are "huge" problems.

Yes, people are confused by prefixes. But people are also confused by 
other things, like multiple classes in a single class attribute. People 
are also confused about microformat parsing and class value inheritance.

The answer is test cases, bug reports and education.

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

Oh really? That may work well for "intertwingly", but less well for 
other domains.

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

Not at all. I'd like those to be URIs. I know you don't like them for 
this purpose, but they have the advantage to be simple detectable.

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

Yet, I want it to be possible that it gets used by user agents.

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

It makes documents using them invalid.

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

I do agree that GRDDL could and should have been written without the 
profile dependency.

However I'm not sure what you mean by "custom profile" -- I think GRDDL 
requires exactly one profile, which is used to opt-in to use the GRDDL 
transformation rel value.

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

It seems you're mixing up the base GRDDL specification (a W3C 
Recommendation, <http://www.w3.org/TR/grddl/>) with specific 
microformat-specific use cases mentioned in the GRDDL primer (a WG note, 
<http://www.w3.org/TR/grddl-primer/>).

 >. ..
> is available as a workaround if GRDDL's maintainers decide not to actually 
> fix the real underlying bug in GRDDL.
> ...

So you're saying that meta/@rel=profile is ok, but head/@profile is not? 
If it has the same semantics, why disallow it, breaking existing specs?

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

How does HTML4 "require" profile? Please elaborate.

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

Yes. But that's an extension point, not error handling. Maybe we just 
disagree on terminology here.

BR, Julian

Received on Saturday, 2 August 2008 07:40:18 UTC