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

Aryeh Gregor On 09-10-19 02.34:

> On Sun, Oct 18, 2009 at 7:24 PM, Leif Halvard Silli:
>> 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.


No proponents of decentralized extensibility think it is "a bad 
thing". I have also not seen anyone lobbying for "presentational 
markup". (But we have debated what presentational markup *is*.)

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

'Unstandard data formats' and 'undesired features' are different 
concepts. Decentralized extensions = standard format.

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

Of course it is possible to live without namespaces, and even 
without class names. (AFAIK, HTML didn't have @class from the start.)

Class names are however often something that you add /after/ you 
have done the mark-up.

Whereas if we have namespaces, with a prefixed element name 
solution, you would be adding the prefix all the time - 
<foo:element>. You would not have to plan for anything or look 
over the code "after the fact" and see what classes you need to 
add in order to make the "space structures" of the page 
selectable. (In case of default namespaces, one can save oneself 
from some typing and just write <element>.)

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

I could not disagree more. You could simply try to create striped 
tables rows effect ... Those UAs which support :first-child and 
the adjacent sibling combinator (E+E) lets you do that fairly 
simple (of course, could be made simpler ...), without adding any 
class or anything. Whereas e.g. IE6 requires that you add a "to be 
striped" class to every second TR element.

It is a big difference between adding classes and between adding 
namespaces. The namespace is part of the element you add.

Also, you seem to assume that HTML would, by definition, go for a 
prefixed namespace solution -  <foo:element>. Such a solution 
would indeed required quite a lot of typing (for hand coders). 
Whereas if one has a default namespace solution (which could be 
simpler for authors than a prefixed solution would be - take note 
of Jon's comment about how <foo:bar> has  local name <bar>), there 
would actually be less typing.

But even if a prefixed solution would require more typing, you 
would get the strucrre "for free". Adding classes, however, 
requires that the author analyze and understands his own code. 
Only then can he add the classes correctly. But even then, he must 
not make any human errors (think about the striped table) ... 
Whereas namespaces based selectors /helps/ the author understand 
the code he has written.

>> 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, [...]

W3C has defined namespaces as a standard way of extending XHTML 
and XML.

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


What HTML 5 specifies is how UAs should react to already existing 
(in HTML) undesired features. However, namespaces don't exist in 
HTML yet. At least not in an XML (that is 'to be used for 
decentralized extensions kind of) way. So, definitely, how 
namespace extensions would work in HTML would need to be specced.

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


Agreed. But how HTML 5 should look like is what we are discussing.

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

By having a standard, decentralized method for extensions, we make 
sure that extensions do not develop as "facts on the ground" that 
subsequent version of HTML would need to take into consideration 
*regardless* (under the motto "don't break the Web").
-- 
leif halvard silli

Received on Monday, 19 October 2009 13:03:51 UTC