Firefox 4: the HTML5 parser – inline SVG, speed and more

This is a guest post from Henri Sivonen, who has been working on Firefox’s new HTML5 parser. The HTML parser is one of the most complicated and sensitive pieces of a browser. It controls how your HTML source is turned into web pages and as such changes to it are rare and need to be well-tested. While most of Gecko has been rebuilt since its initial inception in the late 90s, the parser was one of the stand-outs as being “original.” This replaces that code with a new parser that’s faster, compliant with the new HTML5 standard and enables a lot of new functionality as well.

A project to replace Gecko’s old HTML parser, dating from 1998, has been ongoing for some time now. The parser was just turned on by default on the trunk, so you can now try it out by simply downloading a nightly build without having to flip any configuration switch.

There are four main things that improve with the new HTML5 parser:

  • You can now use SVG and MathML inline in HTML5 pages, without XML namespaces.
  • Parsing is now done off Firefox’s main UI thread, improving overall browser responsiveness.
  • It’s improved the speed of innerHTML calls by about 20%.
  • With the landing of the new parser we’ve fixed dozens of long-standing parser related bugs.

Try the demo with a Firefox Nightly or another HTML5-ready browser. It should look like this:

What Is It?

The HTML5 parser in Gecko turns a stream of bytes into a DOM tree according to the HTML5 parsing algorithm.

HTML5 is the first specification that tells implementors, in detail, how parse HTML. Before HTML5, HTML specifications didn’t say how to turn a stream of bytes into a DOM tree. In theory, HTML before HTML5 was supposed to be defined in terms of SGML. This implied a certain relationship between the source of valid HTML documents and the DOM. However, parsing wasn’t well-defined for invalid documents (and Web content most often isn’t valid HTML4) and there are SGML constructs that were in theory part of HTML but that in reality popular browsers didn’t implement.

The lack of a proper specification led to browser developers filling in the blanks on their own and reverse engineering the browser with the largest market share (first Mosaic, then Netscape, then IE) when in doubt about how to get compatible behavior. This led to a lot of unwritten common rules but also to different behavior across browsers.

The HTML5 parsing algorithm standardizes well-defined behavior that browsers and other applications that consume HTML can converge on. By design, the HTML5 parsing algorithm is suitable for processing existing HTML content, so applications don’t need to continue maintaining their legacy parsers for legacy content. Concretely, in the trunk nightlies, the HTML5 parser is used for all text/html content.

How Is It Different?

The HTML5 parsing algorithm has two major parts: tokenization and tree building. Tokenization is the process of splitting the source stream into tags, text, comments and attributes inside tags. The tree building phase takes the tags and the interleaving text and comments and builds the DOM tree. The tokenization part of the HTML5 parsing algorithm is closer to what Internet Explorer does than what Gecko used to do. Internet Explorer has had the majority market share for a while, so sites have generally been tested not to break when subjected to IE’s tokenizer. The tree building part is close to what WebKit does already. Of the major browser engines WebKit had the most reasonable tree building solution prior to HTML5.

Furthermore, the new HTML5 parser parses network streams off the main thread. Traditionally, browsers have performed most tasks on the main thread. Radical changes like off-the-main-thread parsing are made possible by the more maintainable code base of the HTML5 parser compared to Gecko’s old HTML parser.

What’s In It for Web Developers?

The changes mentioned above are mainly of interest to browser developers. A key feature of the HTML5 parser is that you don’t notice that anything has changed.

However, there is one big new Web developer-facing feature, too: inline MathML and SVG. HTML5 parsing liberates MathML and SVG from XML and makes them available in the main file format of the Web.

This means that you can include typographically sophisticated math in your HTML document without having to recast the entire document as XHTML or, more importantly, without having to retrofit the software that powers your site to output well-formed XHTML. For example, you can now include the solution for quadratic equations inline in HTML:






