Re: Decentralised extensibility idea (ISSUE-41)

Tab Atkins Jr., Mon, 18 Jan 2010 08:56:10 -0600:
> On Mon, Jan 18, 2010 at 1:18 AM, Leif Halvard Silli wrote:
>> Tab Atkins Jr., Sun, 17 Jan 2010 10:25:08 -0800:
>>> Ah, I think I've been misinterpreting your proposal's intent, then.
>> 
>> That is quite remarkable - given the subject line, and all.
> 
> Seriously?  Is that necessary?  Back up a bit.

"Re: Decentralised extensibility idea (ISSUE-41)" 

>>>  I don't believe that the HTML
>>> language *should* be extended in a distributed manner, where anyone
>>> can publish some half-baked vocab extension and see it recognized.
>> 
>> So opposition against namespaces was just a play: It is extensibility
>> itself that you are against.
> 
> I'm not sure what the reference to namespaces was about at all; I've
> commented very little on them personally (though I agree with much of
> the objections to them).

I admit that it was a broad generalization rather than specifically at 
you.

> The only reference to namespaces in this
> thread was referring to them in the same breath as Microdata and RDFa
> as generic extensibility mechanisms.
> 
> But you are correct, I am against precisely what I just said - I don't
> think that HTML should be easily extensible by random authors.  It
> should require some relatively substantial quality bar, ideally a
> public spec, before an extension is deemed valid.

Toby's DE requires that a specification is published. Whether a HTML 
consumer will implement that spec depends, I guess, entirely on the 
spec. The spec could also, btw, simply describe something that is 
already implemented - much the sam way that HTML5 in many aspects tries 
to do.

> (There are very specific reasons why I'm against this in the case of
> HTML; I am, after all, a Lisper as well, a language in which extending
> it is part of the natural process of programming!  A standard
> programming language can innovate however it likes, as it all gets
> turned into generic machine code before being sent to the user.  HTML,
> though, is a public communications language, and only gets 'compiled'
> into a page at the client.  It is in the public interest to keep the
> language uniform and predictable, and only change it in an open
> process that everyone participates in.)

When you extends a programming language, then it affects only you or 
your programming team. HTML isn't like that.

>>> The "applicable specification" clause ensures that the extension is
>>> accepted by a large enough group of people to make the validator
>>> authors recognize it, which is a reasonable minimum quality bar.
>> 
>> We don't really know how the "applicable spec" mechanism will work. But
>> I don't think we'll simply hand it over to the validator team to tell
>> what it is.
> 
> Why not?  What bar should be set?  Who should decide it?

This group should decide who should decide it, at least.

>  It is in a
> validator's best interest to reflect popular usage; if there are
> popular specs that they flag as invalid, people will stop using them.
> They seem like the *perfect* place to assign as the 'quality guardian'
> here, as they are the only group with the correct incentives set up by
> default.
>
>>> It also ensures that, when such a specification *does* become popular
>>> enough to be recognized, it's using first-class pieces of the language
>>> - plain attributes and element names - which are much easier to
>>> author.
>> 
>> Do you have concrete examples of *invalid* features that have become
>> accepted - attained "applicable specification" status in this manner?
> 
> RDFa is on the track to becoming just that.  I'm not certain if any
> validator recognizes it quite yet, but the way it's developed is
> precisely how the applicable specification clause is meant to be used.
>  And though I don't like the way RDFa works, I'd like it even less if
> it was embedded via some extension mechanism, rather than using
> attributes directly.

I agree that "applicable specifications" should be "using attributes 
directly". It would be a kludge if Microdata or RDFa-in-HTML worked 
just like Toby's DE proposal. However, RDFa-in-XHTML doesn't use 
attributes "directly" - it instead uses a DTD which makes the needed 
attributes valid. A DTD does however seem mostly like a validation 
tool.valid. 

