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

Aryeh Gregor On 09-10-18 23.33:

> On Wed, Oct 14, 2009 at 12:54 PM, Tony Ross:
>> A concern I have seen raised here is that user agents will
>> use such a mechanism to introduce proprietary elements and
>> implementations. I agree that's entirely possible, but as
>> others have pointed out, this can happen and has happened
>> even without a formalized method for extensibility.
> 
> Well, by the same token (just to pick one of many issues at
> random), it's been demonstrated that many authors will use
> presentational markup no matter how much specs discourage them.
> Is that a reason for the spec to make presentational markup
> valid?  HTML5 mostly takes the approach of making undesired
> features invalid, so that they work but don't validate, even
> though this won't stop them entirely.  A surprising number of
> authors do actually care about document validity for some
> reason, in my experience.  (As reported by a validator, I mean,
> not that they care what the spec says.)

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

>> User agents are also not the only customers for markup
>> extensibility. Script libraries, editors, and even future
>> standards may choose to make use of such a mechanism.
> 
> Well, first of all, other standards are already allowed to
> extend HTML5.  Look at RDFa, for instance.  Of course, these
> won't validate automatically, and need to be explicitly
> supported by the validator. But that's necessary anyway to
> ensure that the foreign markup is valid according to its own
> standard.  So I think other standards are covered already
> (please correct me if I'm wrong).

RDFa is an example of centralized extensibility.

> On the other hand, I'm not clear what you mean by script
> libraries or editors.  Are you referring to packages in
> standard client-side formats such as JavaScript, which would
> like to store data in the DOM for their own purposes?  I think
> this is covered pretty well by the class attribute, data-*, and
> so on.  While it's true that making up your own elements would
> be kind of neat, it doesn't seem to give much practical
> benefit.  It's entirely possible I missed some use-cases in all
> the discussion -- what exactly would custom attributes/elements
> be useful for, from the perspective of JavaScript or similar 
> technologies?  getElementByTagNameNS() was mentioned, but 
> getElementsByClassName() should be just as fast, I'd think.


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

For authors it is natural to use a class name in several contexts.

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.

CSS will b.t.w. be a great tool for authors to learn namespaces.

 
> If by script libraries and editors you mean non-standard
> extensions -- like browser plug-ins, Flash, etc. -- then I
> think it's entirely correct that markup to support them
> shouldn't validate.  Validation is a sign that your content is
> standards-compliant, which it isn't if it contains non-standard
> content.


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

 
> So in short, despite reading all this discussion, I'm really
> not sure exactly what applications need more support than they
> have already. Other than applications that want to write markup
> that only they can read, but I don't get why HTML5 would want
> to give them more support.

All browser are now more or less able to deal with unknown 
elements. There might be reasons to avoid decentralized 
extensions, though. And may be the validator should somehow have a 
"clean" profile, where no decentralized extensions are considered 
valid. (See the "Profile" pop-up in Validator.nu)

>> Giving such extensions a standard form also increases author
>> awareness that the markup is not native to HTML itself.
> 
> This would be accomplished equally well if there were a
> standard mechanism for extensions (namespace-based or
> otherwise), but it didn't validate, like in CSS.  Would that
> satisfy your requirements?

So you *support* namespaces in HTML 5, you just do not think that 
they should be considered valid? Well, that is a positive step in 
the right direction. My question back would be if "profile 
validation" (see above) would be satisfy your concerns?
-- 
leif halvard silli

Received on Sunday, 18 October 2009 23:25:23 UTC