Re: SVG and MathML in text/html

On Mar 11, 2008, at 11:16, Doug Schepers wrote:

> Jeff Schiller wrote (on 3/10/08 7:21 PM):
>> On Mon, Mar 10, 2008 at 4:44 PM, Henri Sivonen <hsivonen@iki.fi>  
>> wrote:
>>> On Mar 10, 2008, at 23:14, Jeff Schiller wrote:
>>>
>>> I meant that a text/html doc with SVG inside it won't be readable by
>>> existing SVG tools and viewers in general, because the surrounding
>>> HTML almost always isn't well-formed and because the tools probably
>>> aren't expecting some non-SVG stuff around the SVG markup. In your
>>> sample case the HTML happens to be well-formed if treated as XML but
>>> this is not generally true of HTML.
>> Thanks for clarifying Henri.  I was talking from a copy-paste
>> perspective.  For instance, it's perfectly conceivable that someone
>> might view > source, take the <svg> snips out into their own text
>> editor and bring the SVG up in a SVG editor like Inkscape.  I've done
>> this and it works quite nice...
>> But I agree that editors would have a problem with the surrounding
>> HTML "cruft", which I wouldn't expect them to handle.
>
> Jeff has stated my own concerns eloquently, so I won't repeat them  
> (especially since you and I already had a similar conversation on  
> IRC).
>
> In addition to the use case of extracting the SVG from an HTML  
> document for the purpose of editing it, there is the strong case for  
> reuse.

I agree that extracting an SVG part of a text/html page and taking it  
into an SVG editor is a worthy use case. But I think defining  
conformance in an XML-like way is not an effective way to achieve it.

The conformance definition is not an effective way to achieve it,  
because with non-Draconian error handling, there *will* be a non- 
trivial proportion of instances where the embedded SVG island does not  
adhere to the conformance criteria and, therefore, won't parse as XML  
if extracted on the source text level.

I am assuming non-Draconian error handling for two reasons:
  1) Experience with XML has shown that Draconian error handling is  
worse than defined error recovery for Web formats.
  2) Draconian error handling would be bad strategy since it would  
work as an implementation deterrent: If a new browser can throw a  
fatal error on a page that legacy browsers parse to the end (even if  
the SVG parts don't render), the new browser risks losing market  
share, and browser vendors generally avert changes that would lead to  
market share loss.

I think there are two ways of addressing the editing use case more  
effectively:
  1) Making the browser serialize a DOM range into XML (roughly like  
View Selection Source serializes from the DOM in Firefox) and copying  
and pasting the result as opposed to copying and pasting source.
  2) Adding a text/html parser to the SVG editor.

> The fact is, there is a very large deployed base of SVG UAs on  
> mobile devices, many hundreds of millions, that cannot easily be  
> upgraded or revised.  Deliberately making incompatible changes to  
> SVG such that the resulting content will not be viewable on the vast  
> majority of deployed UAs is a very risky strategy, one that I don't  
> think can be taken so lightly.

Note that putting SVG in an text/html wrapper breaks compat with those  
viewers *anyway*. Whether attributes are quoted doesn't matter at that  
point.

On Mar 11, 2008, at 11:16, Doug Schepers wrote:

> Henri Sivonen wrote (on 3/10/08 3:03 PM):
>> Allowing inline SVG in text/html is an interop problem with  
>> existing UAs no matter what. The justification for introducing such  
>> an interop problem is the assumption that the non-inlineability of  
>> SVG in text/html is holding SVG back and enabling SVG in text/html  
>> would allow SVG (in the sense it exists as a DOM language) take off.
>
> I disagree that this is what is holding SVG back.  I believe that  
> one of the major things that's held it back is that, until the  
> couple of years, there have not been desktop SVG User Agents that  
> implemented a complete and interoperable enough subset of the spec  
> to make it useful for authors to deploy.

Yes, the lack of UAs has held SVG back. One could speculate on the  
relationship of lack of text/html integration and pressure to implement.

Anyway, lack of text/html is holding back using SVG as an inline  
progressive enhancement as in Sam Ruby's blog:
http://intertwingly.net/blog/

