Re: Extensibility strategies, was: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

On Tue, 5 Aug 2008, Sam Ruby wrote:
> >
> > You are asking for a way for a third party to develop a syntax for 
> > embedding highly-structured mathematical data into a text/html 
> > document without approaching the HTML standards community, presumably 
> > in a manner that would not be supported by user agents?
> 
> You made a comment previously that I did not understand -- namely that 
> data attributes were "limited to data that is not for use by user 
> agents".  At the moment, my working assumption is that you interpret the 
> term user agents in a manner differently than I do.

By "user agent" in this context I am referring to any software that works 
on HTML documents on behalf of users completely unrelated to the authors 
of the documents that they work on.


> Yes, I am talking about syntaxes that not all user agents would 
> immediately understand. [...] Initially, few would render such.  Some 
> may be able to do so via scripts. Over time, browsers that care about 
> performance will attempt to more directly support the more popular 
> vocabularies.

If the goal of these extensions is to add new features to the core Web 
language without peer review, in such a manner that in due course user 
agents actually supports those features natively, then I do not agree that 
this is a use case we should address. In fact, I believe it is a use case 
we should actively work to frustrate.

It is critically important to the overall health of the Web platform on 
the long term that the features of the platform be developed in the open, 
in a vendor-neutral fashion, with wide peer review.

If you do not agree with this, then we have a fundamental disagreement, 
and I'm not sure that we can proceed without the help of the chairs.


> > [math example]
> 
> That's a bit less verbose than your actual proposal, which would involve 
> longer class names.

Actually only the "math" class would need to be longer if you wanted to 
allow people who are already using the "math" class on their pages to also 
use this feature. The other classes could simply be defined to only have 
meaning in the scope of the "math" class.


> If the criteria described above were applied consistently, then HTML5 
> would not have elements such as article, header, footer, time, or aside 
> which do not actually work in legacy UAs in the context of text/html 
> with javascript turned off.

The whole point of the new elements is that we looked at what classes 
people were using the most, and we provided elements for them, so that 
people didn't have to use extension mechanisms for those semantics.

(The legacy parsing story is poor in HTML4, and this affects the new 
elements in HTML5, but going forward we have resolved this by introducing 
a new parsing algorithm, as you know.)


> I do have usability concerns about a sea of spans.

Sure, you should use the most appropriate fallback element. You'll note 
that in the math example I used <var> and <sup> in various places, not 
just <span>.


In the last e-mail I wrote:

> > Since you have so far rejected all the proposals I have put forward, 
> > and since so far all the proposals you have put forward have only been 
> > incomplete proposals intended to foster discussion (paraphrasing what 
> > you said in an earlier message, sorry if it's not exactly what you 
> > said), could I instead suggest a new approach? Could you concretely 
> > describe your use case, make a full and complete concrete proposal 
> > (intended for the actual spec to use, instead of intended to foster 
> > discussion), and then, if people find problems with this proposal, 
> > actually address those problems and iterate your proposal until we 
> > have something that addresses the use cases and requirements that 
> > everyone has? It's what I've been trying to do so far but it hasn't 
> > worked. I think it is your turn to try.

You did not actually provide such a proposal, leading me to question 
whether you truly want this issue addressed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 5 August 2008 11:50:01 UTC