[whatwg] Inline SVG

Simon Pieters zcorpan at hotmail.com
Fri Dec 8 09:00:19 PST 2006


Hi,

From: "Leons Petrazickis" <leons.petrazickis at gmail.com>
>How about this for HTML5:
><object type="image/svg+xml">
>    <svg version="1.1" xmlns="http://www.w3.org/2000/svg">
>        <circle cx="100" cy="50" r="40" stroke="black"
>stroke-width="2" fill="red"/>
>    </svg>
></object>

OBJECT has to be parsed as PCDATA for backwards compatibility, and 
introducing yet more features to an already overloaded element is probably 
not a good idea.

However, this already works:

<object type="image/svg+xml" data='data:image/svg+xml,
    <svg version="1.1" xmlns="http://www.w3.org/2000/svg">
        <circle cx="100" cy="50" r="40" stroke="black"
stroke-width="2" fill="red"/>
    </svg>
'></object>

>And this for XHTML5:
><object type="image/svg+xml">
><![CDATA[
>    <svg version="1.1" xmlns="http://www.w3.org/2000/svg">
>        <circle cx="100" cy="50" r="40" stroke="black"
>stroke-width="2" fill="red"/>
>    </svg>
>]]>
></object>

This is not needed for XHTML5; XML already supports namespaces so you can 
just put the elements there directly:

   <svg version="1.1" xmlns="http://www.w3.org/2000/svg">
       <circle cx="100" cy="50" r="40" stroke="black"
                 stroke-width="2" fill="red"/>
   </svg>

>If that's over-complicating the semantics of <object>, we could
>introduce an inline <xml> tag that's similar to the inline <script>
>and <style> tags. It would have a type="" attribute to specify the
>mimetype, and its contents would be within a CDATA block in XHTML5.

It's not clear to me why we want to embed "XML" in HTML, and such a feature 
would be completely redudant in XHTML5 because XHTML5 *is* XML.

IE's <xml> isn't really used on the Web -- the idea is already implemented 
and it didn't get popular.

If the use-case is to embed SVG in HTML then we could either:

   * use embedded elements (which allows for fallback content)
   * use XBL
   * Make <svg> elements and its descendants be put in the SVG namespace (or 
similar processing model)

The first option already works. The second option will work once XBL gets 
implemented. Given that inline SVG is presentational, doesn't allow for 
fallback content and breaks in legacy UAs when using SVG's text features, 
I'm not sure we want the last of those options.

And even if we did want inline SVG, there's no need to (re)parse it as XML. 
You don't need to parse XML to build an SVG DOM.

Regards,
Simon Pieters

_________________________________________________________________
Alla lediga jobb för bartenders http://jobb.msn.monster.se/




More information about the whatwg mailing list