Re: Decentralised extensibility idea (ISSUE-41)

On Sat, Jan 16, 2010 at 3:50 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Because applying a class, without the URI, is simpler than the MD
> knee-jerks. Using MD as if it was a markup language spec is shoehorning
> it. (Or can you show how to implement spellcheck="skip" with MD? An
> even so: Any UA or editor still has to implement the MD spellcheck skip
> - there is noting in MD which makes it automatically happen. )

I'd just use the existing standard spellcheck="false" attribute,
personally.  But okay, suppose you have something that's not specced
but is too light-weight for microdata, and you really want something
more like an attribute.  Like let's say squizzle="foobar".  Then great
-- make up a new attribute, and call it squizzle, and say it can have
the value "foobar".  You can already do this, and it will work great.
The spec guarantees that all UAs that don't recognize it will ignore
it.  In fact, that's how many (if not most) existing HTML attributes
arose!

Of course, it won't validate, but it shouldn't, after all -- it's a
vendor-specific extension.  You have to get it in a spec for it to
validate.

> Your definition of "applicable specification" is what? If I say that it
> is applicable, then it is? Then what about validation?

It's applicable if the validator recognizes it as applicable, as far
as I can tell.  If you have a validator maintained by a pro-standards
group like the W3C, it would presumably only recognize things defined
in actual open standards.  If you provide some way for any extensions
to pass through validators without manual checking to verify that
they're actually openly specified, then anyone can get their
proprietary extension to validate.  This defeats one of the purposes
of standards validators: to validate that a document can be processed
using open standards.

(You can get around this in other ways, of course.  For instance, you
could specify proprietary languages for <object> and <script>, etc.
I've been meaning to submit feedback about this, suggesting that
validators be required to emit errors in more cases here.)

> Few are those
> that can develop their own validator. And even if they can, they cannot
> get all third-parties and clients etc to use _their_ validator - and so
> the extra attributes causes them to loose customer etc because they use
> "invalid code".

As they should, if they refuse to create an open, well-conceived
standard with multiple interoperable implementations.  If they can do
that, on the other hand, the conventional validators won't mind adding
them to the list of applicable standards.

Received on Sunday, 17 January 2010 03:38:27 UTC