Category: SVG

All about Scalar Vector Graphics (SVG)

Categories
SVG

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 Validator.nu. 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.

Categories
SVG

SVG in HTML

I’m writing an article on using SVG for site decoration and backgrounds. Since SVG is now allowed in HTML via HTML5, it seemed a good time to introduce people to the concept. Especially since the nightly build of Firefox 3.7 has a configuration option (“about:configure”) where you can enable HTML5.

To test the new option in the Firefox nightly, I created a simple file, with a SVG red circle that can be resized with JavaScript. (HTML5 version and XHTML version).

Clicking on the circle will resize it, but also throws up some alerts outputting information about metadata in the element, including namespace, prefix, and element tag name. I wanted to see how Firefox parsed the SVG via HTML, as compared to XHTML. After all, it’s not unusual for SVG files to have namespaced entities in them, for metadata (Creative Commons RDF/XML), or even placed by a tool (Inkscape).

The results are about what I expected. The namespace, prefix, and tag element name all displayed according to their namespace goodness in XHTML, but the namespace didn’t work with the HTML parsing.

To me, this isn’t a showstopper. People who have been working with the DOM and JavaScript have had to deal with differences through the years, such as event handling differences between IE and the rest of the browser world. You just check to see MIME type of page, and either expect to look for the localname as a mashup between prefix and local name, or it’s handled properly.

It’s a little *challenging because prefixes aren’t always going to be the same. However, for the most part, if you need to access the data, you can either control the prefix used, or you can work through the differences without having to resort to rocket science. I rather expect both Dojo and jQuery to incorporate this functionality, once HTML5 gets wider use.

I also have been trying the new SVGWeb product from Google, and fine folks like Brad Neuberg, which enables SVG in HTML for all browsers, including IE. It does this by incorporating a JavaScript library that implements most of the SVG in Flash. Since Flash is pretty much ubiquitous, folks won’t have to install something new for the page to work.

I’ve used SVGWeb to manage the background image for The SVG Feed, which is now formatted as HTML5, and served as HTML. It works nicely in Safari, Opera, Firefox, and even SVG-challenged Chrome, but IE has a problem. Unfortunately, height and width are handled differently with IE as compared to the other browsers, so the values are coming up null in IE. However, Brad has added this as a bug, and I expect this page will work in the next iteration of the product.

Now, there are some differences between SVG parsed by an HTML5-enabled browser, and using SVGWeb. My earlier example embedded SVG directly in the page, but SVGWeb expects an inline SVG element to be enclosed in a script tag:

<script script type="image/svg+xml">
<svg...
</script>

Embedded SVG in a script tag won’t work if you’re only dependent on HTML5 parsers. However, SVGWeb also works with HTML5 parsers, so you’re set, either way.

Until all browsers support SVG, in HTML or XHTML, SVGWeb provides the first real breakthrough in using SVG on the web. And here you thought that SVG was only good for **Scrapbooking.

*It’s a little more challenging for server-side applications parsing the web page, but again, the differences aren’t insurmountable.

**The background SVG I’m using for my site originated as a scrapbook pattern for the cutting machine, Cricut.

Categories
HTML5 SVG Technology

Separating Canvas out of HTML5

The HTML 5 specification is too large, that’s a given. Too large, and too diverse. With the merge of the DOM into the specification, as well as an attempt to cover two different serializations, not to mention the microdata section, it’s difficult to describe the HTML 5 spec as an “improvement on HTML 4”, which is what the HTML WG’s charter specifies. Kitchen sink comes to mind, and kitchen sinks don’t make good specifications.

One simplification of HTML 5 I would make is to remove the Canvas section from the specification. Instead, I would reduce the Canvas section down to coverage of the syntax for the Canvas element, similar to what’s happening with MathML and SVG, but remove the guts of the object to a separation specification. Or don’t move the Canvas object to a separate specification, but don’t leave the object in HTML 5.

I read through results of the three votes associated with Canvas, or should I say, “immediate mode graphics API”. Two of the votes had to do with the WG charter and creating a tutorial about the Canvas element, and one was specifically about splitting the Canvas element out.

The vote was overwhelmingly against splitting the element out, but also against not updating the charter to reflect the fact that including the Canvas element is outside of the group’s current charter. Frankly, this was undisciplined, and at that point in time, the W3C Director should have stepped in to remind the group about what the charter is, and the importance of adhering to it.

Looking again at the vote about not splitting the Canvas object into a separate specification, you can see immediately that few people are really enthusiastic about keeping the Canvas element in the HTML 5 specification. However, they were even less enthusiastic about doing the work necessary to split the Canvas element into a new specification, and developing a group to support the new spec. Being disinterested in starting a new working group does not make for a compelling argument for keeping Canvas in HTML 5.

Now we’re seeing problems arise by that bad decision. There have been numerous recent discussions about Canvas and accessibility, and it isn’t difficult to see that work on Canvas accessibility needs to continue, probably for a significant period of time; possibly long enough to impact on the timeline for the Last Call for HTML 5.

