Year: 2007

‘ve moved on from SVG to the Canvas element, and am still suffering whiplash at the downward steepness of the step. Leaving aside that one can defeat canvas easily just by turning off script, about the best documentation I found on the element is Mozilla’s implementation. The specification is buried within the HTML5 work, which if you think on it, defeats every last bit of argument about not including SVG because it’s “presentational”.

About the only negative associated with SVG is how to include it in the pages–the specification, itself, is really nice. Once all of the features are supported in the main browsers, you’re going to see some amazing stuff.

You don’t realize how nice SVG is, until you look at the Canvas element. For instance, I created an SVG example on how quadratic bèzier curves work in SVG. The canvas element also supports the same type of curves, so I went to re-create the example. I hit a wall immediately. Why? Two words:

“dashed lines”

No, there is no way of adding either dashes or dots or combination to lines in canvas. You can use a custom function and create tiny little lines using lineTo and/or one of the curve functions, but there’s no way to actually just specify the dash-dot pattern to use, and forget about it. My canvas demonstration of quadratic bèzier curves ended up looking a tad bit different.

I went searching on HTML5, the canvas element, and dashed line support and found a couple of discussions about supporting dashed lines in canvas. The official word is: not trivial to implement, no one really wants them.

Considering that one of the first implementations on the canvas element I created uses dashed lines, I beg to differ on the ‘no one really wants’ assumption. Sure, I can use a custom function, such as the one I’m using to emulate a rounded corner rectangle, but I can’t help thinking this isn’t the most efficient approach. The user agent should be able to optimize for dashes in line drawing if these are part of the specification, but there is no real optimization for functions that create hundreds of little dashes based on rotate, curve, line, move.

While researching the missing ‘dashes’, I ended up being more caught up in the discussions associated with the canvas element. It wasn’t until looking for dashed line that it hit me: why was there such deeply presentational discussions associated with a version of HTML that’s specific to semantics, only? Especially when you consider that in the recent discussions about support for SVG in HTML5 there was pushback for supporting SVG within HTML5 because SVG is ‘presentational’. In fact, Jacques just wrote, the following on this topic:

The subject came up in a discussion over at Sam’s blog about SVG-in-HTML5. Some people were arguing that, even if it were technically possible, it would be undesirable to sully HTML5 with the inclusion of foreign dialects, like MathML or SVG. The latter, in particular, was in some quarters considered too “presentational.”

This annoyed me sufficiently that I gave the following example:

Say I wish to discuss irreducible representations of SU(3). I think it should be perfectly acceptable to point out that: Rank-2 Symmetric Tensor Representation⊗Fundamental Representation=Adjoint Representation⊕Rank-3 Symmetric Tensor Representation

No, I don’t understand what Jacques wrote, either, but the SVG shows properly.

Of course, the issues associated with SVG (and MathML and RDF/XML, if it comes to that) go beyond just the presentation. SVG is a well-defined markup based on XML, which requires precise handling on the part of the user agent and the agent generating or creating the SVG. HTML5, on the other hand, is meant to be a less rigorous environment, where the lack of precise application of markup is handled with greater indulgence.

Lack of precise application of semantic markup, I should say, as there are new semantic attributes, values, and elements being added to the spec. One assumes this is so that search engines, such as Google, can better process the web page ‘semantics’. In fact, much of the semantics associated with HTML5 seems to be specific to search engine optimization.

I can understand some of the ‘foreign markup’ implementation concerns about SVG. What I can’t understand is why the HTML5 group hasn’t split the canvas element off into a separate specification–not if presentational purity is a goal of the specification. Just because it’s easier to include the canvas element in HTML5, doesn’t mean it should be included, if the underlying purpose of HTML5 is to provide an interim, better behaved, but more forgiving, semantic web page markup. According to the HTML5 spec:

This specification is limited to providing a semantic-level markup language and associated semantic-level scripting APIs for authoring accessible pages on the Web ranging from static documents to dynamic applications.

The scope of this specification does not include addressing presentation concerns (although default rendering rules for Web browsers are included at the end of this specification).

The scope of this specification does not include documenting every HTML or DOM feature supported by Web browsers. Browsers support many features that are considered to be very bad for accessibility or that are otherwise inappropriate. For example, the blink element is clearly presentational and authors wishing to cause text to blink should instead use CSS.

Blink is presentational, while dashed lines are not? I suppose one could also push line patterns off on CSS, but then why would one not also push stroke style and fill pattern, as well as such esoteric items as maximum miter height?

I’ve moved on from SVG to the Canvas element, and am still suffering whiplash at the downward steepness of the step. Leaving aside that one can defeat canvas easily just by turning off script, about the best documentation I found on the element is Mozilla’s implementation. The specification is buried within the HTML5 work, which if you think on it, defeats every last bit of argument about not including SVG because it’s “presentational”.

About the only negative associated with SVG is how to include it in the pages–the specification, itself, is really nice. Once all of the features are supported in the main browsers, you’re going to see some amazing stuff.

