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

Ian Hickson wrote on 08/05/2008 07:49:27 AM:
>
> 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.

I played that game for many months, leading to a concrete proposal over a
year ago.  The proposal from a year ago had considerably more detail than
the class based design that you have briefly sketched out.  I've since seen
many such proposals rejected for reasons that would cause much of the
current HTML5 design to be questioned.  For example, much of the
conciseness of the class based approach is due to indirection and nesting,
meaning that if one were to copy/paste an individual line to another file,
it wouldn't work.  I've seen that given as a argument against prefixes.

I agree with you that it is time for the chairs to weigh in.

- Sam Ruby