Lots of interesting discussion about SVG in browsers. Here’s a roundup of my favorites, along with my thoughts:
To Joshua, if MSIE has a kick-ass graphics engine, and there is a plentiful source of data out there on the web to drive it, why on gods green earth would Microsoft willfully chose to ignore it? Someday, I would love to report that IE12 wipes the floor with other browsers on this test. On both the left and right hand sides of the page.
To Doug, great post. Makes a lot of sense when talking about new vocabularies. I’m a bit leery about central registration. But specifically about SVG, it is an existing vocabulary. You can find plenty of examples on Wikipedia and other places. Ideally someday people could be able to view-source/copy/paste said examples onto their MySpace pages.
To Anne: that’s closest to what I would like to see. My biggest problem with the WHATWG and the existing W3C HTML working group can be best expressed by comparing it against Atom's roadmap. There are four principles listed there. The WHATWG consistently achieves three out of four. I’d like to see HTML5 cater to the long tail developer as well as the big browser vendors. XHTML5 meets all four, but is as an unforgiving and inhospitable environment that it might as well be the moon for most people.
But all in all, momentum is building towards supporting SVG in HTML5, and that makes me happy. It is clear that whatever form it takes won’t satisfy everybody. I’d still prefer that HTML5 support distributed extensibility, but meanwhile, let me toss out the following; merely in the spirit of brainstorming:
<!doctype html>
<title>SVG in text/html</title>
<p>
A green circle:
<script type="image/svg+xml"> <circle r="50" cx="50" cy="50" fill="green"/> </script>
</p>
As I said, no solution will satisfy everybody, and the above clearly won’t support nested scripts. It also requires copy/pasters to skip over the XML prolog, DOCType, and perhaps even the outermost <svg> tag itself. None of these issues need apply to <script src="…"></script>. Ideally, the end result of such a “script” would be nearly indistinguishable from the DOM nodes that standards-compliant browsers produce for inline SVG in XHTML today.
Update:Michael Day suggests <style> instead. If the HTML5 working group will agree to stop hoisting such elements into the <head> section of the DOM, that would work too.
Sam,
You no doubt have noticed that Jacques Distler provided me with a use case for inlining SVG in HTML. Could you also show me a use case where inlined SVG is clearly advantageous over linking it in as we do with images?
I seriously doubt it is a different use case that the one that Jacques may have shared with you, but if you view source on pretty much any post on this weblog from the past 12-18 months you will see at least one small, and resizable, SVG image on the page.
I just had a conversation with a colleague of mine about this, and he pointed out something I hadn’t considered: It has been permissible to inline JavaScript and CSS in HTML, and he knew me well enough to know that even though I prefer to link those in, I don’t have a problem with seeing them inlined with HTML either. In that light, objecting to inlined SVG and MathML is like drawing a line in the sand.
Now that you mention MathML: I feel that the use case for inlining MathML is somewhat more compelling than the use case for inlining SVG. Saying that MathML must be linked makes about as much sense to me as saying that ordered lists must be linked.
That would seem to me to be an odd distinction to make to somebody who is, say, a professor of physics. Ideally, people who deal with mathematical equations on a regular basis should be able to copy and paste these equations into comments on people’s weblogs. Something that can’t be done today on your weblog or mine.
I challenge you to rewrite a typical page from my blog (say, this one), replacing the inline MathML with <object> elements.
Not so much fun, is it?
(And I will repeat the proviso that <object> elements in blog comments are a non-starter.)
As to copy/paste of formulæ, I would say that we are pretty far from where we should be on that. Regressing to MathML as <object>s would be a big step backwards.
(BTW, Sam, would it really be too much to permit people to enter NCR’s?)
From a practical standpoint, svg in HTML img elements gets you most of what you need.
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.
If you can do something like this in CSS:
p {rotation:50; shape:oval; gradient(10%, red: 90%, green);}
then you keep the separation of content from presentation, and you don’t need any SVG elements at all!
would it really be too much to permit people to enter NCR’s?
That would make it more difficult to talk ABOUT instances of NCR’s. But on the other hand, I tried adding it, and it amused me watching the results in live preview, so for now it is in. If it irritates me, it will be yanked.
Sam, semantically speaking your blog SVG pictures are probably images, so an HTML img element pointing to a separate SVG document is fine.
It’s just inline svg inside HTML that I don’t like, because it mixes content with presentation. If you really wanted it inline, might I suggest three HTML “img” elements, one for each shape in the image, with no “src” and a new CSS “path” style (plus the old border and background styles).
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...
@Shelly,
Well - it’s obviously not just up to me! But you raise good questions; all new HTML5 elements should have to be semantic. The MathML ones pass the test, the SVG ones don’t.
“Presentational” MathML is about as semantic as most of HTML. It’s certainly a good deal more semantic than LaTeX, which is the input format typically used to generate it.
“Content” MathML is much more semantic, attempting to convey what the formulæ actually mean. It was conceived as a data interchange format between symbolic manipulation programs (among other things), which is why it is not implemented in any browsers.
“Presentational” MathML is about as semantic as most of HTML
Oh, there's a high bar for you. I bet if you tried hard enough, 51% of HTML could be replaced with <span> + CSS. What’s left would include tags like <table>, and the elements and attributes that Shelley listed.
Oh, there’s a high bar for you. I bet if you tried hard enough, 51% of HTML could be replaced with <span> + CSS. What’s left would include tags like <table>, and the elements and attributes that Shelley listed.
Perhaps.
But, for instance, distinguishing between <mo>, <mi> and <mn> (or including tokens like ⁢ and ⁡ which, to be honest, itex2MML doesn’t do) is as semantically fine-grained as HTML, despite the “Presentational” moniker.
So it would be a little strange to take the position that pMML is insufficiently semantic to be included in (X)HTML. That was precisely the purpose for which it was created.
I spent a few minutes taking you up on your challenge, and I can now appreciate the difficulty of using <object/> tags today, using XHTML and Firefox 2. Since this is the first time I have ever looked at this problem, I wouldn’t know if anyone has tried to style an <object/> tag inline for MathML formatted data. If not, maybe I should write something up that explains the details and offers others a chance to try it out.
Still, what I’m using is not HTML5, and so I’m left to wonder if the behaviour of the <object/> tag couldn’t be made saner.
By the time I reached this point in the conversation, I realized, finally, why Sam, Anne and others were excited by this, so if it wasn’t clear before, let me say now that I changed my opinion on how I think things ought to be done. To wit: yes, we should investigate ways to inline other text formats, and if those formats can be parsed into a DOM tree (something I always thought was a good idea), then so much the better. I only hope that the solution would imitate the pattern that JavaScript and CSS uses — provide a means to either inline the data or include it from a separate URI.
Warning! The following comment will be hopelessly spooged, because Sam’s comment system does not support inline SVG. You’ll have to head over to my blog, and copy/paste it into the comment form there, in order to decipher what I’m saying.
I spent a few minutes taking you up on your challenge, and I can now appreciate the difficulty of using <object/> tags today,
...
By the time I reached this point in the conversation, I realized, finally, why Sam, Anne and others were excited by this, so if it wasn’t clear before, let me say now that I changed my opinion on how I think things ought to be done. To wit: yes, we should investigate ways to inline other text formats, and if those formats can be parsed into a DOM tree (something I always thought was a good idea), then so much the better.
Great! I’m glad we’re finally on the same page. Having, perhaps, understood why inline MathML is a sound idea, let’s move on to inline SVG.
And I defy anyone to tell me that the above sentence is “presentational” or “decorative” or some such malarky.
I’m also not interested in hearing that currently prominent AT programs don’t support SVG.
The currently prominent AT programs (JAWS, Window-Eyes) run on top of IE. So whadya expect?
From everything I’ve read (I haven’t been blessed with the opportunity to sit down in front of one), they’re crap.
It should be clear, from the above markup, that writing an AT program that could do a decent job of conveying the inline SVG would not be rocket science.
(Umh, when you do that, you’ll have to delete the extraneous blank lines in the midst of the SVG that (at least in my browser) got added when I copy/pasted the text of the comment.)
It would be lovely to be able to inline SVG and MathML in comments, Sam. I’m looking forward to seeing how you implement it, because I always find that your implementations differ from what I expect and more often than not in a positive way. This will be interesting. :-)
As to the topic, I just have to say that inlining non-HTML markup in text/html is a good idea. It needs to be well thought through and I think the best thing to do is to describe a general way to do it instead of a finite set of concrete ways to do it, so future requirements can more easilly be met. That is, if specifying this takes less than twentyfour or so years.
I also find your inlining syntax, with the use of <script> elements, very interesting. I see no reason to ditch the <svg /> element, though. Stuffing SVG, MathML, etc., into <script> has the benefit that what’s inside can have a completely different parsing model from what’s outside. I’m not sure it’s “right” to mark up SVG and MathML as scripts, though. That kind of rips them a bit out of their content and context; think how they react to disabling scripting in a browser, for example. Anyhoo, it might be the perfect compromise.
Bah, because of a 406 (because of a <script> tag as far as I could understand) I decided to encode the tags myself. And now they’re double encoded, because the preview didn’t update until I had pressed the submit button. Well well.
FYI, it looks like something went wrong with the utf-8 encoding of that entry in your comment feed. In my aggregator the above text shows up as:
Jacques’ post, deciphered:
Now the Euro and TM are actually control characters (U+0080 and U+0099), so other aggregators may not show them at all. The Firefox feed preview, for example, shows it as:
Jacques’ post, deciphered:
Either way, something’s not right. And it’s not just the apostrophe - the same things happens with a number of other characters in that entry.
So, towards the end of the original post, Sam, you proposed using script tags to render inline content. If the HTML 5 spec used that in the end, I’d be ok with that, but what if we defined an <include> element, with attributes src, type and display (in addition to the usual set)? The src attribute, optional of course, defines a URI to refer to (like img src). The type attribute refers to the mime type of the data enclosed (or referred to). The display attribute would have values of block, inline, or none; if that tag were optional, we would default to inline.
Grrr. Now I need to track down again what counter-measures my hosting provider has in place for script injection attacks.
FYI, it looks like something went wrong with the utf-8 encoding of that entry in your comment feed.
Oops. Fixed. Thanks!
So, towards the end of the original post, Sam, you proposed using script tags to render inline content. If the HTML 5 spec used that in the end, I’d be ok with that, but what if we defined an <include> element
Try them both in an existing browser and see what you think. One of the key self-imposed constraints of the HTML5 working group is backwards compatibility.
If we believe SVG and MathML are important I think we should give them their own elements (<svg> and <math> naturally) with a shared parsing phase as jgraham suggests on my blog.
Linguists will tell you that the only languages that are static are dead ones. This applies too at the character level. Jacques' example above is a very instructive one... Unicode may seem pretty exhaustive, but it can’t keep up with the pace at which new symbols are being created.
The same every bit as true at the semantics level. It would be prudent to think ahead about a way to mark that a given element has being defined by a given media type or namespace.
By the way, I can’t take credit for coming up with the idea of using <script> in this manner. There is a cross browser (as in, count them two), cross platform (again, as in count them, two) plugin that is starting to spread. The media type that this plugin looks for is text/xaml.
Embedding XML islands inside HTML documents is an old idea, and lately the debate about how to standardise this in HTML5 has been heating up again. As someone working on an HTML to PDF converter with strong XML support, I......
the symbol on the LHS of the equation is U+2297 (tensor product), not U+2295 (direct sum)
Fixed. Thanks!
Uhm. Sorry. I should have been more explicit.
There’s a U+2297 on the LHS, and a U+2295 on the RHS.
In words (see the fallback text, contained in the svg:desc elements):
The tensor product of the rank-2 symmetric tensor representation and the fundamental representation decomposes as the direct sum of the adjoint and rank-3 symmetric tensor representations.
Linguists will tell you that the only languages that are static are dead ones. This applies too at the character level. Jacques' example above is a very instructive one... Unicode may seem pretty exhaustive, but it can’t keep up with the pace at which new symbols are being created.
I don’t think you want to lard up Unicode with Young Tableaux. They consists of an arbitrary number of boxes per row, and an arbitrary number of rows, with the one proviso that the number of boxes per row is non-increasing.
What my example does illustrate, though, is that the MathML and SVG people utterly failed to provide a sane mechanism for embedding one dialect in the other. My example should have been written as a snippet of MathML, with embedded snippets of SVG. It wasn’t, because you can’t.
It is not clear to me how you could have been more explicit. Anyway, that now explains how I made this simple error. I was wondering how I could have copy/pasted a simple number incorrectly... and the answer is that I did not... instead I reused the paste buffer when I should have started the “decoding” process over. Bah.
In any case, if I allowed you to enter this stuff directly, I wouldn’t be in the middle of all of this. The server side logic for sanitizing has long since been debugged, appearing in multiple places like Venus, html5lib, and others. I probably don’t need to wait until I get the client side version of the sanitization in order to deploy this.
How does {{{= and =}}} sound as delimiters? I tried several other combinations, and wasn’t happy with introducing yet another set of delimiters; a modifier of sorts on the existing markers seemed better. Thoughts?
{{{=...= }}} sounds good to me. If you’re really using the same sanitization code as Venus and HTML5lib, then I could just embed my example (and any other combination of XHTML+MathML+SVG that I might dream of typing).
Woot!
With a little extra work (supplying the Python equivalent of itex2mml.rb), you’d have Python bindings for itex2MML, and an easysyntax for entering MathML.
Lots of talk these days about allowing SVG inline with text/html content. I thought I’d try and put some thoughts down. Start with Doug’s excellent post on this topic. I don’t have any opinion on the aria-specific elements of the...
Putting the SVG code inline in a page would not be less semantics. A map, a drawing carries a lot of semantics. How do we find our directions without a map? It is full of semantics. A mathematics curve is full of semantics.
Saying that putting inline is against semantics doesn’t make sense if we at the same time accept that you can put an image in <img src="data:image/png;base64,…some ascii data here"/>.
The content of a script or of a stylesheet is not more or less semantics, or datagrid, or canvas. The thing which matters is how do we author things, and how are we able to pass the information between different products without loosing context?
Nicely put, Karl. And I know about Silverlight, Sam. ;-) I also agree with you that we should cater for unknown use-cases. We can’t possibly grasp all the different use-cases today, so we should design something a bit more future-proof than just how to embed SVG and MathML. That would perhaps suffice today, but we’re not talking many years before that proves to be unsufficient. And we don’t really want to be specifying “How to embed X in HTML5” for the rest of our lives, do we?
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...
I’m with Sam on this to discover a real way to be able to extend HTML5 in an arbitrary way. What is the bad thing about Namespaces in HTML5? Does namespace sounds too much like XML? I don’t think it should.
On the other hand, we need fallbacks. What should a browser do if he doesn’t understand SVG? It would be good if the author provides a PNG as fallback and the browser can show this instead. Currently the IE does not show Sam’s nice icons. Is it okay to ignore users using IE? I don’t think so. A fallback would be better. In HTML4 the have the object tag which provides fallback. So it would be nice to think about a generic fallback system if a browser doesn’t understand the namespace in question.
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...