Thoughts on when to use Canvas and SVG

HTML5 Canvas and SVG are two exciting graphics features introduced in IE9. Both were covered in sessions at last week’s MIX11 conference in Las Vegas (see Deep Dive Into HTML5 <canvas> and Modernizing Your Website: SVG Meets HTML5).

These technologies can be used to address a range of graphic scenarios on the modern Web. With a lot of excitement around Canvas, there has been a tendency to ignore SVG, which, in many cases, is the better choice. Here I offer some thoughts on when to choose Canvas, SVG, or a combination of the two.

High Level Summary of Canvas and SVG

The following is a high-level summary of Canvas and SVG meant to frame a discussion of when to use one particular vector graphic technology over the other.

A Comparison of Canvas and SVG
Canvas SVG
Pixel-based (canvas is essentially an image element with a drawing API) Object Model-based (SVG elements are similar to HTML elements)
Single HTML element similar to <img> in behavior Multiple graphical elements which become part of the Document Object Model (DOM)
Visual presentation created and modified programmatically through script Visual presentation created with markup and modified by CSS or programmatically through script
Event model/user interaction is coarse—at the canvas element only; interactions must be manually programmed from mouse coordinates Event model/user interaction is object-based at the level of primitive graphic elements—lines, rectangles, paths
API does not support accessibility; markup-based techniques must be used in addition to canvas SVG markup and object model directly supports accessibility

SVG is known as a retained mode graphics model persisting in an in-memory model. Analogous to HTML, SVG builds an object model of elements, attributes, and styles. When the <svg> element appears in an HTML5 document, it behaves like an inline block and is part of the HTML document tree.

Canvas is a bitmap with an immediate mode graphics application programming interface (API) for drawing on it. Canvas is a “fire and forget” model that renders its graphics directly to its bitmap and then subsequently has no sense of the shapes that were drawn; only the resulting bitmap stays around.

One way to think of these is that Canvas resembles the Windows GDI API, where you programmatically draw graphics to a window, and SVG resembles HTML markup with elements, styles, events, and DOM-based programmability. Canvas is procedural whereas SVG is declarative.

The Scenarios

The following sections describe the technical benefits and limitations of both technologies, including a common sense approach to determining when one is appropriate for a given task. The illustration below illustrates where each scenario falls on a spectrum from Canvas to SVG with a clear cross over point in the middle.

Spectrum of Web vector graphics from canvas to SVG
Vector Graphic Spectrum

High Fidelity Complex Vector Documents

High fidelity complex vector documents have been, and will continue to be, the sweet spot for SVG. Highly detailed for viewing and printing, standalone or those embedded in a Web page. The declarative nature of SVG provides for tooling or client or server side generation of shapes from databases.

From the Real-world Diagrams demo on the Internet Explorer Test Drive:

Portion of SVG image zoomed out

The first image shows the diagrams, while the second image shows these diagrams zoomed in to 1000%

Portion of SVG image zoomed in

When you consider the usefulness for observing a large schematic, but the need to drill into the detail, or print the entire document for engineering purposes, the “scalable” in Scalable Vector Graphics becomes abundantly clear. For these reasons, we put high fidelity complex vector documents at the SVG end of our spectrum.

Spectrum from canvas to SVG showing high fidelity documents at SVG end of spectrum

SVG as an Image Format

Another common use for SVG is for static images within a Web page. With present-day high DPI monitors, developers must take into account the quality of graphics. The images below represent potential <li> bullet images styled via CSS. The following images are almost identical in presentation and file size.

Two circles zoomed out that look similar
SVG graphic on left, PNG rendering of it on right

If the developer wishes to reuse that image on a larger scale, or if the end user uses a high-DPI screen, the raster image becomes pixilated, or the need for a larger version of the file is necessary to preserve the fidelity.

Two circles zoomed in. SVG circle is crisp; PNG circle is blurry.
Zoomed SVG graphic on left, zoomed 4K PNG on right

SVG can thus serve as a nice image replacement format for even the simplest of images on a Web page. A suitable replacement by Canvas is not available.

Spectrum from canvas to SVG showing static images at SVG end of spectrum

On the other side of the spectrum, canvas brings speed to scenarios that don’t require retention of what was drawn. When Canvas was first introduced, many fun experiments were developed. I break these into three different scenarios.

Pixel Manipulation

Because Canvas is all about drawing and manipulating a pixel-based drawing surface, several experiments and showcases of Canvas include sophisticated algorithms to achieve impressive graphic effects such as ray tracing or filters.

