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

On Sun, Oct 18, 2009 at 7:34 PM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
> 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.

I don't agree, but regardless of opinion in this regard, neither
centralized extensibility nor RDFa is germane to the discussion.

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

I would say since the topic is related to decentralized/distributed
extensibility, the prevention of name clashes is entirely germane to
the discussion.

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

I'm not sure where the concept of proprietary tools enters this. I
have seen HTML used for proprietary tools, and CSS, too -- should we
then desist in working on these? Or should we accept, as fact, that
any open specification can be, and will be used, in proprietary tools.

And again, I'm not sure how anything that will be added to HTML pages
cannot be public specified. We can have a standard form of
decentralized extensibility, in fact we do, and have for over a
decade: namespaces. How this is used by any one vendor is not our
concern, other than the use has to be valid if they want the use to
validate.

We're not nannies to dictate what every company and vendor does with
these specifications. To say that, "We're sorry but you're using HTML
for a proprietary tool and that's not 'standard'", when it is
perfectly acceptable.

Unless we're willing to tell every maker of a commercial product that
uses HTML, or CSS, or any number of W3C and other specifications that
they have to desist, I think we need to separate our concerns on this
issue from the core of the discussion.

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

That's a risky path to walk. You've just equated proprietary with
standard, and then stated non-standard should be invalid. Are you
saying that all proprietary uses of HTML5, then, should be invalid?

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

Shelley

Received on Monday, 19 October 2009 12:00:08 UTC