Re: SVG in text/html

On Oct 14, 2007, at 05:02, Sam Ruby wrote:

> Jirka Kosek wrote:
>> Hmm, and why to support SVG (or any other embedded vocabulary) in  
>> HTML
>> serialization at all. XML serialization can be used without any  
>> problems
>> for such purposes. I think that cleaner approach is to switch from  
>> HTML
>> to XML syntax if you want to use XML features. Trying to emulate XML
>> features in HTML syntax is way to hell.
>
> Two reasons:
>
> 1) People often author content which is inserted into a larger  
> context.  Blogs, wikis, comments, are but a few examples.   
> Requiring the entire page to be xml well formed, and requiring that  
> none of the page be displayed if there is any well formedness  
> errors, is a non-starter for most sites.  I'd love to see the day  
> when svg could be copy/pasted into MySpace and MathML copy/pasted  
> into Facebook, and have it "just work".

More generally 3), the same reason we want to introduce *any* new  
HTML5 features in text/html instead of requiring everyone to switch  
to application/xhtml+xml in order to use new features:

There's a vast legacy of systems that have text/html user interfaces.  
It is very rare for these systems to build their text/html output on  
a level of abstraction higher than strings that contain HTML syntax.  
That is, systems built 100% on SAX pipelines, Genshi templates and  
the like that isolate the serilization issues to one small place in  
code are rare. Systems built on print(), PHP, JSP, etc. abound.

These legacy systems could benefit from new markup features such as  
inline SVG as part of the apps themselves. This can be the case even  
when markup isn't being aggregated from multiple sources as on blogs,  
wikis and social software sites, so the issue touches a much larger  
spectrum of apps than suggested in #1 above.

If you have a text/html legacy app, adding a little new feature that  
made use of inline SVG would be too expensive if it required an  
architectural change to the whole front end of the app or the whole  
app when there isn't even a clear separation of front and back ends.  
The ability to use new features in text/html without having to tears  
down what you already have protects the investment in systems that  
are built to produce text/html.

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

Received on Sunday, 14 October 2007 14:39:41 UTC