You don’t realize how nice SVG is, until you look at the Canvas element. For instance, I created an SVG example on how quadratic bèzier curves work in SVG. The canvas element also supports the same type of curves, so I went to re-create the example. I hit a wall immediately. Why? Two words:

“dashed lines”

No, there is no way of adding either dashes or dots or combination to lines in canvas. You can use a custom function and create tiny little lines using lineTo and/or one of the curve functions, but there’s no way to actually just specify the dash-dot pattern to use, and forget about it. My canvas demonstration of quadratic bèzier curves ended up looking a tad bit different.

I went searching on HTML5, the canvas element, and dashed line support and found a couple of discussions about supporting dashed lines in canvas. The official word is: not trivial to implement, no one really wants them.

Considering that one of the first implementations on the canvas element I created uses dashed lines, I beg to differ on the ‘no one really wants’ assumption. Sure, I can use a custom function, such as the one I’m using to emulate a rounded corner rectangle, but I can’t help thinking this isn’t the most efficient approach. The user agent should be able to optimize for dashes in line drawing if these are part of the specification, but there is no real optimization for functions that create hundreds of little dashes based on rotate, curve, line, move.

While researching the missing ‘dashes’, I ended up being more caught up in the discussions associated with the canvas element. It wasn’t until looking for dashed line that it hit me: why was there such deeply presentational discussions associated with a version of HTML that’s specific to semantics, only? Especially when you consider that in the recent discussions about support for SVG in HTML5 there was pushback for supporting SVG within HTML5 because SVG is ‘presentational’. In fact, Jacques just wrote, the following on this topic:

The subject came up in a discussion over at Sam’s blog about SVG-in-HTML5. Some people were arguing that, even if it were technically possible, it would be undesirable to sully HTML5 with the inclusion of foreign dialects, like MathML or SVG. The latter, in particular, was in some quarters considered too “presentational.”

This annoyed me sufficiently that I gave the following example:

Say I wish to discuss irreducible representations of SU(3). I think it should be perfectly acceptable to point out that: Rank-2 Symmetric Tensor Representation⊗Fundamental Representation=Adjoint Representation⊕Rank-3 Symmetric Tensor Representation

No, I don’t understand what Jacques wrote, either, but the SVG shows properly.

Of course, the issues associated with SVG (and MathML and RDF/XML, if it comes to that) go beyond just the presentation. SVG is a well-defined markup based on XML, which requires precise handling on the part of the user agent and the agent generating or creating the SVG. HTML5, on the other hand, is meant to be a less rigorous environment, where the lack of precise application of markup is handled with greater indulgence.

Lack of precise application of semantic markup, I should say, as there are new semantic attributes, values, and elements being added to the spec. One assumes this is so that search engines, such as Google, can better process the web page ‘semantics’. In fact, much of the semantics associated with HTML5 seems to be specific to search engine optimization.

I can understand some of the ‘foreign markup’ implementation concerns about SVG. What I can’t understand is why the HTML5 group hasn’t split the canvas element off into a separate specification–not if presentational purity is a goal of the specification. Just because it’s easier to include the canvas element in HTML5, doesn’t mean it should be included, if the underlying purpose of HTML5 is to provide an interim, better behaved, but more forgiving, semantic web page markup. According to the HTML5 spec:

This specification is limited to providing a semantic-level markup language and associated semantic-level scripting APIs for authoring accessible pages on the Web ranging from static documents to dynamic applications.

The scope of this specification does not include addressing presentation concerns (although default rendering rules for Web browsers are included at the end of this specification).

The scope of this specification does not include documenting every HTML or DOM feature supported by Web browsers. Browsers support many features that are considered to be very bad for accessibility or that are otherwise inappropriate. For example, the blink element is clearly presentational and authors wishing to cause text to blink should instead use CSS.

Blink is presentational, while dashed lines are not? I suppose one could also push line patterns off on CSS, but then why would one not also push stroke style and fill pattern, as well as such esoteric items as maximum miter height?

I finished the static chapter on SVG for the book and it has become the largest. I imagine the programming chapters could get larger. One doesn’t realize how rich SVG is, until one really looks at the individual components and realizes what you can do with the technology.

It’s nice to see that the HTML5 working group is now considering the need to include SVG in the specification. According to Anne van Kesteren:

The other interesting thread is about an HTML compatible syntax for SVG. In other words, integrating SVG in text/html. Now that an HTML parser, that is compatible with deployed content and Web browsers, is defined, it is possible to create small extensions on top of it that enable new tricks. As SVG is essentially a DOM-based language the only thing the parser will have to ensure is that the elements end up in the right namespace in the DOM.

The comment thread is interesting, but when I see discussion about changing the SVG specification just so it’s more compatible with HTML5, I run cold. Really cold. The thread also highlights my own concerns with HTML5 and trying to integrate semantics using syntax rather than a model, as people worry about whether opening the door to SVG won’t open the door to RDF and other such nonsense. After all, who wants to muck up the burger (using Anne’s colorful description of the next generation of tag soup) with open, mature specifications? That would be like Hardee’s trying to create a healthy, low calorie sandwich.