The way RDFa has "made it" is by becoming popular in formally XHTML, 
which in reality mostly is text/HTML. Perhaps you would suggest using 
such path, in general? At least XHTML is more like Lisp, there, in that 
it allows you to extend the language. 
 
>>>  Forcing language extensions into an embedding ghetto just
>>> ensures that they'll always be difficult to use.
>> 
>> We cannot expect that someone that wants to solve a problem joins a
>> Working Group desert for 3 to 6 years in order to solve the problem at
>> hand.
> 
> If they want to solve a problem that requires browsers to respond to
> the new markup, then they most certainly *do* need to do so.  What, do
> you think there's some magic switch that people can throw and
> automatically get their features implemented interoperably in every
> browser?  

No.

> It takes time to go from a full, complete spec to wide
> adoption.  Most specs that don't pass through a standards body never
> reach the "full, complete" phase (for that matter, many of the specs
> that do pass through a standards body don't reach it either, but we at
> least have a somewhat higher success rate).  A buggy spec leads to
> buggy (or even perfectly conforming, just not-interoperable)
> implementations, which leads to author difficulties.

Why do you assume that a DE vocabulary/spec would not take time to 
develop so much that it would be useful for many?

> If they're solving a problem that *doesn't* require the browsers to
> cooperate and do something new, then why do they care in the first
> place?

They would be using Toby's DE system precisely because they need 
browsers and validators to cooperate. When it comes to "do something 
new", then it might be that they don't need /all/ HTML 
consumers/producers to do something new. They could just be needing 
that a UA extension, or web engine adaptation, "does something new". 
Thirdly, a language isn't only meant to cause UAs to behave in a new 
way, a new language can also get the programmer to behave in a new way. 
E.g. the DE via @profile system would could also be combined with 
Microformats/RDFa: You could define a certain class name for those 
elements that you would microformat/RDFa-format in a certain way.

>  You don't need a standards body at all then.  Just do your
> thing, and if it gets popular enough, validators will recognize it and
> it will stop being invalid.

This seems far from the freedom you have in Lisp ... 

One of the reasons given for developing Microdata was that it would 
allow authors to develop vocabularies that possibly would be used only 
a single time. Of course, Toby's DE system would likewise allow authors 
to define a language within HTML which perhaps would have only a single 
implementation.

>> Toby's DE system allows many things to be tested. 

Expl: New concepts and ideas could be tested. It would be a low bar for 
showing a concept.

>> It also allows best practises to be specified. It allows User Agents
>> quirks to be documented and put into a "language".

Expl: The Web is full of an unsystematic collection of browser bugs and 
tricks. A Web page maker needs to use search engines to find them all - 
if he wants to be compatible with "the Web". Some of these tricks have 
made it to HTML editor/text editors, so that you can just select these 
tricks as if they were part of HTML.

A class/profile based DE system could let you create a "language", by 
seeking out - and developing - _valid_ tricks to deal with the Web. 
Then, instead of using search engine X to locate all the billion hacks, 
I could use profile="X" as a coding standard.

As an example, IE6 and IE7 have particular bugs w.r.t. which selectors 
and "fake properties/wrong syntax properties" they accept and don't 
accept. There are valid CSS selectors that they don't recognize. And 
there are invalid ones that they recognize. A huge amount of pages 
documents invalid IE tricks. 

A DE profile could document valid IE tricks. The preferred valid CSS 
tricks, in my book, are based on CSS selectors. CSS selectors are often 
class names and other HTML features. Thus a DE could define a 
"language" consisting of class names and coding practises. Some direct 
HTML parsing bugs can also be linked to class names: The presence of 
class X in element Y means that the children or parent of element X 
have been coded in such a such way to be compatible with this and that 
UA.

Thus, by staying compatible with HTML standards, DE profiles could help 
circumventing browser bugs, in order to implement the Web as it is 
specified.

