SVG Technology Writing


I’ve not been the best at keeping up with my writing at my various sites. I have been writing, though.

I have a two-part article up at A List Apart: Using SVG for Flexible, Scalable, and Fun Backgrounds, Part 1 and Part 2. Though Microsoft still hasn’t implemented SVG in IE, with the company’s new membership in the SVG Working Group, there’s new hope for the future. And I cover how to use a JavaScript library, SVGWeb, to work around the lack.

I’m also finishing a new book for O’Reilly: the JavaScript Cookbook. It promises to be a big book, which isn’t surprising, considering how much JavaScript has advanced. I’m also incorporating the relevant bits from the HTML5 specification, though I have to be careful, as we don’t know which bits will remain, and which removed before Last Call.

Speaking of which, I’ve been spending an inordinate amount of time with the HTML WG. I have about a dozen Change Proposals coming up in March, which I’ll write about here, when finished. Among them is one to remove one of the more recent additions, the iframe srcdoc attribute. This example for this new attribute is the following, for weblog comments (the use case for the new attribute):

 <h1>I got my own magazine!</h1>
 <p>After much effort, I've finally found a publisher, and so now I
 have my own magazine! Isn't that awesome?! The first issue will come
 out in September, and we have articles about getting food, and about
 getting in boxes, it's going to be great!</p>
  <p>Written by <a href="/users/cap">cap</a>.
  <time pubdate>2009-08-21T23:32Z</time></p>
  <footer> At <time pubdate>2009-08-21T23:35Z</time>, <a href="/users/ch">ch</a> writes: </footer>
  <iframe seamless sandbox="allow-same-origin" srcdoc="<p>did you get a cover picture yet?"></iframe>
  <footer> At <time pubdate>2009-08-21T23:44Z</time>, <a href="/users/cap">cap</a> writes: </footer>
  <iframe seamless sandbox="allow-same-origin" srcdoc="<p>Yeah, you can see it <a href=&quot;/gallery/cover/1&quot;>in my gallery</a>."></iframe>
  <footer> At <time pubdate>2009-08-21T23:58Z</time>, <a href="/users/ch">ch</a> writes: </footer>
  <iframe seamless sandbox="allow-same-origin" srcdoc="<p>hey that's earl's table.
<p>you should get earl&amp;amp;me on the next cover."></iframe>

Just in case you’re curious, no, I’m not particularly fond of weblog comments as escaped HTML within an attribute on an iFrame.

I’ve also been playing with the new Drupal 7 alpha in my copious spare time. I won’t be moving my sites over to Drupal 7 until a stable release, but I do have a “play” site. I like the new release, though I wasn’t terribly fond of the admin overlay. However, the new admin overlay can be turned off. In addition, I re-posted all of the pages, and comments, from my older WordPress weblog. It takes up little room, and ensures I can find, and link, some of my older work. Plus, folks can find their comments. I was impressed with the fact that WordPress was able to upgrade my old site, without a hitch.

So much to write, so little time. Today, though, it’s snowing, and I haven’t had a walk outside since the weekend. Enjoy the articles at A List Apart, and more writing here, soon.


Celebrating the first day of SVGOpen

Wordle Image of RealTech front page, captured using Skitch and saved as PNG.

PNG file opened in Inkscape, and Trace Bitmap applied. Bitmap options: Multiple Scans, Colors, 5 Scans, with options to stack the scans, and remove background.

SVG finished by running Scour, saving 52.1% of the SVG file size. SVG made cross-browser friendly, via SVGWeb.


SVGWeb and the XML Issue

I’ve been playing around with SVGWeb, liking the library more over time. I re-created the SVG in HTML5 example, and at first it didn’t work. I thought it could be because SVGWeb couldn’t manage the metadata element, but when I loaded the page in Firefox, with Firebug, I found that the SVG/XML still had the bugs I inserted to test whether the Firefox nightly would correct the HTML-enabled errors—the example still had an unquoted attribute, and elements with missing tag ends. In fact, I got XML error messages within the Firebug console exactly I would expect such errors if I loaded the SVG directly in the browser.

SVGWeb manages SVG for browsers that can handle SVG by creating an XML document of the SVG. You can tell, because if you click the circle with the new example, all of the namespaces for the RDF/XML elements are handled properly, even though the page is parsed as HTML. To me, this is the way SVG should be handled in a document, whether the document is parsed as HTML or as XHTML. This pretense that SVG is not XML when its in HTML is patently absurd. It doesn’t map to anything that exists in the real world.

The SVGWeb library is a wonderful tool, but I would really prefer all that functionality be embedded directly in the browser handling of SVG in HTML. I read the past discussions on SVG in HTML, about how trying to maintain the XML nature of SVG within HTML would require “exceptional parsing rules”, or something of that nature. It seems, though, that SVGWeb is managing the issue just fine, and doing so without having to make one change to any parser for any browser. SVGWeb works by generating a SVG document and inserting the document into the DOM (if the browser supports SVG). Technically, this is little different than what happens for inline SVG in XHTML now. So why is this a perfectly acceptable approach when using script, but not acceptable when not using script?

I’m also aware of the discussions about mixing content, such as SVG in MathML, and MathML in SVG, and HTML5 in both. I made another copy of the example, this time inserting an HTML5 paragraph element into the SVG. Since the syntax I used was proper XML (no unquoted attributes, closing paragraph), it parsed without an error, but the paragraph didn’t display. Of course not, because there is no paragraph element within SVG, and the SVG is treated as an SVG document, not an SVG in HTML document. The thing is, though: the paragraph wouldn’t do anything in SVG within an XHTML document today.

However, returning to the example I linked earlier, I did insert HTML into the SVG using the SVG foreignObject element, with proper syntax, and as you can see, the HTML does display correctly. In fact, if you scroll down, I also created a second SVG element, this time with MathML as the foreignObject contents, which renders fine in Firefox, and partially everywhere else, depending on MathML support.

All of this works, and works well, when using SVGWeb. You can even access namespaced Rdf/XML elements in the XML, using the proper namespace functionality, but the page still validate using All of the portentous grumblings about the horrors of mixing HTML and XML just don’t ring as ominously when one can see that, contrary to the dire warnings, and tales of potential woe, the two can mix. Unfortunately, the only way to mix the two, now, is to be dependent on a Google JavaScript library. Don’t get me wrong: I’m grateful for the library. So grateful, in fact, that I don’t recommend the use of SVG inline with HTML unless you use this library.

I just don’t like being dependent on JavaScript for that which should be and can be, natively supported in a browser. This approach requires library intercession for all instances of SVG use, which means the SVG markup won’t be accessible to server-side applications that disregard the script element. This JavaScript dependency also means the SVG won’t be visible if scripting is disabled, even though SVG does not require scripting support. When scripting is enabled, the approach is still inherently inaccessible.

These are the two choices facing us with SVG in HTML: SVG/XML treated as HTML, and all the problems this causes; or SVG/XML treated as XML, but requiring JavaScript.