It’s just data

SVG in HTML Momentum Building

Lots of interesting discussion about SVG in browsers.  Here’s a roundup of my favorites, along with my thoughts:

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?

Thanks!

Posted by roberthahn at

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.

Posted by Sam Ruby at

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.

Posted by roberthahn at

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.

Posted by Sam Ruby at

I guess, but the difference between an ordered list and a snippet of MathML is that only one of them is served with an alternative mime type.

Posted by roberthahn at

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.

Posted by Sam Ruby at

Robert,

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?)

Posted by Jacques Distler at

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!

Posted by Chris at

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.

Astral: 𐍆

But on principle, I don’t support inline svg elements, because they’re not semantic, they’re presentational.

As an exercise, can you tell me how the small SVG image that you see on this page would be represented in your proposed extensions to CSS?

Also, which of div or span do you propose be eliminated from HTML5?

Posted by Sam Ruby at

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).

Posted by Chris at

Chris, can you tell me which of the following is 'semantical'?

The Canvas object

datagrid

drag and drop attributes

Marking an object as editable

Posted by Shelley at

SVG Onward

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

Excerpt from Burningbird at

@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.

But here’s a starter...

Posted by anonymous at

The MathML ones pass

Oh, really?

Chris — you certainly are welcome to your opinion, but you are giving every appearance of not having thought this through very carefully.

Posted by Sam Ruby at

Oh, really?

“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.

Posted by Jacques Distler at

“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.

Posted by Sam Ruby at

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 &InvisibleTimes; and &ApplyFunction; 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.

Posted by Jacques Distler at

Jacques,

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.

Posted by roberthahn at

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.

Say I wish to discuss irreducible representations of SU(3). I think it should be perfectly acceptable to point out that: <svg xmlns="http://www.w3.org/2000/svg" width="30" height="16" viewBox="0 0 30 16">
  <desc>Rank-2 Symmetric Tensor Representation</desc>
  <g transform="translate(5,5)" fill="#FCC" stroke="#000" stroke-width="2">
  <rect width="10" height="10"/>
  <rect width="10" height="10" x="10"/>
  </g>
</svg> ⊗ <svg xmlns="http://www.w3.org/2000/svg" width="30" height="16" viewBox="0 0 30 16">
  <desc>Fundamental Representation</desc>
  <g transform="translate(5,5)" fill="#FCC" stroke="#000" stroke-width="2">
  <rect width="10" height="10"/>
  </g>
</svg> = <svg xmlns="http://www.w3.org/2000/svg" width="30" height="26" viewBox="0 0 30 26">
  <desc>Adjoint Representation</desc>
  <g transform="translate(5,5)" fill="#FCC" stroke="#000" stroke-width="2">
  <rect width="10" height="10"/>
  <rect width="10" height="10" x="10"/>
  <rect width="10" height="10" y="10"/>
  </g>
</svg> ⊕ <svg xmlns="http://www.w3.org/2000/svg" width="40" height="16" viewBox="0 0 40 16">
  <desc>Rank-3 Symmetric Tensor Representation</desc>
  <g transform="translate(5,5)" fill="#FCC" stroke="#000" stroke-width="2">
  <rect width="10" height="10"/>
  <rect width="10" height="10" x="10"/>
  <rect width="10" height="10" x="20"/>
  </g>
</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.

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.

Posted by Jacques Distler at

(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.)

Posted by Jacques Distler at

Jacques’ post, deciphered:


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 .

Hmmm. Perhaps I could add an syntax, much like {{{…}}}, but in reverse, that instead of escaping the markup, merely sanitizes it. Will ponder.

Posted by Sam Ruby at

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 &lt;script&gt; elements, very interesting. I see no reason to ditch the &lt;svg /&gt; element, though. Stuffing SVG, MathML, etc., into &lt;script&gt; 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.

Posted by Asbjørn Ulsberg at

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.

Posted by Asbjørn Ulsberg at

Jacques’ post, deciphered:

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.

Posted by James Holderness at

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.

Posted by roberthahn at

because of a 406

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.

Posted by Sam Ruby at

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.

Posted by Anne van Kesteren at

If we believe SVG and MathML are important I think we should give them their own elements

Today is 2007.  SVG and MathML are rising in importance.

What should we do now to prepare for the vocabulary that rises in importance in 2012?  2017?

Posted by Sam Ruby at

What should we do now to prepare for the vocabulary that rises in importance in 2012?  2017?

Deciding how those formats best integrate with the Web’s language now seems premature as it is completely unclear what the requirements are.

Posted by Anne van Kesteren at

Deciding how those formats best integrate with the Web’s language now seems premature as it is completely unclear what the requirements are.

The use case is to enable features without use cases.

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.

Posted by Sam Ruby at

Small quibble about your “decoded” version of the comment: the symbol on the LHS of the equation is U+2297 (tensor product), not U+2295 (direct sum).

Otherwise, cool!

Posted by Jacques Distler at

the symbol on the LHS of the equation is U+2297 (tensor product), not U+2295 (direct sum)

Fixed.  Thanks!

Posted by Sam Ruby at

Another proposal for XML in HTML

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

Excerpt from O'Reilly XML Blog at

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.

Posted by Jacques Distler at

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.

Posted by Jacques Distler at

I should have been more explicit.

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?

Posted by Sam Ruby at

{{{=...= }}} 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 easy syntax for entering MathML.

Posted by Jacques Distler at

(Umh, in case you’re wondering, that’s a BZR repository.)

Posted by Jacques Distler at

Yet More on SVG in text/html

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

Excerpt from Something Witty Goes Here at

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?

Posted by Karl Dubost, W3C at

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?

Posted by Asbjørn Ulsberg at

Updated: Dash it All

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

Excerpt from Burningbird at

SVG in MathML in ...

On mixing SVG and MathML....

Excerpt from Musings at

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.

Posted by Alexander Kiel at

Dash it All

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

Excerpt from Bb RealTech at

Add your comment