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

Ian Hickson wrote on 08/05/2008 12:50:24 AM:

[[I will note up front that this email does not pose any questions that
require an answer]]

> On Mon, 4 Aug 2008, Sam Ruby wrote:
> >
> > The most I have ever argued for is not to take namespace prefixes off
> > the table prematurely.
>
> When would you say it would become appropriate to take namespace prefixes

> off the table, then?

When there is a concrete syntax adopted that people will actually use that
enables decentralized parties to create their own language.

> I do not believe anything was prematurely taken off the table, we did in
> depth analyses before deciding against such mechanisms. Eventually we
have
> to make some decision. That decision presumably has to be based on data.
> As far as I know we have all the data we're going to get. Is there data
> that I haven't considered which would argue for not yet taking prefixes
> off the table?

Provisionally deciding.  And without creating a concrete syntax that people
will actually use that enables decentralized parties to create their own
language.

> > As to your main point: no question that a single, isolated div or span
> > is usable.  However, issue 41 is about enabling third parties to create

> > their own languages.  SVG and MathML were given as examples.  I realize

> > that MathML has subsequently been accepted (provisionally) into HTML5,
> > but consider what it would take to represent the following page into
> > HTML5 had that not been done:
> >
> > http://golem.ph.utexas.edu/~distler/blog/archives/001758.html
> >
> > If you can show a usable syntax for the above page given the notation
> > you suggested, then my appologies.
>
> 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.  Yes, I am talking about syntaxes
that not all user agents would immediately understand.

> Just so that I understand the request, how would one obtain interoperable

> renderings of such a language? Would one use scripting, CSS and XBL?

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 so, then the class="" attribute mixed with existing HTML semantic
> markup seems like a perfectly adequate solution already, as in:
>
>    <p>We'll work in Euclidean signature. Let <span
>    class="math"><var>M</var></span> be a Riemannian 4-manifold, and <span

>    class="math"><var>V</var><span
>    class="mo">&#x2192;</span><var>M</var></span> a complex vector bundle
>    with unitary connection.</p> <div class="math"><var>D</var><span
>    class="mo">:</span><var>&#x393;</var><span class="mo"
>    data-stretchy="false">(</span><span class="msup"><var>S</var> <sup
>    class="mo">+</sup></span><span
>    class="mo">&#x2297;</span><var>V</var><span class="mo"
>    data-stretchy="false">)</span><span
>    class="mo">&#x2192;</span><var>&#x393;</var><span class="mo"
>    data-stretchy="false">(</span><span class="msup"><var>S</var> <sup
>    class="mo">&#x2212;</sup></span><span
>    class="mo">&#x2297;</span><var>V</var><span class="mo"
>    data-stretchy="false">)</span></div> <p>is the usual chiral Dirac
>    operator.</p>
>
> I was about to say that this is in fact no worse than the actual MathML
as
> seen on the site you cited, but actually, it's better. It actually works
> in legacy UAs, for one! It also doesn't need any explicit namespaces,
> which in the original are very verbose.

That's a bit less verbose than your actual proposal, which would involve
longer class names.

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.

> > Issue 41 is about enabling decentralized parties to create their own
> > languages.  Taking options off the table prematurely and proposing
> > unusuable syntaxes are not consistent with furthering a constructive
> > conversation on the topic.
>
> class="" isn't unusable. Indeed, the Microformats community has shown
that
> it can be used as the basis for multiple quite detailed vocabularies
> successfully.

class attributes are useful -- for the purpose that they were designed.
They even are useful in limited use outside of that domain, and suffer from
a number of problems even there.  I do have usability concerns about a sea
of spans.  In fact, if I remember correctly you once said something along
the lines that if you could figure out a rule which enabled web pages which
overused such elements to be flagged, you would make it so that such pages
would not be considered valid.

> > I appologize that I don't quite have the same number of cycles to
devote
> > to this issue as you have.  I am trying to keep up.
>
> I don't have that many cycles. I've been spending my free time on this
> trying to get something that can address all use cases including yours,
> because, well, actually I'm not sure why. Several people have asked me to

> stop responding to you.
>
> 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.

In the course of over a year discussing this topic, I've only seen one
proposal put forward by you.  I've ceeded that it meets the stated
requirements, but suffers severely in terms of usability.  I've now also
noted a few inconsistencies that come to light when the proposal is
evaluated in the context of both the design and with the stated direction
of HTML5.

Over that time, I've also seen a number of other proposals put forward by
myself and others, all to the same or greater level of detail as the one
you put forward, only to be met with sarcasm, stonewalling, and moving
goalposts.

Despite the stated goal of bringing vendors to the table, it does not
surprise me that more vendors do not chose to do so.

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

- Sam Ruby