miraclebg / svgweb

Automatically exported from code.google.com/p/svgweb
Other
0 stars 0 forks source link

Support direct HTML5 embedding #199

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Sam Ruby uses SVG Web on his blog but embeds things in a different,
currently unsupported way. He directly has the SVG in the page, and serves
it as XHTML to all non-IE browsers and as HTML to IE. He only needs IE 8+
to work. He has a special helper script that grabs the source from the page
and then feeds it into SVG Web. He's run into some issues, which I'm not
surprised about since we don't currently support this use case. This bug is
to track getting it to work.

More details from Sam on how he embeds things here:
http://groups.google.com/group/openweb-group/msg/d26c7f22bc66612a

His blog where he is using SVG Web: http://intertwingly.net/

Some users have reported an error on page unload as well; it looks like
this has to do with the fact that we can't get a handle onto the SVG to
clean it up since it's embedded in an unusual way (I think Sam's script
embeds it dynamically with SCRIPT tags but its missing lots of our
machinery). Fix this as well.

Original issue reported on code.google.com by bradneub...@gmail.com on 31 Jul 2009 at 6:14

GoogleCodeExporter commented 9 years ago
Better than testing for IE would be testing to see if there are any elements 
named
svg for which namespaceURI != 'http://www/w3.org/2000/svg'.  This works for all 
the
major browser, including IE, for content served as text/html.

As a special accomodation for IE, I would suggest adding a simple
"document.createElement('svg');" to be executed before the rest of the page is
parsed, as this enables a more XML style markup to be interpreted correctly.  I 
did
find two gotchas: outerHTML will insert "PI" instructions, and will strip quotes
around id tags.  I'm sure that there are more issues that will also need to be 
handled.

A trivial example applying these techniques that works cross browser can be 
seen here:

http://intertwingly.net/tmp/svgns_test.html

Original comment by intertwi...@gmail.com on 2 Aug 2009 at 8:57

GoogleCodeExporter commented 9 years ago
Some other details from Sam for when I get to this bug:

Take a peek at:

http://intertwingly.net/js/jq_localize_dates2.js

In particular, look for "!document.createElementNS".  They key parts
are:

   document.createElement('svg');

That causes IE to parse the element itself differently.

 document.write('<script ...

That hooks in svgweb.

 var script = document.createElement('script');
 script.setAttribute('type', 'image/svg+xml');
 script.text = svg;

That creates the script elements that svgweb expects.  Note: I also
wrap this in a div as it appears that I can't do css styling on svg
elements (yet?).  Feel free to ignore this part.

Beyond that, all I am doing is serving data which can validly be sent
as application/xhtml+xml, and processed by existing browsers that
support that MIME type.  At the moment, I'm avoiding self closing
tags, but that doesn't not appear to be an issue with IE8.  IE's
outerHTML seems to have a number of quirks: removing quotes on id
attributes and inserting a PI which I work around.

Original comment by bradneub...@gmail.com on 10 Aug 2009 at 10:48

GoogleCodeExporter commented 9 years ago
Changing to support direct HTML5 embed type. This would basically directly nest 
the
SVG into a page. There would be some limitations though; XML empty tags would 
not be
supported and casing would get thrown away for custom attributes. Custom 
namespaced
tags would not be supported.

Original comment by bradneub...@gmail.com on 20 Oct 2009 at 12:25