Likewise, you can include scalable inline art as SVG without having to recast your HTML as XHTML. As screen sized and pixel densities become more varied, making graphics look crisp at all zoom levels becomes more important. Although it has previously been possible to use SVG graphics in HTML documents by reference (using the object element), putting SVG inline is more convenient in some cases. For example, an icon such as a warning sign can now be included inline instead of including it from an external file.


Make yourself a page that starts with <!DOCTYPE html> and put these two pieces of code in it and it should work with a new nightly.

In general, if you have a piece of MathML or SVG as XML, you can just copy and paste the XML markup inline into HTML (omitting the XML declaration and the doctype if any). There are two caveats: The markup must not use namespace prefixes for elements (i.e. no svg:svg or math:math) and the namespace prefix for the XLink namespace has to be xlink.

In the MathML and SVG snippits above you’ll see that the inline MathML and SVG pieces above are more HTML-like and less crufty than merely XML pasted inline. There are no namespace declarations and unnecessary quotes around attribute values have been omitted. The quote omission works, because the tags are tokenized by the HTML5 tokenizer—not by an XML tokenizer. The namespace declaration omission works, because the HTML5 tree builder doesn’t use attributes looking like namespace declarations to assign MathMLness or SVGness to elements. Instead, <svg> establishes a scope of elements that get assigned to the SVG namespace in the DOM and <math> establishes a scope of elements that get assigned to the MathML namespace in the DOM. You’ll also notice that the MathML example uses named character references that previously haven’t been supported in HTML.