The example below was written by Adam Burmister. The experiment creates an image by tracing the path of light through pixels on an image plane and simulating the effects of its encounters with virtual objects.

Spheres on checkboard background showing reflections

The author himself includes the following warning: “This is very CPU intensive. Your browser may appear to stop responding.” Therefore, though the Canvas API is capable of generating pictures such as this, it may not be such a good idea. As site author Adam Burmister summarizes, “Ray-Tracing [is] The Worst Application of JavaScript Ever.”

The same can be said for other scene-wide pixel manipulation. The following function replaces green pixels in one canvas with pixels from another, identically-sized canvas. A function such as this could be used with to create a video “green screen” effect.

function GreenScreenAtoB(a, b) {
    var aImageData = a.getImageData(0, 0, a.canvas.width, a.canvas.height);
    var bImageData = b.getImageData(0, 0, b.canvas.width, b.canvas.height);
    var aPixels =;
    var bPixels =;

    if (aPixels.length != bPixels.length) {
        window.alert("Canvases do not have the same number of pixels");
        return bImageData;

    var pixelCount = bPixels.length;
    for (var pixelIndex = 0; pixelIndex < pixelCount; pixelIndex += 4) {
        // grab the RGBA components of each pixel in b
        var r = bPixels[pixelIndex + 0];
        var g = bPixels[pixelIndex + 1];
        var b = bPixels[pixelIndex + 2];
        var a = bPixels[pixelIndex + 3];

        // if the b pixel is green, replace it with a pixel from a
        if (r == 0 && g == 255 && b == 0 && a == 255) {
            bPixels[pixelIndex + 0] = aPixels[pixelIndex + 0];
            bPixels[pixelIndex + 1] = aPixels[pixelIndex + 1];
            bPixels[pixelIndex + 2] = aPixels[pixelIndex + 2];
            bPixels[pixelIndex + 3] = aPixels[pixelIndex + 3];

    return bImageData;

It was a fun experiment, but like the ray-tracing example above, performance on
today’s machines falls short. I call these out though for one primary reason: such
pixel manipulation is simply not possible with SVG. It is the differentiating factor
between the two technologies. One manipulates pixels while the other manipulates
a model.

Whether creating realistic images from otherwise simple vector graphics or creating
green screen effects with video, these graphic scenarios are, in most cases, simply
not ready for prime time deployment on the today’s Web. However, certain scenarios
are responsive enough (such as applying filters to remove red eye in photos). These
pixel manipulation scenarios fall on the far left on the spectrum as a canvas scenario.

Spectrum from canvas to SVG showing filters and ray tracers at canvas end of spectrum

Hybrid and Crossover Scenarios

The most interesting set of use cases didn’t indicate a clear winner. These are
illustrated with two primary scenarios: Charting/Graphing/Mapping and Two-dimensional

Charts and graphs require vector graphics and either Canvas or SVG will work. However,
SVG is the often then better choice due to its intrinsic capabilities.

SVG Charting/Graphing/Mapping Scenarios

A popular subset of charts and graphs on the Web include:

  • Interactive Organizational Charts and Flow Charts
  • Interactive maps - path finding
  • Building floor plans
  • Engineering schematics
  • Seat maps for airlines or event venues
  • Generic data or financial charts (column, bar, line, scatter, donut, etc.)

For all of these SVG is the technology of choice because:

  • They can be generated easily from existing data by transforming XML to SVG
  • Static versions can be exported from Tools (including
    , Adobe Illustrator, Microsoft Visio, and various CAD programs)
  • They require precise user interaction
  • Third-party content providers can customize for Web authors using CSS styling
  • They have a need for accessibility

To illustrate more precisely, let’s examine the scenario of selecting a state on
a map of the United States.

Image of the state of Alaska

The detailed map of
shown above is public domain and available on
Wikimedia Commons

In SVG, the state of Alaska is represented by one <path> element with about
162,500 characters of geometric data in its “d” attribute.

<path id="AK" fill="#cdc3cc" d="M 777.5514,1536.1543 C 776.4904,1535.0933 776.7795,1530.0041
777.9416,1529.2859 C 781.3258,1527.1943 787.2657,1532.4522 784.8317,1535.3849 …"

For canvas, this shape could be created using a series of JavaScript calls:

function drawAlaska() {
    var canvas = document.getElementById("myCanvas");
    var ctx = canvas.getContext("2d");
    ctx.moveTo(777.5514, 1536.1543);
    ctx.bezierCurveTo(776.4904, 1535.0933, 776.7795, 1530.0041, 777.9416, 1529.2859);
    ctx.bezierCurveTo(781.3258, 1527.1943, 787.2657, 1532.4522, 784.8317,1535.3849);
    // 2,875 more path-drawing directives
    ctx.bezierCurveTo(1689.8261, 12.13753, 1689.1395, 12.17333, 1685.8848, 10.52683);
    ctx.fillStyle = "#cdc3cc";

In fact, it requires 2,878 path-drawing directives (moveTo, lineTo, and bezierCurveTo)
to draw this complex map of Alaska. Of course, lower resolution versions of this
map are possible. Considerably fewer lines of code would be required for Wyoming
and Colorado. 🙂

SVG mapping-based applications typically include an interactive experience involving
hover effects, selection, tabbing between items, and scaling. These operations require
only lightweight HTML concepts when using SVG, for example, for processing a mouse

<path id="AK" fill="#cdc3cc" onmousedown="window.alert('Alaska');" d="M 777.5514,1536.1543
…" />

or creating a hover highlight effect using CSS:

path#AK:hover { fill: yellow; }

An example of this type of interactive map can be seen in the Test Drive demo
Atlas zur Europawahl 2004 in Deutschland
, a visualization of the 2004 European
election results in Germany.

In canvas, creating either of these effects requires you code your own hit detection
using the event object’s mouse coordinates. You no longer have the context of the
shape. While there is the isPointOnPath() API, it only applies to the last path

Code can and does exist in the form of graphing libraries to enable specific hit
detection on graphs using pixel data to identify hits and hovers and are functional.
They also exist for SVG and will have better performance if designed to take advantage
of the SVG features.

Spectrum from canvas to SVG showing interactive charts and graphics at SVG end of spectrum

Canvas Charting/Graphing Scenarios

Canvas has its place for charting and graphing scenarios. To set context for this,
we need to examine the performance characteristics of both SVG and Canvas.

Sometimes there are outside influences that require a choice of technology that
is, or is mostly, independent of functionality. For SVG and Canvas, there are two
primary differentiators.

Developer knowledge, skill set, and existing assets will play a significant role
into the choice of technologies. If while creating a game, the developers have deep
knowledge of low-level graphic APIs and limited knowledge of Web technologies, the
likely technology to choose is Canvas (more on this later). In porting games, there
are tools that support moving from third party implementations to Canvas.

If performance is critical, often down to milliseconds, it is necessary to compare
the performance characteristics of the two technologies. This does not mean that
Canvas, typically considered highly performant, is the obvious choice. However,
for applications with large amounts of data that must be drawn at the pixel level,
Canvas is by far the better choice.

The weather map below does not require a large surface area, and the number of objects
on the screen is considerably high. With Canvas, these can be quickly drawn without
the cost of updating a DOM.

Weather map image

While the above image could be fully created in SVG using circle or ellipse elements
for the dots, the time to load many thousands of elements into the DOM would simply
be too slow. Wherever you see a large number of pixels or images, this is a good
clue that Canvas is the technology to use—whether this is astronomy, biological
cellular movement, or voice modulation displays. The limits here on how fast data
can be visualized are the speed of the CPU, the speed of the Canvas implementation,
and the speed of the JavaScript implementation.

Spectrum from canvas to SVG showing real-time, high-volume data presentation at canvas end of spectrum

Two-Dimensional Games

Casual gaming was the most complicated scenario to explore. Some initial observations:

  • Gaming libraries have leveraged lower level graphic APIs
  • Developer skillsets for the gaming industry are tuned towards these lower level
  • Many games are largely image- or sprite-based
  • Vendors such as Adobe are beginning to support Canvas as an export
  • Casual games do not often require sophisticated hit testing
  • Casual games do not usually have a prohibitively large number of “objects”

In gaming libraries, for example, popular physics engines, the graphics model is
independent and graphics becomes an implementation detail. Graphing geometries such
as boundaries, velocities, sizes, and positions are delivered to engines that subsequently
respond with velocities, collisions, and positions. Graphics are used only to get
the computed scene to the screen.

The concept of graphics being independent of the gaming logic is demonstrated by
two games, developed by the same author, intended to highlight both SVG and <canvas>:

While the game and demonstration logic is different, both are leveraging the same
physics engine, which tracks positions, collisions, velocities, and other physical
aspects of the gaming components. In the end, one utilizes SVG to draw (or move)
the elements of the game and the other redraw them with Canvas.

Most 2D casual games that are built today for HTML5 are using Canvas so we place
this scenario toward the Canvas side of the cross over point.

Spectrum from canvas to SVG showing 2D casual gaming near the center of spectrum

The Hybrid Scenario

Casual gaming also falls into the hybrid scenario is because there is an advantage
to leveraging the best of both technologies. For easy hit detection and user interaction,
a mostly opaque layer of SVG geometries can be used to position elements while the
underlying Canvas can more quickly position relevant images and provide real-time

There is a growing number experiences outside the casual gaming segment that are
finding it compelling to use a hybrid. When a scenario contains both the need for
visually intense dynamic graphics and animations (Canvas) as well as rich user interaction
(SVG), both of these technologies can and should be used. This is represented by
the Brain Power site from one of
our partners showcased on The Beauty of the
site. This Brain Power site—and others featured on The Beauty
of the Web—have found this delicate balance.

For user interaction and displaying portions of the brain, the site leverages the
higher-level geometries of SVG:

<polygon id="SensoryCortex" points="253,80,266,93,…" style="fill: rgba(0,0,0,0)"

For real time animations and special effects, canvas is used:

<canvas id="cnvDisplay" width="1920" height="1099" style="position:absolute;"


The analysis of existing vector graphic technologies available in the latest modern
browsers shows new scenarios can be created using standard Web technologies in an
interactive way.

Spectrum from canvas to SVG showing "the graphically rich Web" at the center of spectrum

The ongoing evolution of the Web continues to include richer graphics at its heart.
We’ve presented one point-of-view about applying these technologies to particular
scenarios. In the end, both Canvas and SVG are important components of the HTML5
graphically rich Web.

We’d love to hear how you’re applying these new HTML5 technologies to your Web sites.
Include URLs and, please, make sure your page works in IE9 by including the
HTML5 doctype, <!DOCTYPE html>, and using feature detection not browser detection
to know if SVG or Canvas are supported.

—Patrick Dengler, Senior Program Manager, Internet Explorer

Comments (26)

  1. Speednet says:

    This is one of the best IE blog posts I've read, thank you!

  2. Pino says:

    Very interesting indeed, thanks.

  3. Rob^_^ says:

    Excellent…I am interested in how SVG can be used in real world applications… particuarly in the medical industry in remote diagnostics… as I was expecting an uptake of this to replace high end unix workstations for xray remote diagnostics by the medical profession ( . Together with tiff support an off the shelf Win7 PC can replace a $100k dedicated unix workstation…

    I imagine that a similar application would be usefull in the aero-space industries… Is Boeing using IE9 for this purpose?

  4. says:

    I like saying: canvas is forprogrammers, svg is for designers/html coders.

    I like both, but use much more svg than canvas ( ).

    But I agree with Speednet  – nice post!

  5. meni says:

    WOW, a post with no dissing, no wonder there are no fanboys here going "hahaha, chrome got pawned". Just a nice post about web-standards (ahm, same markup that is ;-))

  6. meni says:

    Just to add to my last comment:

    I'm not a Microsoft guy as you probb guessed. For me, Mix11 was pretty bad. Mostly other browsers bashing plus a lot of propriety technology. (I thought mix was Microsoft's take on the web). But there were some bright spots, same as this post is for this blog:

    1) A talk about knockout.js:…/frm08

    2) Douglass Crockford (look his YAHOO videos about JavaScript) in a panel about JS [seek to 03:30:00]:…/ch9day1

  7. Senthil Kumar says:

    "Considerably fewer lines of code would be required for Wyoming and Colorado"…. hahahaha.. 🙂

  8. Rob says:

    This is one of the few blog posts worth reading but it only took Microsoft a decade to get here, where all other browsers have been, and where IE held back the web as far as SVG is concerned.

  9. @Rob says:

    Microsoft has been here before with a technology called VML; the SVG acronym didn't even exist then. The web held itself back for not accepting that technology as a standard.

    We can see the same thing happening with the video format. H264 is the accepted world-wide video standard. Only the web-browser market is still muddying the waters. I'll see you in about ten years from now, when that dust has finally settled.

  10. @Rob 2 says:

    ever heard of VML? go study a little before embarrassing yourself.

    @IETeam: thanks for this wonderful post. Definitely bookmarked!

  11. Rob says:

    Microsoft stopped development of VML in 1998 and SVG superseded it. What's their excuse for not implementing it till now?

  12. Bepo says:

    Very nice blog post, but I guess you could have gone more into detail in the implementation-based differences like for example the redrawing and the following caching problem with Canvas and the consequences on memory usage and battery life.

  13. Realities says:

    just a few notes on realities.  VML was a flop – no ifs ands or buts.  SVG was far superior when it superseded VML but Microsoft's refusal to adopt it force Adobe to create their SVG viewer for IE.  The Web stayed stagnant on the issue for years since it wasn't supported natively in IE and when Adobe realized there was little commercial reason to release such a plugin when Microsoft was making no efforts to push for Web Standards they decided to shift their focus elsewhere and discontinued support of the plugin.

    Meanwhile Firefox, Safari and others had native SVG support and companies like Google taking advantage of it for Google maps (with fallback for those stuck on IE to use VML) so Microsoft once again realized that their browser was far behind the times and they needed to get caught up.

    Microsoft finally caught up in IE9 with support for Canvas and SVG.  Microsoft's DOM support is still massively sub-par and the number of bugs and bad UI chrome is still growing but now finally MSFT has a browser that can at least play along with the better browsers.

    HTML5 Video became a huge issue when IE9 came to market.  Microsoft arrogantly came out saying they would only support the one non-open video format and out-right refused to support WebM.  They later realized with all the bad press this generated that this was a ridiculous move and added support for WebM via a plugin (as we've discussed before, plugins don't cut it, it needs to be supported natively).  Since Microsoft wasted so much money investing in h.264 they've dug their own hole and refuse to let it go.  The Web is Open, and there is nothing open about h.264.  Microsoft – please give up on this already and support an open video format by default, natively, or stop preaching that you support HTML5 because you most clearly do not.

    IE9 (and now IE10) present new issues as Microsoft still supports IE6 forcing web developers to support it too.  The Web at large still needs to wait for 3 FULL RELEASES of IE to be DEPRECATED before we can actually take advantage of any of these new features.  In addition we need to wait until users are off of XP, and even Vista if we want IE10 support.  This is the sole reason why developers were so violently angry with Microsoft holding back the Web for the past decade while they sorted out their internal mess.

    Worst of all, Microsoft has actually spread this problem to other platforms.  Windows Phone 7 shipped with a 10 year old browser… an unbelievably EPIC FAIL when entering the mobile market where every device has a browser built on a Web Standards based engine that is less than 2-3 years old. (its understood that this fall MSFT is scheduled to update WP7 IE to a branch off IE9, but that is again too little, too late)

    More importantly developers have lost complete faith in Microsoft due to their inability to admit mistakes and move on.  Case(s) in point:

    1.) Microsoft has refused to deprecate their invalid JavaScript behavior in the browser of making every single element with a name or id attribute an automatic global variable.  This causes all kinds of naming collisions and countless bugs and bad practices.  The rest of the Web is trying very hard to get away from this crap but it's hard to move forward while Microsoft is still dragging the anchor in the sand.

    2.) HTML5 full support.  Microsoft claims some garbage about IE9 being the only browser to support "HTML5 Natively".  Not only is the "natively" part complete bull, but the HTML5 part is also false.  There are several DOM API calls that Microsoft STILL doesn't support properly after decades of invalid support.  The HTMLElement.innerHTML setter method has been documented as broken for over a decade.  This is part of the HTML5 DOM API specifications and until Microsoft supports it fully, and properly… has no business claiming IE9 has full HTML5 support.

    Serious developers do not develop in IE anymore – they gave that up sometime in the last 10 years.

    To this day I will only test in IE for end user support and even then only add fixes for IE when it affects functionality (not visual rendering glitches) – and I would (and do) recommend the same for any other developers I meet.

  14. meni says:


    "Microsoft stopped development of VML in 1998 and SVG superseded it. What's their excuse for not implementing it till now?"

    What's microsoft excuse for the lost years? It took that many years to show that their Silverlight plan bombed, and they were left with no plan, so all this is the emergency plan headed by Dean Hachamovitz 😉

    Seriously, Microsoft was dragged into HTML5 while Mozilla, Google, Opera, and who not lead the way.

  15. Doug says:

    SVG also doesn't work on android browsers, at least versions before 3.0 I believe

  16. sad-but-true says:

    looks like only m$ guys are happy with their new browser. Maybe because the UI is not appealing/swift as compared to chrome, UI lacks customization/personalization as compared to Opera/Firefox (changing skins and using different profiles within a windows user account profile), there is no spell-checker, lack of pervasiveness in terms of XP-support and diverse tab-management as in all modern browser.

    F12 developers tool's look and feel is not really very smooth in terms of changing css property, lacks thumbnail preview on hovering the embedded image and it doesn't have a very user-friendly way to edit the html content on the fly if we compare it with firebug.

    I feel sorry for IE-browser being self-destructed by m$. According to, IE's usage share is falling down with 55.XX% this month (<- worst of all times and you still think that its too EARLY to provide a mere spell checker in your precious browser)! You are making effort for IE6 riddance and offering what? a rigid/steel browser with 50% reliability of not-crashing and 50% reliability of rendering SVG element (to wit; IE is the only browser that fails to load the SVG element on this page! Then obviously those 12% IE6 users will also stake the shares of G-Chrome or FF…

  17. Anonymous says:

    I don't like Microsoft myself. I know it can be fun to troll on blogs. But the trolling here is really getting annoying because:

    – This was a good blog post without any marketing BS.

    – IE9 may not be perfect, but finally, it's a Microsoft browser you can work with/develop for.

    – Other browser engines are buggy as well.

    I'd love to see all of you to complain as much about stupid Webkit bugs. For example, the :empty pesudo selector (which they claim to support) is pretty useless in Webkit based browsers, since this extremely simple piece of code won't work:

    p:empty { display: none; }

    What else would you want to do with empty elements apart from hiding them?

    The battle against non-standards-compliant Microsoft browsers is almost won, so get a life, guys …

  18. Stilgar says:

    I felt like I lost 30 IQ points just reading all the bullshit generated by anti-MS morons in the comments

  19. Andrew says:

    Great overview of the two technologies. Appreciate that both sides are represented appropriately. We've found some similar results the development of our charting library, which we recently updated to include SVG rendering in addition to HTML5 Canvas —

  20. Jon says:

    Doug is correct.  SVG does not work on Android devices, at least not before 3.0, because they did not compile that part of WebKit into the system.  So if the reason for using HTML5, canvas, or SVG is for cross-browser development, then SVG will not be viable for several years, until the old Androids die out.  Canvas seems to work (unless you are on iOS 3 or earlier, where the text functionality is broken), but it's worse than programming in Silverlight 1.0 (the Javascript version).  Now that IE supports both, it wlil help move in that direction, but the truth is that none of them are more viable for creating mobile apps than writing for the native device.  For all of the buzz around HTML5, I was extremely disappointed when I started trying to use it in real-world applications and ran into all of these roadblocks.  Don't think you can test something in IE9 and Chrome and then expect it to automatically work on any of the mobile devices.

  21. Peter says:

    I never read more bull**** than in some comments here (e.g. from "Realities"). Why you not read wikipedia before and after this troll around on Mozilla websites about missing or wrong implement things in Firefox? What's the point of post only half-true statements here? That only one more person use Firefox now? Be serious…

  22. jayp says:

    Interesting post, thanks!

  23. not-Peter says:

    If you are going to make a claim that others are posting half-true statements back it up with facts (you can't and thus you are lying!)

    What is on Wikipedia that we don't already know? and explain exact details of the wrong implementations in Firefox… because I haven't seen any.

  24. meni says:

    Doug, you are 100% right, i must admit. I was surprised to learn that the stock android browser doesn't support SVG. Thx. But as a mitigating factor, you CAN install mobile FF or Opera, though most users will not.

    To the point, this is an excellent post from the IETeam. Maybe you guys should consider creating another blog for posts like this, emphasizing the common ground instead of the devising stuff. I would think that Google and Mozilla would be happy to contribute.

    I'll repeat another plea of mine: Now is the time to push the web forward fast. Don't be afraid to create BAD standards, as they are better then proprietary sh!t.

  25. Peter says:

    Let's start with the fact that IE will not support any W3C working drafts or experimental specifications. WebM? Let's wait what MPEG LA say about this.

  26. who says:

    @Peter – who said IE will not support W3C working drafts?

    What about WebM? – what is your statement?

    Who gives a flying ____ what MPEG LA says about anything.  MPEG LA has nothing to do with supporting open video formats on the Web.  MPEG LA is a group dedicated to closed systems with DRM and licensing – none of which belongs on or is even part of the Web.

    Try again.

Skip to main content