Those SVG icons are nice to have. They are not essential, so losing  
the visibility of the text content in IE would be an unreasonable  
trade-off. Moreover, unlike Sam, normal people use content management  
systems they didn't write themselves and that they cannot easily patch  
to be well-formedness bullet-proof.

As it stands, a random Web author whose publishing workflow is just  
putting static files in a directory somewhere cannot easily use this  
progressive enhancement, because making the main content visible in IE  
while making the enhancement visible in Gecko/Opera/WebKit would  
involve tweaking mod_rewrite which may not even be available for  
tweaking.

For a random author using a typical PHP blogging system (which could  
be patched to vary the Content-Type header with relative ease),  
turning all the bogo-XHTML output into real bullet-proof well-formed  
XHTML output is too big a hurdle standing in the way of dropping some  
SVG inline.

When people find that adding SVG eye candy is too hard and continue  
without adding it, the existing installed base of SVG viewers doesn't  
win. However, SVG as a plausible DOM language loses.

> Obviously, the other thing that's held it back is the fact that  
> Internet Explorer has not yet implemented it natively.

More to the point, making inline SVG work elsewhere, the document has  
to be served using a content type that hides even the XHTML parts from  
IE. This pretty much defeats the progressive enhancement use case  
whereas the lack of all SVG support in IE is a problem when the SVG  
images are essential content.

> Now, SVG is much more widely deployed, and implemented natively and  
> well on 3 of the 4 major browsers.  IE's browser share is declining  
> steadily, making the browsers with native implementations much more  
> important, despite lack of support in IE.

The bulk of complexity in those implementations is above the DOM  
layer, though. It is already possible to inject SVG elements from JS  
into a DOM initialized from text/html, but doing so is hard. It seems  
silly not to tear down the last barrier.

On Mar 11, 2008, at 11:16, Doug Schepers wrote:
> Henri Sivonen wrote (on 3/10/08 4:51 PM):
>> Pure technology value is a characteristic of a given technology  
>> without regard to how it interacts with other stuff. For example,  
>> the number of polygons a game console can shade per second is a  
>> characteristic of the game console that doesn't depend of external  
>> factors. A game console becomes more valuable when there are more  
>> games available for it and more games become available as there are  
>> more console units sold. A game console with higher shader  
>> throughput but no games is of no value compared to a less  
>> performant console that has a lot of games available for it. When a  
>> new console with almost no games is launched, it is less valuable  
>> than a console from the previous generation with a lot of games. A  
>> smart strategist creates the new console to leverage the network  
>> effects of the existing ecosystem by making the new console  
>> compatible with the games of the previous generation.
>> XHTML totally failed to use the well-known strategy of leveraging  
>> the existing network effects by being compatible with the installed  
>> base of the previous technology generation.
>
> I strongly agree with you here.  I think that that was a serious  
> failing of the deployment of XHTML.
>
> I also want to emphasize, however, that the same situation obtains  
> in reverse here.  SVG already has a wide deployment base on mobiles,  
> and in legacy viewers, that demands strict content (with the odd  
> exception in the case of namespace declaration in Adobe's viewer).   
> The network effect would be critically lessened if an incompatible  
> serialization of SVG were deployed, as I said before.

Indeed, enabling SVG in text/html would not tap into the network  
effects of the existing SVG viewer installed base. (It would tap into  
existing SVG renderer code, tough. And to the network of SVG creation  
tools.)

There are different network effects to tap into. After all, XML did  
plug into an existing network--SGML--but that ecosystem was less  
important for Web success than the text/html ecosystem derogatorily  
dismissed as tag soup.

The idea of enabling SVG in text/html assumes that tapping into the  
network effects of text/html on the open Web (the ultimate network  
effect?) is more important than failing to enrich the existing network  
of SVG-enabled handsets directly. Note that enabling SVG in text/html  
would drive demand for improvements in code that would be shared  
between serializations in software that'd end up supporting both and  
would drive demand for SVG creation tools. So I do believe SVG in text/ 
html would give a boost to SVG on the whole.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 11 March 2008 14:28:45 UTC