Here’s a quick summary of inline MathML and SVG parsing for Web authors:

  • <svg></svg> is assigned to the SVG namespace in the DOM.
  • <math></math> is assigned to the MathML namespace in the DOM.
  • foreignObject and annotation-xml (an various less important elements) establish a nested HTML scope, so you can nest SVG, MathML and HTML as you’d expect to be able to nest them.
  • The parser case-corrects markup so <SVG VIEWBOX='0 0 10 10'> works in HTML source.
  • The DOM methods and CSS selectors behave case-sensitively, so you need to write your DOM calls and CSS selectors using the canonical case, which is camelCase for various parts of SVG such as viewBox.
  • The syntax <foo/> opens and immediately closes the foo element if it is a MathML or SVG element (i.e. not an HTML element).
  • Attributes are tokenized the same way they are tokenized in HTML, so you can omit quotes in the same situations where you can omit quotes in HTML (i.e. when the attribute value is not the empty string and does not contain whitespace, ", ', `, <, =, or >).
  • Warning: the two above features do not combine well due to the reuse of legacy-compatible HTML tokenization. If you omit quotes on the last attribute value, you must have a space before the closing slash. <circle fill=green /> is OK but <circle fill=red/> is not.
  • Attributes starting with xmlns have absolutely no effect on what namespace elements or attributes end up in, so you don’t need to use attributes starting with xmlns.
  • Attributes in the XLink namespace must use the prefix xlink (e.g. xlink:href).
  • Element names must not have prefixes or colons in them.
  • The content of SVG script elements is tokenized like they are tokenized in XML—not like the content of HTML script elements is tokenized.
  • When an SVG or MathML element is open <![CDATA[]]> sections work the way they do in XML. You can use this to hide text content from older browsers that don’t support SVG or MathML in text/html.
  • The MathML named characters are available for use in named character references everywhere in the document (also in HTML content).
  • To deal with legacy pages where authors have pasted partial SVG fragments into HTML (who knows why) or used a <math> tag for non-MathML purposes, attempts to nest various common HTML elements as children of SVG elements (without foreignObject) will immediately break out of SVG or MathML context. This may make some typos have surprising effects.


  1. jpvincent

    so, will this engine be only in FF4 or it could happen sooner in a 3.6.x version ?

    May 11th, 2010 at 09:23

    1. jng

      You can in 3.6.x, but you have to go to about:config to enable html5 parsing.

      May 11th, 2010 at 10:35

  2. voidmind

    Is the work on XPCOMGC ( for Mozilla 2 meant to be included in FF4 or is this further in the roadmap?

    May 11th, 2010 at 10:00

    1. Christopher Blizzard

      I don’t think we’re focusing on XPCOMGC right now. We actually did the cycle collector in previous releases, which helped a lot with those problems. We are also looking at a per-page GC, which would help a lot with some set of garbage collection issues.

      May 17th, 2010 at 09:39

  3. Daniel

    Fails to render in Chrome, but then both and say the page is invalid HTML5.

    May 11th, 2010 at 10:37

  4. Doug Schepers

    Nice writeup and nice work, Henri. I caution folks to still use quotes and proper casing in SVG, so the content works in other situations, like inline SVG in XHTML, standalone SVG, etc.

    This is a great step forward… with the next version of both Firefox and Internet Explorer supporting SVG inline in HTML, I hope to see a lot more use. (Let’s hope IE supports MathML, too!)

    May 11th, 2010 at 10:48

  5. Henri Sivonen

    @jpvincent, It’s highly unlikely that this would get backported to 3.6.x.

    @jng, Flipping the pref in Firefox 3.6.x exposes you to known bugs inlcuding crashers. The snapshot of the parser in 3.6 is from June 2009 before the parser had had any testing by our community of users of nightly builds. I recommend getting a trunk nightly if you want to run the HTML5 parser and not enabling it on 3.6.x.

    @Daniel, Chrome doesn’t have an HTML5 parser yet. The reason why I haven’t enabled SVG-in-text/html or MathML-in-text/html validation in the HTML5 validator yet is tht I wanted to discourage authors from using the features before they had a browser to test with. If authors create content speculatively, there’s a risk of creating a loegacy that makes introducing implementations harder. I intend to enable SVG-in-text/html and MathML-in-text/html validation soon.

    May 11th, 2010 at 10:50

    1. SilverWave

      >@jpvincent, It’s highly unlikely that this would get backported to 3.6.x.

      Why no backport?
      3.6.7 or whatever, as was done with OOPP?
      The same rationale would apply, no GUI changes just under the hood stuff.

      It would be nice to be able to use the uptodate parser in 3.6.

      4.0 will be a while and it would be nice to have the gains immediately ;-)

      May 18th, 2010 at 09:42

      1. Boris

        SilverWave, unlike OOPP this change is known to break various sites because the parser _does_ change behavior and the sites assume things about parser behavior (complete with UA sniffing, etc). The sites will update eventually, but in the meantime this is not appropriate for a stable branch.

        May 18th, 2010 at 09:59

        1. SilverWave

          Fair enough. Although I was thinking more along the lines of a swap out of old (Buggy)3.6 Parser for new parser, but with html5 still turned off by default.

          Then ppl could turn it on at their own risk just as now.

          I suppose that the cost would be too high for the small benefit.
          I was thinking the feedback from a larger number of users would be beneficial and provide sites with a nudge to start the necessary upgrading.

          BTW I have had the html5 turned on in 3.6 for a week with no problem so far ;-)

          May 18th, 2010 at 10:36

  6. Lars Gunther

    Really cool. The demo worked flawlessly in Fennec. I am writing this comment on it right now. (And the latest update made filling in this form a pleasure.)

    May 11th, 2010 at 11:20

  7. Brian Herman

    Wow, this is so cool. This worked like a dream in the nightly.

    May 11th, 2010 at 13:34

  8. ALan

    I like it. Feels really fast.

    May 11th, 2010 at 14:09

  9. pascal

    Nice. Will it finally allow basic things like empty script and textarea-elements? (without seperate closing tag, like XML)

    Oh and will Firefox finally use a real XML parser when the content-type says XML? and not some tag-soup-guessparser?

    May 11th, 2010 at 14:34

  10. Jeff Walden

    Both instances of “lead” in the original post should be “led”.

    May 11th, 2010 at 14:41

  11. Adam

    Is this html5 parser also used to parse xhtml(5), or a separate parser used to parse all xml?

    May 11th, 2010 at 15:25

  12. Hans Wurest

    @Doug Schepers:
    I aggree, just because its possible people should be still discouraged from not being unreserved.

    I wonder what was the rationale for including the HTML5 parser in 3.6?

    Also, I remember Firefox was always being pretty efficient in rendering huuuuge tables (compared to other browser). I hope this won’t change fo the worse with the new parser.

    May 11th, 2010 at 17:12

  13. SilverWave

    In my test case Firefox 3.6.5 is aprox. 3x Faster with html5.enable=True

    Bug 559396 Large ShelveLogger files are slow in Firefox

    bzip2-compressed instrumented version that alerts times and has profiler hooks

    Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100507 Ubuntu/10.04 (lucid) Namoroka/3.6.5pre – Build ID: 20100507040151

    @Hans Wures:
    re:rendering huuuuge tables
    FF 3.6.4 was 37 seconds Chromium 5 seconds, so not so much.

    May 11th, 2010 at 20:40

  14. voracity

    “Instead, [svg] establishes a scope of elements that get assigned to the SVG namespace in the DOM and [math] establishes a scope of elements that get assigned to the MathML namespace in the DOM.”

    You mean markup is being used to actually, you know, mark things up? (Apologies for the sarcasm, but the verbosity of XML et al. is so saddening.)

    May 12th, 2010 at 01:04

  15. pawel

    Is there a plan to serve SVG via CSS like Webkit and Opera?

    May 12th, 2010 at 02:59

  16. Henri Sivonen

    @Daniel, I updated The W3C instance of the validator should pick up the change when the maintainer of the W3C instance updates the code from version control.

    @Hans Wurest, Code gets landed on the trunk and from time to time a release branch is cut. Firefox 3.6 branched very soon after the parser landed on trunk preffed off, so parser got picked up into the branch. The change policies to branches are rather strict, so at that point, the parser got stuck on the branch as removing the parser didn’t meet the bar for branch-only changes.

    May 12th, 2010 at 06:23

  17. A. Davis

    I regularly use xhtml+mathml+svg (great for making physics worksheets) and have been updating things to work with the html5 parser (using Firefox 3.6). It’s great and things work nicely. Looking forward to Firefox 4.

    One of the things I did notice that changed with the html5 parser is that the onload attribute no longer seems to function. Is this by design or should a bug be filed?

    May 12th, 2010 at 06:49

  18. A. Davis

    Oops, “onload attribute *in the svg element*”

    May 12th, 2010 at 06:51

  19. Henri Sivonen

    In case you are wondering about the behavior of ‘a’ and ‘font’ end tags in SVG, it is a known spec bug that remains in the implementation for the time being. The fix for the spec bug was itself buggy, so implementing a fix is now blocked on the new spec bugs. Tracked as

    May 12th, 2010 at 07:13

  20. Lars Gunther

    Doug’s caution about SVG being copy-able into another setting where it is parsed as XML would make for a great thing to have in the validator’s pedagogic ruleset (not yet implemented).

    May 12th, 2010 at 08:36

  21. Lars Gunther

    2nd follow up idea: Would it be possible to check for SVG and/or MathML in text/html as a plug-in to Modernizr?

    May 12th, 2010 at 08:39

  22. Henri Sivonen

    @Lars Gunther, I’m not sure what happened to the profiles. No news there for quite a while.

    As for Modernizr, I suggest something like for SVG. In the MathML case, it’s trickier to tell if the browser implements just the parsing algorithm or the parsing algorithm and actual MathML functionality on top of the resulting DOM.

    May 12th, 2010 at 10:39

  23. Lars Gunther

    Your work has already been noted in under the heading Inline SVG in HTML5. That was fast!

    May 12th, 2010 at 13:08

  24. marcoos

    Great article, and awesome stuff coming to Firefox 4. Really can’t wait. :)

    As with some of the most interesting (to me, at least) Hacks articles, here’s my Polish translation of Henri’s post.

    May 12th, 2010 at 13:11

  25. Brad Neuberg

    It’s very exciting to see this work land in the Firefox nightlies by default! Great work Henri.

    This will make IE 9 and Firefox 4+ the two browsers that natively support SVG inside of HTML5. Anyone know what the status of Webkit is for this feature?

    Brad Neuberg

    May 12th, 2010 at 17:08

  26. Brad Neuberg

    BTW, it’s a little known fact that you can apply CSS Web Fonts to SVG Text elements. Can you make sure to test that this still works in the new HTML5/SVG parser?

    May 12th, 2010 at 17:10

  27. mike503

    All this is great, but PLEASE work on resource utilization. Firefox is typically the most reliable for website compatibility, but it eats up RAM like none other, as well as CPU sometimes.

    Quicker startup times and a leaner footprint would be excellent. As an open source product I would think people would be hacking improvements for this left and right!

    May 13th, 2010 at 12:19

    1. Boris

      mike503, the interesting thing is that any time someone actually _measures_ memory usage across browsers Firefox comes in with the lowest RAM usage. So I don’t know about that “eats up RAM like none other” thing.

      May 14th, 2010 at 00:14

    2. SilverWave

      Re: mike503

      Chromium uses 778MB(2tabs) Firefox 3.6.5 272MB(43tbabs).
      I also have 34 Extensions running and it doesn’t crash.

      I see “mike503” type stuff in most comments sections so.

      Either its spam or astroturfing or he really has a problem :-)
      Are you using FF3.6? if not upgrade.
      Have you created a clean profile? If not do so.

      If the above works add in each extension until you find the ones that are causing the problem.

      If the above does not work its possibly your OS. Thy booting the latest Ubuntu LiveCD and see if using the provided Firefox works OK for you.

      If not then it must be a hardware issue :-(

      TBH I don’t care that Chromium uses more memory as I have upgraded to 8GB specifically because I want speed!

      I would prefer that Firefox used 2GB if it was faster.

      BTW that’s not the issue as I have loaded firefox into ram and the speeds don’t change.

      May 14th, 2010 at 02:58

  28. Henri Sivonen

    @pascal, No, textarea and script will continue to require end tags in text/html due to compatibility with the legacy. Firefox already uses a real XML parser for XML content type and has used a real XML parser for years and years.

    @Adam, The HTML5 parser is used for content served as text/html. Content served as as application/xhtml+xml is parsed using the XML parser. So, no the HTML5 parser is not used for XHTML5. (If you are serving content as text/html, it is not XHTML5.)

    @A. Davis, The bug is . The way the load event has been defined in the SVG spec doesn’t consider all the consequences satisfactorily. I’ve been waiting for the SVG WG to decide if they choose to make the definition better or if they choose to remove the whole event. (The event is a bit of a misfeature to begin with.)

    @Brad Neuberg, Thanks. I’m not the best person to make forward-looking statements about the status of things in WebKit, but the current status is that WebKit doesn’t support SVG or MathML in text/html in its HTML parser. In Gecko, @font-face works in SVG in text/html:

    May 14th, 2010 at 01:37

  29. Michael Newton

    If you have a feature that works identically in either of two ways, but one of those ways requires bold-faced warnings, isn’t it better to just not mention it?

    I’m speaking of unquoted attributes…

    May 14th, 2010 at 15:09

  30. Darren Govoni

    The latest drop is looking and running well. But the javascript execution is still not as fast and smooth as Chrome after testing my app (e.g. animations, large javascript apps, etc.)

    My app requires firefox, which I’m loyal to. So I hope the javascript and css rendering will run faster than chrome when its released.

    May 15th, 2010 at 23:40

  31. […] Sivonen, one of Mozilla’s Firefox developers, has written a guest post on about Firefox’s new HTML5 […]

    May 16th, 2010 at 18:12

  32. Boris

    Darren, have you filed a bug on the performance issues with your app? If not, could you please do that and cc “:bz” on it?

    May 17th, 2010 at 15:20

  33. Darren Govoni

    I will do that! Thank you.

    May 17th, 2010 at 19:42

  34. david

    Very nice to hear that the HTML parser is being rebuilt! Is the HTML5 parser in Firefox 3.7 Alpha 4 (more or less) fine or do I really have to install a nightly?

    May 18th, 2010 at 12:06

  35. Henri Sivonen

    @Michael Newton, I mentioned it mainly to make it clear that there’s no embedded XML parser for SVG and MathML.

    @david, I can’t remember what stage the HTML5 parser was in at the time of an Alpha, but it was “more or less” fine but needed pref flipping. I’d still recommend that people who are interested in getting an early look of the HTML5 parser use fresh nightlies instead of older builds (with the usual caveats that go with nightlies in general).

    May 18th, 2010 at 23:27

  36. […] and canvas (which Safari and Firefox have both been shipping for years) it’s actually the honest-to-god promise of interoperability. Even stodgy old Microsoft, who has been doing their best to hold back the web for nearly a decade, […]

    June 4th, 2010 at 11:48

  37. Steve

    Please include NoScript in future firefox builds as part of the browser

    June 5th, 2010 at 12:16

  38. Ant Gray

    I’d rather use quotes for values anyway, as my text editor hilight only quoted ones.

    June 16th, 2010 at 14:54

  39. […] What’s new in Firefox 4 […]

    June 18th, 2010 at 04:34

  40. Guillermo Anaya

    how to delete this firefox document: 3000-8022_4.10045910.html
    protocol: Hyper Text Transfer Protocol
    Type Firefox Document

    This document is a virus, how can I delete it from my computer?

    June 25th, 2010 at 02:18

  41. […] HTML5 Parser: Run the best Web apps of today and tomorrow – if a user’s browser doesn’t support HTML5, they still won’t miss out on your content. […]

    July 6th, 2010 at 14:42

  42. […] HTML5 parsing algorithm, one of the most important parts of the HTML5 spec. The parser allows us to embed SVG and MathML directly into HTML content, but also promises developers the ability to have the same behaviour in different browsers, even […]

    July 6th, 2010 at 17:20

  43. […] HTML5 Parser er en fælles indsats blandt browserleverandører, blandt andet med det formål at alle hjemmesider skal vises ens uanset hvor mange syntaksfejl de måtte indeholde. […]

    August 12th, 2010 at 06:23

  44. […] 원저자: Christoper Blizzard – 원문으로 가기 […]

    August 12th, 2010 at 17:32

  45. […] Note that we didn’t even have to use XHTML in order to be able to embed SVG thanks to our new HTML5 parser. […]

    August 24th, 2010 at 13:49

  46. Tim Niiler

    I’ve noted that svg objects embedded with will show up in html documents, but then nothing that follows (html, or otherwise) will show up when loaded into FF4b4. The same documents work properly on FF 3.6.8. Am I missing something or is this a bug?

    September 7th, 2010 at 15:25

  47. matt

    At this stage of the game I’m not sure why anyone is still using clunky old FireFox.
    Sure, when our options were more limited it was a viable option; but with the browsers we have today FireFox is as outdated as Internet Explorer.

    September 7th, 2010 at 17:45

    1. voidmind

      Epic Troll

      September 7th, 2010 at 18:18

  48. Zach Hauri

    I couldn’t help but find this funny:

    “/ ! Warning: Remember that &PlusMinus; means that there are two solutions!”

    Like, holy shit, if you forget that +/- means two different solutions then the world will end and Satan will rise from hell. WARNING WARNING WARNING!!! BEWARE! CAUTION!

    But yea. Back OT now: HTML5 is bitchen.

    September 8th, 2010 at 18:54

  49. Alex

    Regarding system resources, I have been disappointed with Firefox 4 beta. I have quite a fast laptop with 4G of RAM, running Windows 7, and there is a marked increase in fan speed – and – oddly, an inexplicable sluggishness about the implementation. With luck these problems will be ironed out by product release. Meantime I’m sticking to 3.6.10

    October 5th, 2010 at 17:39

  50. WebManWalking

    Here’s something I expected would work in Inline SVG, but didn’t: Apparently the x, y, height and width attributes don’t correspond to the CSS and JavaScript DOM properties left, top, height and width, respectively. Or at least, when I try to modify them in jQuery animations, they don’t work.

    On the other hand, I **can** animate opacity, so the problem isn’t one of properly referencing the DOM elements. So the question remains, why can’t I modify left, top, height and width?

    October 29th, 2010 at 14:15

  51. WebManWalking

    P.S.: When I use a for .. in loop on the style property of the SVG elements in question, every property seems to be null. If I’ve assigned a property value it shows up as if in an array. (For example, when I set opacity, it showed up as style[0], even though style.opacity is where I would’ve expected it to be.) Also, when I tried to alert(this.width), as opposed to, I got “[object SVGAnimationLength]” or something like that.

    This was with Firefox 4 beta 6.

    October 29th, 2010 at 14:57

  52. Boris

    > Apparently the x, y, height and width attributes don’t correspond to the CSS and JavaScript DOM
    > properties left, top, height and width, respectively.

    That’s correct. They’re defined differently in SVG.

    > On the other hand, I **can** animate opacity

    Yes, SVG defines opacity in a CSS-compatible way.

    > why can’t I modify left, top, height and width?

    In brief, because the SVG spec says one thing and jquery assumes another thing. File a bug on jquery?

    October 30th, 2010 at 19:14

  53. WebManWalking

    Thanks for your quick reply, Boris.

    I’ve contributed 2 jQuery plug-ins before. I think it would be less whiny of me to simply figure it out and contribute another, rather than classifying it as a jQuery bug for someone else to fix.

    Does Firefox and/or HTML5 expose an Inline SVG JavaScript API with which I can accomplish the same thing as CSS property modification?

    November 2nd, 2010 at 07:54

    1. Boris

      You should be able to use setAttribute to change the x/y/width/height attributes.

      Alternately, for animation stuff, you could try to use SMIL to animate the values…

      November 2nd, 2010 at 08:25

  54. When will MathML be adopted widely enough to replace images for mathematical notation on the web?…

    Gecko and WebKit both support mathML. Like SVG, I think it wasn’t well positioned for widespread use until recently because it was difficult to include in an HTML document. With HTML5, both SVG and mathML can be included inline in HTML pages. See http…

    December 27th, 2010 at 02:34

  55. Jukka K. Korpela

    I’m puzzled: is the HTML5 parser now part of Firefox released versions, as I’ve understood? In versions that have the HTML5 parser, is it _the_ parser, or is it an alternative to the old parser? If they coexist, does the doctype declaration trigger the choice? Are there practical major implications, such as some legacy tags or attributes not recognized?

    March 9th, 2011 at 10:53

    1. Boris

      In Firefox 4, the HTML5 parser and the old parser are both present, but which one is used is controlled by a hidden preference, with the default being the HTML5 parser. A page can’t control which parser will be used.

      In Firefox 5, the old parser will be removed.

      March 9th, 2011 at 16:06

  56. ybochatay

    Météo-France now works with a full web application, based on firefox and svg. You can find demos with inline SVG at
    Please have a look if you have time.

    August 29th, 2011 at 01:53

Comments are closed for this article.