W3C home > Mailing lists > Public > public-html@w3.org > August 2008

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

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 3 Aug 2008 22:09:50 +0000 (UTC)
To: Julian Reschke <julian.reschke@gmx.de>
Cc: 'HTML WG' <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0808032118500.13029@hixie.dreamhostps.com>

On Sun, 3 Aug 2008, Julian Reschke wrote:
> > 
> > Education is expensive. Why not just make it unnecessary?
> If you can make it unnecessary without suffering from other drawbacks, 
> like chattiness, unreliable disambiguation and unnecessary mapping 
> problems to other specs, fine.

Using a domain name followed by a hyphen followd by a word seems to solve 
all of these simply.

> > > > One finds people confused about many things, but honestly I have 
> > > > rarely found any concept that causes non-geeks more confusion than 
> > > > the concept of indirection. Namespace prefixes are nothing more 
> > > > than indirection, that's their entire reason for being.
> > > Class names use indirection as well.
> > 
> > How so?
> It's first level indirection in that you specify a class name, instead 
> of adding the style information in place. In addition, it uses 
> inheritance with exceptions, plus cascading, and - in HTML5 - scoping.
> I'm mystified how a web developer can get *that*, and fail to understand 
> prefixes. Sorry.

Oh for styling. Authors have had huge problems with that. It's actually 
quite humbling to try to teach CSS to someone who hasn't ever learnt the 
way of the Web, because they never ask "How do I make headings red?" they 
ask "How do I make this piece of text red?".

The indirection of class names in CSS is a huge problem too.

> > Why? Are you concerned that people using different dismabiguation 
> > schemes would somehow come up with clashing names? How would that 
> > happen? Could you give an example?
> Of course that could happen. For instance, when using domain names, is 
> the TDL right (URI) or left (Java packages). And so on.

Could you actually give an example where this could happen? I haven't been 
able to find a case where an actual clash could happen.

Consider that even without any sort of disambiguation mechanic other than 
just picking unusual names, Microformats has had no serious problems with 
clashes. If you add domain names to the same thing, the problem really 
becomes moot.

It's like saying that you can't use checksums for disambiguating things 
because you might have a clash.

> What if you don't have a domain name, and prefer a UUID. Or a URN? Or a 
> date-stamped URI (tag: URI scheme)? URIs give you the choice.


None of these are ambiguous. They don't even have to use the same scheme 
-- since they're all completely opaque, so long as you generate something 
that is unambiguous, you will know that it can never clash with someone 
else's. No need for URIs.

But _you_ can use URIs if you want to.

> > > Again: who is "we" in this case? Certainly not the HTML WG.
> > 
> > So you're in favour of the behaviour seen in the browser wars where 
> > people just made up their own tags all the time?
> > 
> > I am not.
> I am in favor of being able to use new vocabularies without getting the 
> WHATWG's or the W3C's approval first. The price for that is that I have 
> to put them into a separate namespace, and that is totally fine. It 
> works everywhere else.

If the price for that is that you have to use a syntax intended for this 
use, which is in a different _syntactic_ space than the language's main 
vocabulary, is _that_ an acceptable price?

> > If you are using the scheme="" attribute for Dublin Core metadata, 
> > could you point me to the part of the spec that defines what the 
> > semantics of scheme="" values is? How would an independent Dublin Core 
> > processor know how to interpret the scheme="" values?
> I can't answer that, and that is a problem of that standard.

Ok, well, until someone can tell me what the attribute actually does, and 
show that's there's a real, widespread need for it, let's not add it.

> That still don't gives us the mandate to simply drop the attribute.

Actually, we have the mandate to drop anything we like in the whole 
language. Or add anything.

> Also, HTML4 says the interpretation depends on the profile attribute, so 
> again, pages can opt into a specific behaviour if they choose to do so.

Since we've also not included the profile="" attribute...

We have other mechanisms now that are much more flexible for including 
private metadata of all kinds, e.g. data-*.


The GRDDL maintainers should make the following changes to GRDDL:

1. Don't require profile="http://www.w3.org/2003/g/data-view" to support 
   link rel=transformation.
2. Don't require transformations to look for profiles before applying 
   their transformations.

Having done this, you now no longer need profiles to be declared, without 
losing any functionality.

We're not keeping profile="", evidence is overwhelming that authors rarely 
use it and, if they try, use it incorrectly. We're not including things 
that are much more widely used (e.g. <font>). The bar for adding a feature 
to HTML5 is high. profile="" doesn't even come close to qualifying. It's 
not even actually solving a problem that needs solving, it's just a way to 
declare something that you can just assume anyway. Indeed, it's similar to 
a DOCTYPE declaration.

> If you insist on removing it, then please:
> - get WG consensus to do so,


> - explain to HTML4 users the replacement strategy,

Do exactly what you did before, just without the profile="" attribute.

This is what most authors are doing anyway.

> - work with the other standards groups (in this case GRDDL) to get the 
> spec updated to use the other format.


Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 3 August 2008 22:10:30 UTC

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