In addition, there is a very real concern that the same governments that mandate against JavaScript because of accessibility will also mandate against Canvas for the same reason, because Canvas is dependent on JavaScript. Yet the Canvas element is integrated into the HTML 5 specification. The end result could be a slower roll out of HTML 5, perhaps even a reluctance to adopt HTML 5. I hesitate to say there may be a ban against HTML 5, but there is that possibility, too, slight as the risk is.

Most importantly for the folks who like the Canvas object, it’s now tied to the same schedule of the HTML 5 specification. This means that if we want to expand the Canvas object at same later point, we have to do so in conjunction with a new version of HTML. This tie-in makes absolutely no sense. When you consider the increasing capabilities being built into Flash and Silverlight, Canvas also needs room to grow. Now, the HTML WG has effectively boxed it in, limited its future expansion, and probably helping to hasten its future obsolescence. Of course we still have SVG, which is not integrated tightly into the HTML 5 specification, and can continue to grow and expand. Good for SVG. However, I happen to believe that it’s healthy to have both graphics capabilities—but only if both have room to grow.

It wasn’t up to the HTML WG to insist that the Canvas element either be included in the HTML 5 specification or some other formal working group. The group can’t just grab things in, willy nilly, like crows grab a piece of tinsel because it sparkles in the sun. Oh! Me want! Me want! If people are interested in the object, they’ll work to help standardize its use. If they aren’t, then it will continue as it has in the past, based on informal agreement among four of the top five browser developers. At least then it won’t get stuck being permanently embedded in an HTML specification.

Categories
SVG XHTML/HTML

Whipping boy

I noticed a passing twitter message from Laura Scott. It said One word: standards. Firefox follows w3c standards. Internet Explorer does not. She wrote it in response to another Twitter message from tutu4lu, who was having problems with a web page appearing differently with IE than Firefox.

It is true that Firefox implements more standards than IE, especially in when it comes to some of my favorites, such as SVG. And I appreciate the fact.

Firefox does not necessarily get an A+ for all of its effort, though. In particular, if Microsoft’s lack of implementation of XHTML has been one force against broader implementation of XHTML at web sites, Firefox’s own handling of XML errors in XHTML is another, more subtle force against XHTML.

Here’s an example. I added an ampersand (&) to a URL in one of my posts, which generates an XHTML error. The following are three screen shots from Chrome, Opera, and Safari, respectively, that demonstrate how they handle the error:

XHTML error in Chrome
Opera XHTML error
Safari error

Safari and Chrome are both built on WebKit, which handles XHTML errors by parsing, and rendering, the document up to the error. This has the advantage of providing some content, as well as being able to more quickly find the error when you’re debugging.

Opera doesn’t render the document, but it does provide a display of the source with highlighting where the error occurs. This is extremely helpful when you’re debugging a larger document. In addition, Opera also provides an option to render the document in HTML, rather than XHTML, which is helpful for everyone else.

Contrast and compare these screenshots with the following, from Firefox.

Firefox error handling

The Firefox XHTML error handling is also known as YSOD, or Yellow Screen of Death. It’s harsh, abrupt, and somewhat punishing in nature, with its sickly yellow background, and bright red text. The message is typically cut off by the edge of the browser window, so one can’t easily see where the error has occurred. It’s most definitely intimidating for readers who accidentally stumble on to an XHTML page currently in a broken state.

All four of the browsers do support the XHTML standard, and all stop processing the XHTML when an error occurs, as is proper. But where Safari/Webkit, Chrome/Webkit, and Opera try to provide a useful web page, Firefox picks up a ruler and gives the owner of the web site a good whacking.

It’s easy to fall into the trap of blaming all web development and design problems on Microsoft and IE, and to use IE as a whipping boy—to the exclusion of looking, critically, at the other browsers in the web space. If the lack of support for XHTML in IE is a primary inhibitor of the spread of XHTML, Firefox’s YSOD has to take the second place prize. Support for XHTML doesn’t end at the parser.

Categories
SVG Web

Gracefully upgrading

I am reminded in comments of Steve Champeon’s progressive enhancement, which I actually did cover in my book, “Adding Ajax”. My apologies to Steve for seeming to subvert his subversion of all browsers look the same. I tend to think of Steve’s progressive enhancement in light of the use of JavaScript, but it is also focused at design, too. And, I am embarrassed to admit, I forgot about the concept when I started to write up what I’ve done with my site designs. Blame it on enthusiasm, or advancing age—take your pick.

However, if the concept is so popular with web designers, I have to wonder why every time I mention the use of SVG in web design, I’m met with “Oh, but not every browser supports SVG”? Perhaps IE has become, over time, a handy excuse for not trying something new.

Regardless, the idea of starting plain, and upgrading gracefully did originate with Steve.