Re: Supporting MathML and SVG in text/html, and related topics

Ian Hickson wrote on 04/10/2008 05:51:20 AM:
>
> The former has historically been solved by adding custom non-standard
> attributes to elements in the DOM, or by abusing other attributes
> (typically title="") or by encoding the data in painful ways in the class

> attribute (the closest thing to legitimate solution).
>
> I've added a "standard" way to support this: the data-* attributes.

I'm mildly concerned that this is an invention.  And one that does not
properly consider such prior art as RDF/A.  I believe that those that
advocate RDF/A are only asking for two things: for the data to be placed in
the DOM in a predicatable manner (in fact, AFAICT identical to the way that
the HTML5 parsing rules already define), and for such usages not to be
flagged by an HTML5 validator.  I think it is unnecessarily provocative to
not consider such a request.  If HTML5 could simply find a way to not flag
such as errors without necessarily endorsing the usage, I would think that
would be sufficient.

> The second reason to extend the language is to extend the language in a
> manner that is intended to be used by many people, be implemented by user

> agents, and so forth. For this, though, we actively want to make sure
that
> people can't willy nilly extend the language without coordination with
> anyone interested in the development of the language, and therefore I
> haven't provided any syntax mechanism to address this. The right way to
> extend the language is with the involvement of the wider community, as we

> have been doing for HTML5.

For the record, I vehemently disagree with the above statement.  Actually,
I don't disagree with it being the "right" way in many cases, what I
disagree with is it being the *only* way in all cases.  However...

> Now, even given all this, some people still want an extensibility
> mechanism for proprietary extensions. For this, we have XML, which is
> intended to just be a generic syntax. It is quite difficult to make a
> generic syntax out of text/html, due to the legacy content out there. I
go
> into more detail on this in some of the replies below.

I do agree that the above effectively mitigates the issue.

Those that wish to experiment have a vehicle to do so via XHTML5.  It is
severely constrained, but predictable.

If/when the demand for such a vocabulary achieves some sort of critical
mass, there now is precedent for adoption of said vocabularies into the
HTML5 serialization of HTML 5.  While there are minor deviations (e.g.
attribute normalization rules) and things outright not supported (e.g.,
prefixes other than 'xlink' for the xlink namespace, for example), there is
a substantial and useful intersection between the XHTML5 and HTML5
serializations of many DOMs.  This will help not only those that wish to
migrate, but also people like me who write tools like Venus which may not
have precise control over the Content-Type with which the static HTML that
is produced is served.

What remains to be seen is how future vocabularies will be handled.  From
your narrative, I read that there were a number of features that SVG
demanded of HTML 5, and that you made an attempt to generalize this for the
benefit of MathML.  It is entirely possible that this trend may continue
with future vocabularies.  We won't know until such discussions surface.

So, for my part, I'm content to wait until that occurs.  So while we may
agree to disagree on the motivation, I do believe that this draft is a
significant and appropriate step forward at this time.  For that I thank
you.

I'd only like note in closing that appearing in a draft is only
provisional.  Until we actually get implementors signed up and running code
in the hands of critical users, this is all academic.  That represents an
important feedback loop that has yet to be done for this work.  It may very
well result in some changes, hopefully tweaks.  Two such that immediately
come to mind for me: for atleast one implementation, the xmlns attribute
may very well (or may not, who can tell with IE) turn out to be more than
discouraged syntatic sugar or a talisman.  It may turn out to be something
that needs to be recommended for interop purposes.  Secondly, I haven't
thought through the use of <script> inside a SVG element, but it occurs to
me that there is likely to be more work and exploration required.  And
those are just off the top of my head.  Real use will undoubtedly turn up
more.

In closing, I'd like to reiterate: good work, thanks, and now hopefully we
are onto implementing and evaluating...

- Sam Ruby