Sam Ruby, who is much more tolerant of burgers than I am–but then, he also patiently works with RSS 2.0, the XML equivalent of a Twinkie–also linked other discussions on SVG, which, I agree with Sam, are nice to see.

The first post he links discusses Microsoft and Adobe’s impact on SVG with assurances that neither company is out to kill SVG. Yes, but neither company is out to support SVG, either. Supporting it as an export format is not enough. IE doesn’t support SVG, and Adobe is pulling it’s *popular SVG plug-in in January. End of story.

(Interestingly enough I just dropped the planned Flash/Flex and Silverlight chapters from my book, in order to make more room for the non-proprietary specifications such as SVG.)

The comments in Sam’s post reflect what’s happening in Anne’s post, including the re-occurring question of just using the object or img element to include SVG, rather than allow inline SVG. The use of object as compared to inline isn’t just an issue with SVG, as Jacques Distler points out in comments, specifically directing attention to MathML. Jacques also discusses allowing inline SVG and MathML in comments; allowing the object element in comments is not something most of us would want to contemplate. I’m sure that if I did allow object or scripting elements in my comments that you would have no hesitation on opening the pages in your browser.

In addition, the whole point of SVG, or one would just use a converter to convert SVG into PNG format, is that SVG, being a vector language, can become part of the page DOM, which means we can then ‘do’ things with the SVG when loaded. We may not want to, but wouldn’t we rather have this option than not?

Sam’s proposal is to use the script element to bring in SVG. The benefit to this is that we can then include SVG in the page, and ensure it’s loaded into the DOM if we wish. Without having to redefine the semantics behind ‘img’, I want to add. The idea has limitations, which Sam points out. Using the script element is, however, preferable than just blowing SVG off for the HTML folks. Or bunging it into object, like we bung everything else into ‘class’ or ‘rel’.

One of the commenters, Chris Jay, wrote the following in comments to Anne’s post:

But on principle, I don’t support inline svg elements, because they’re not semantic, they’re presentational. Colors, gradients, filters, crops, shapes, and even geometry (e.g. rotation), should be put in CSS instead, so they can be applied to ANY element.

Many of these are being added to CSS, but CSS isn’t meant to control the creation of objects. There is no place in CSS for creating a rectangle, polygon, or polyline, much less a path or a text object. As for using CSS to control the presentation of these objects, we have much of this already. We can include SVG presentational information in a style attribute, if we want. True, something like a gradient is an object in SVG rather than an attribute is that it is a complex object with attributes and modifications of its own, which can then be used to ‘fill’ other objects. But then, so can paths–paths can be used to build patterns.

The point is, ten years ago the big thing in web page markup was presentation and we had FONT and BLINK, and now the big thing in markup is ‘semantics’ and we have things like…the Canvas object. The datagrid, which is enabled for Ajax use. Drag and drop. Editable content. Stop me when we get to something semantical.

In the meantime, I’ll plug along with XHTML 1.1, where though I’m sometimes fed mustard yellow pages, at least I’m not at the mercy of the ‘semantic’ burgers.

Speaking of which, after my own recent experiences in inline SVG, I’ve decided three things:

1. For my uses of reusable SVG symbols, I plan on adding my own template tags and plug-ins that find these and replace them with SVG in the post, but not in the database or the syndication feeds. Until Mozilla/Firefox and Safari 3 get their act together enough to support external SVG fragments, repeating blocks of SVG text in the database is not something I contemplate with equanimity. I should be able to create reusable blocks of SVG and use them thus:

<use xlink:href=”symlibrary.svg#musicnote1″ width=”15″ height=”10″ />

Opera supports this. Safari 3 doesn’t, and neither does Firefox 3. IE? *giggle* That’s funny.

2. I’m stripping SVG from syndication feeds. In many ways, this goes back to the question of what exactly a syndication feed is for, and how much we should provide in a feed versus providing at the source.

If I still had feed excerpts, the issue wouldn’t arise because all markup is stripped with excerpts. Yeah, feeds, partial or full, is a topic I bring up a lot, because it’s an issue that irritates me and, frankly, continues to irritate me. This irritation isn’t aided by the fact that WordPress makes it really difficult to support both partial and full feeds.

In the meantime, since serving a post with SVG as HTML in syndication feeds causes Atom hiccups, and the Atom feed is hard coded to display content as HTML, only, I’ll continue with my manually edited feed template until I have time to write some plug-ins. Or until Sam can get through the modifications he makes into the general WordPress code. Whichever comes first.

3. I’m contemplating adding SVG support in comments. Just contemplating, though.

Update

I’m now seeing that the Adobe SVG Viewer plug-in may be available until 2009. I don’t know if this is a typo or not, because the front page for the install still shows January, 2008.