Re: ISSUE-41/ACTION-97 decentralized-extensibility

On Sun, Oct 18, 2009 at 7:24 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> What's the link between extensibility and presentational markup?

I was drawing a comparison between allowing presentational markup, and
allowing nonstandard language extensions that cannot be implemented
interoperably.  Both are (arguably) bad things that HTML5 currently
prohibits, but which are sometimes done anyway.

> What's the link between extensibility and "undesired features"?

Unstandardized data formats lock users into a specific product or
vendor, with possibly no escape route ever short of rewriting all
their documents and hoping that everyone else does the same.  They are
therefore generally undesirable for use on the public web.  At least
I'd say so -- since this is a list dedicated to web standards, hosted
by the premier web standards organization, I'd hope most others would
agree.

> RDFa is an example of centralized extensibility.

Correct.

> A class "foo" might be used in all elements, irrespective of which namespace
> the elements belong to. With namespace support, you would thus be able to
> select a subclass of all the elements with class name "foo" - e.g. you could
> select only those "foo" class elements that belong to the namespace "bar".

Using a class "bar" instead of a namespace "bar", and
querySelectorAll('.foo.bar'), is just as easy.  It also works right
now (at least if you use a JS library to mimic querySelectorAll()).
It doesn't guarantee uniqueness of the class name, of course, but how
essential that is seems to be a matter of debate.

> But it is also a well known burden to have to /add/ class names (or even
> elements), only in order to support a particular user agent that lacks
> support for a particular CSS selector.

Mainly because it lets you get away with fewer changes to the HTML
output (which you might not even be able to change easily or at all)
when restyling.  That's a nonissue here -- either you change the HTML
to add a class, or change it to add namespaces.  Neither one is more
troublesome than the other.

> We are discussing what /should/ be considered "standard" here.

Well, the word "standard" has a common English meaning, as well as a
conventional technical meaning within the W3C, IETF, and similar
bodies.  Content whose format is not publicly specified and which can
only be processed using proprietary tools from a single vendor is not
standard no matter who says otherwise.

> So you *support* namespaces in HTML 5, you just do not think that they
> should be considered valid?

I definitely think it makes sense that the spec should make anything
unstandardized invalid.  I'm not sure whether HTML5 needs to specify
what invalid mechanism you should use if you want to extend the
language in a non-standard way.

> My question back would be if "profile validation" (see above)
> would be satisfy your concerns?

I don't think anything that claims to be an HTML5 validator should
ever be saying something is valid when the HTML5 spec says it's not.
Of course, validator writers could always include a "not valid HTML5
but valid according to some more generous definition of my choosing"
mode if they liked.  That's up to them, not us.

Received on Monday, 19 October 2009 00:35:20 UTC