I doubt that a W3 wg would devote itself to develop a sublanguages for 
dealing with the "real" Web. Ever! No matter what you say it should. UA 
vendors are occupied with their own standards support and also happily 
bash other UAs. But developing a valid "language" through which one can 
circumvent UAs, is not their task. And, probably, rightly so.

>> Basically, it is perfect system for developing and detecting (!)
>> Cowpaths. Should therefore be the perfect extension system for a
>> cowpath considering working group.

Expl: I think I say: See above.

> I'm not sure what magical powers you're reading into Toby's proposal.
> I either don't understand the points you're talking about, or don't
> see how they're different from the other extensibility mechanisms that
> have been accepted or discussed.

The language of the Web isn't even captured in HTML5. I added inline 
comments above to help you understand.

>> Of course, if the extension is really useful, then one can turn the
>> things into "real" elements and attributes. What's the problem?
> 
> Once a pattern has set in, it's very difficult to change.  If there is
> a convenient and simple way to upgrade into real elements and
> attributes, I'd like to see it explained precisely.

It is not necessary that a DE pattern "sets".

<span class="time" profile="URI" data-datetime="2007">
Two thousand and seven</span>

I believe that the <time> element has partly developed from attempts at 
solving the same problem in the microformats context. And microformats 
are very close to Toby's proposal. I don't think that <time> has 
suffered any problems because of this. On the contrary, I think <time> 
learned from the microformats trial and errors. Toby's proposal would 
however have allowed to create a microformat that was much closer to 
<time> than HTML4's profile system allows - so that it could have 
avoided e.g. misusing @title in <abbr> for this very purpose.

What would eventually the difficulty be in turning <span class="time"> 
into <time>? Do you refer to the difficulty you could experience in 
convincing the relevant people that we actually need <time> when we 
already have <span class="time">?

> That skips around the issue that I've already raised, though, of why
> one shouldn't just use real elements and attributes in the first
> place.  It's easier and simpler to just do so, and once your extension
> is a success it becomes valid as well.

Because the amount of people who develop class names are billion times 
higher than those who develop elements. The Web would be a true mess if 
one developed elements instead. Besides, HTML5 say that one should not 
use features that are not part of HTML5.

>>> The one realm where unilateral extension of the language *is*
>>> recognized to be useful is in experimental implementations by browser
>>> vendors,
>> 
>> I have not perceived this to be unilateral. OK, it works fine for CSS.
>> But if all the 4 big Web browser vendors each operated with their own
>> <time> element (<moz-time>,<webkit-time> etc), then it would be hell
>> for authors to try it out.
> 
> Indeed, direct extension by adding new elements is a bad trip.  This
> has been hashed out before; HTML's element names are *not* extensible
> in a useful way.  There are ways around this, though - HTML attributes
> are extensible in the correct way (they have the correct fallback and
> combining behavior), and so we can exploit that instead.

So what was your use case then? Were is <browserElement> useful?
 
>> OTOH, I think that CSS selectors and HTML *attributes* have much in
>> common, and with Toby's DE _then_ it would be possible to operate with
>> vendor prefixes. For example experiments with the <time> element could
>> be performed like this:
>> 
>> <span class="time -moz-time -o-time -ie-time -webkit-time"
>>      data-datetime="2007-10-05"
>>      profile="http://w3.org/html5-experimental"
>>     >October 5</span>
> 
> What value is added by the profile?

A URI. It ensures that the elements can be interpreted in the meaning 
specified in the spec at that URI. Otherwise, without the profile, 
class names are completely semantic free.

>> In markup, vendor prefixed elements will cause a lot of authoring hacks
  [...]
> Again, I agree.  Vendor-prefixed elements would be horrible.  We
> already know this.  Vendor-prefixed attributes, on the other hand,
> have similar fallback and combination abilities as vendor-prefixed CSS
> properties and values.

So you actually do not see any use for such prefixes in HTML?
-- 
leif halvard silli

Received on Monday, 18 January 2010 19:00:17 UTC