Monday, August 30, 2010
New SVG Web Release: Owlephant
The SVG Web team is proud to announce a new release. SVG Web is a drop in JavaScript library that makes it easy to display SVG graphics on Internet Explorer 6, 7, and 8 using Flash.
The new SVG Web release, like all our releases, is named after especially silly D&D monsters. The new release is code named Owlephant:

You've heard of Elephants, you've heard of Owls… put them together and you get the fearsome Owlephant. If you encounter one, be sure it will be the last thing you ever, um, encounter. Hoot…. stomp!
With this release we now score 55.45% on the SVG compatibility charts, almost at the same level as IE 9 (58%).
Major aspects of this new release includes overhauls and fixes for gradients, clipping, events, text placement, and more. It also includes a huge step forward in SMIL animation support, including being able to animate path segments and interpolate their values, scripting SMIL with JavaScript, and more.
This release has been built by the community, with major contributions from Bruce Duncan from VisualMining.com; Ken Stacey from SVGMaker.com; and the always awesome (and project co-leader) Rick Masters. Thanks to the many people like Michael Neutze, Bruce Rindahl, and more for their bug testing and evangelism!
Everything fixed in this release:
Please note that there are some breaking changes in this release that will affect code that uses older versions of SVG Web; more details here. Also note that SVG Web does not yet support the native SVG functionality in IE 9 preview releases.
The new SVG Web release, like all our releases, is named after especially silly D&D monsters. The new release is code named Owlephant:

You've heard of Elephants, you've heard of Owls… put them together and you get the fearsome Owlephant. If you encounter one, be sure it will be the last thing you ever, um, encounter. Hoot…. stomp!
With this release we now score 55.45% on the SVG compatibility charts, almost at the same level as IE 9 (58%).
Major aspects of this new release includes overhauls and fixes for gradients, clipping, events, text placement, and more. It also includes a huge step forward in SMIL animation support, including being able to animate path segments and interpolate their values, scripting SMIL with JavaScript, and more.
This release has been built by the community, with major contributions from Bruce Duncan from VisualMining.com; Ken Stacey from SVGMaker.com; and the always awesome (and project co-leader) Rick Masters. Thanks to the many people like Michael Neutze, Bruce Rindahl, and more for their bug testing and evangelism!
Everything fixed in this release:
- Issue 471 : Radial gradient different between Flash and Native renders
- Issue 349 : gradients with bounding box cooordinates are positioned wrongly on circles
- Issue 475 : 'this' not getting set correctly in SVG element event callback
- Issue 477 : The change in the size of the ClipPath area is not reflected by Flash Renderer.
- Issue 483 : Changing gradient stop does not trigger redraw of referencing elements
- Issue 484 : Dynamic clip-path attribute changes are not reflected.
- Issue 476 : set Element Problems and numerous SMIL issues
- Issue 489 : Support beginElement() for animation elements
- Issue 494 : SVGTextNode.onDrawGlyph not removing glyph clones
- Issue 495 : Support units-per-em on SVG fonts
- Issue 492 : 'button' property missing in mouse event object
- Issue 472 : get svg.js even more compressed with Google's closure compiler (30K reduction)
- Issue 499 : Object loaded svg with scripts not firing window load or SVGLoad event
- Issue 488 : Updating styles via Javascript does not visibly update child nodes in IE/Flash
- Issue 496 : Support exponents in path values
- Issue 502 : Radial Gradient userSpaceOnUse Matrix calculated incorrectly
- Issue 503 : Radial Gradient focalLen not used for stroke
- Issue 504 : Radial Gradient userSpaceOnUse Matrix calculated incorrectly for SVGCircle and SVGEllipse nodes
- Issue 497 : bad 'target' when click on text node
- Issue 342 : Event handler fires only after second mouse click.
- Issue 507 : Namespaced elements not allowed until svg element added to page
- Issue 158: Rotated text not rendering for native fonts (Mostly Fixed)
- Issue 467 : Namespace exception loading video example in IE8
- Issue 510 : Font Family not used when surrounded by single quotes in Flash 10.1
- Issue 57 : SVG default fill-rule 'nonzero' not supported by flash 9
- Issue 123 : Nested svg elements don't show up in the DOM correctly
- Issue 145: dynamically creating SMIL elements and attributes
- Issue 356 : Show SVG Web Release Name and Revision in Right Click Menu
- Issue 513 : getElementsByTagNameNS returning text nodes
- Issue 515 : Call handleEvent on EventListener objects passed to addEventListener
- Issue 517 : Elements with fill set to 'none' should produce mouse events but do not
- Issue 518 : Avoid redraw on change to pointer-events attribute
- Issue 523 : Event listener from object element may be applied to svg element erroneously
- Issue 522 : Need way to create element with self declared namespace
- Issue 525 : Image element not respecting display='none'
- Issue 524 : Jquery $(window).scroll event will not fire
- Issue 527 : Excessive messages for detached event listeners
- Issue 528 : Exception if remove event listener from detached element, then add to document
- Issue 321 : Support for animating path 'd' attribute (and interpolate between values)
- Issue 514 : clip-path not used when part of style attribute value
- Issue 526 : Object using clip path cannot have its opacity animated
- Issue 535 : Nested svg disappears when animated
- Issue 536 : Problems tracking whether elements attached to document or not
- Issue 537 : Animation added in onload listener does not initialize
- Issue 538 : Node removed while invalid causes endless frame listening
- Issue 539 : Animation with invalid or forward href causes exception
- Issue 540 : script stack space quota is exhausted by large svg file
- Issue 511 : Keyboard events are not supported properly
Please note that there are some breaking changes in this release that will affect code that uses older versions of SVG Web; more details here. Also note that SVG Web does not yet support the native SVG functionality in IE 9 preview releases.
Labels: announcement, release, svg, svgweb
Friday, August 27, 2010
Ajaxian.com
Just a small note that I've been doing most of my blogging on Ajaxian.com rather than here! I still blog here with the occasional update or opinion piece but mostly do things on Ajaxian.
Wednesday, July 14, 2010
An Ode to Ajaxian
Ben Galbraith and Dion Almaer of Ajaxian recently posted that they are stepping down as formal editors of the blog Ajaxian.
I just wanted to write a short ode to Ajaxian. Ben and Dion both literally created the Ajax community, founding a central watering hole for everyone to come around. Of any tech community I've been a part of, the Ajax/Ajaxian community has been the absolute best one. While Jesse James Garrett might have coined the term Ajax, Ben and Dion made it real and gave it heart.
Ben and Dion both helped me launch my JavaScript career, supporting me with mentions when I put out some new Ajax hack or toolkit. Without Ajaxian there wouldn't have been a place to post new updates; it's the Techmeme of the JavaScript world (not the Valleywag of the JS world, thankfully :)
I wouldn't be where I am in any possible way if it wasn't for Ajaxian and Ben and Dion. Thanks for all the hard work guys!
As HTML5 grows and slowly eclipses the Ajax community, lets hope we get as awesome a common community space as Ajaxian has been!
I just wanted to write a short ode to Ajaxian. Ben and Dion both literally created the Ajax community, founding a central watering hole for everyone to come around. Of any tech community I've been a part of, the Ajax/Ajaxian community has been the absolute best one. While Jesse James Garrett might have coined the term Ajax, Ben and Dion made it real and gave it heart.
Ben and Dion both helped me launch my JavaScript career, supporting me with mentions when I put out some new Ajax hack or toolkit. Without Ajaxian there wouldn't have been a place to post new updates; it's the Techmeme of the JavaScript world (not the Valleywag of the JS world, thankfully :)
I wouldn't be where I am in any possible way if it wasn't for Ajaxian and Ben and Dion. Thanks for all the hard work guys!
As HTML5 grows and slowly eclipses the Ajax community, lets hope we get as awesome a common community space as Ajaxian has been!
Labels: ajax
Monday, June 07, 2010
HTML5 Defined! It's Not Just a Marketing Term
There's been a fair bit of discussion recently about what some folks mean when they say HTML5. I use HTML5 in the wider sense, so it's only right that I take a stab at defining what I mean when I say something is part of HTML5.
From a very high level, when I say HTML5 I mean:
"Everything that is in the formal W3C HTML5 spec; everything that used to be in there but was broken out for various reasons; sibling and related technologies and developments like CSS3, SVG, EcmaScript 5, etc.; and experimental explorations that are pushing the boundaries."
I won't go into the reasons why I use HTML5 in these more expansive terms, as I blogged about that recently.
Going deeper, I've broken these down into separate areas:
One small note; there are actually two HTML5 specs, one maintained by the W3C and the other maintained by the WhatWG.
You need to understand that HTML5 began as a revolution to the established order, initiated by the WhatWG. A peace of sorts developed over the years, with the upstart "Web Applications" and "Web Forms" specs brought in-house to the W3C under the moniker HTML5. Over time I'm assuming that the W3C spec, when Final Call has happened, will be the canonical spec.
To simplify things below, I'm only referencing the W3C HTML5 spec for now. Here's how I would break things down based on what I said above; if you think something should be somewhere else or things get moved around email me and I'll update this (Last Updated: June 14th, 2010). If you want to know the state of where these technologies are implemented see caniuse.com; if you want your code to detect what is available see Mark Pilgrim's book for details.
From a very high level, when I say HTML5 I mean:
"Everything that is in the formal W3C HTML5 spec; everything that used to be in there but was broken out for various reasons; sibling and related technologies and developments like CSS3, SVG, EcmaScript 5, etc.; and experimental explorations that are pushing the boundaries."
I won't go into the reasons why I use HTML5 in these more expansive terms, as I blogged about that recently.
Going deeper, I've broken these down into separate areas:
- "HTML5 Strict" - Things that are strictly inside the W3C's HTML5 spec.
- "Referenced by HTML5" - Things that are referenced by the HTML5 spec and which can optionally be parsed into the DOM and displayed.
- "Broken out of HTML5" - Things that used to be part of HTML5 or its older iterations, called Web Applications and Web Forms.
- "HTML5 Family of Technologies" - Extended set of technologies not strictly part of HTML5 spec or referenced but likely to be used in conjunction with HTML5.
- "HTML5++" - More experimental technologies pushing the web forward that are not part of the HTML5 spec at all; may or may not see broader adoption.
One small note; there are actually two HTML5 specs, one maintained by the W3C and the other maintained by the WhatWG.
You need to understand that HTML5 began as a revolution to the established order, initiated by the WhatWG. A peace of sorts developed over the years, with the upstart "Web Applications" and "Web Forms" specs brought in-house to the W3C under the moniker HTML5. Over time I'm assuming that the W3C spec, when Final Call has happened, will be the canonical spec.
To simplify things below, I'm only referencing the W3C HTML5 spec for now. Here's how I would break things down based on what I said above; if you think something should be somewhere else or things get moved around email me and I'll update this (Last Updated: June 14th, 2010). If you want to know the state of where these technologies are implemented see caniuse.com; if you want your code to detect what is available see Mark Pilgrim's book for details.
"HTML5 Strict": Strictly Inside the W3C's HTML5 Spec
- HTML5 Doctype: <!doctype html>
- HTML5 parsing
- XHTML5 serialization
- Cleaning up edge cases of existing web content for greater compatibility
- New semantic, behavior, and application tags: section, nav, article, aside, hgroup, header, footer, address, figure, figcaption, time, code, var, samp, kbd, output, progress, meter, details, summary, command, menu, keygen
- Being able to nest H1, H2, etc. arbitrarily
- Sandbox attribute on iframes
- Video tag, API and events
- Audio tag, API, and events
- New form input types: telephone, search, url, e-mail, date, time, month, week, number, range, color
- New form abilities: multiple file upload; placeholder text; directing focus on initial page load; constraint validation by input type and properties
- New link rel types: alternate, archives, author, bookmark, external, help, icon, license, nofollow, noreferrer, pingback, prefetch, search, sidebar, tag, index, up, first, last, next, prev
- data-* attributes on elements to be used by JavaScript
- Offline Web applications
- contenteditable for editing
- Drag and Drop
- UndoManager for consistent undos
- Parsing empty and unknown tags into the DOM: <foobar />
- async attribute on SCRIPT tags
- PUT and DELETE methods for form submission
- Deprecated elements: acronym, applet, basefont, big, center, dir, font, frame, frameset, isindex, noframes, s, strike, tt, u
- getElementsByClassName
- innerHTML, outerHTML, insertAdjacentHTML
"Referenced by HTML5": Referenced from W3C HTML5 spec, including how to parse into an HTML5 DOM; HTML5 parsing engines can optionally include these in DOM and display them
- MathML
- SVG
"Broken Out of HTML5": Used to be inside of HTML5, Web Applications, or Web Forms specifications
- Web Sockets
- Local Persistent Storage (localStorage and sessionStorage)
- SQL Storage (in contention versus IndexDB)
- DataGrid
- Specific HTML5 Video codec: H.264, Ogg/Theora, WebM (contention between video codecs)
- Specific HTML5 Audio codec
- Device element
- Ping attribute
- Timed track model for media elements
- Canvas
- Microdata and Microdata Vocabularies (some level of contention versus RDFa and Microformats)
- Cross-document messaging
- Channel messaging
- W3C XMLHttpRequest specification
- Server-Sent Events
- Ajax Session History
- MIME type and Protocol handler registration
- P2P connections
"HTML5 Family of Technologies": Extended set of technologies not strictly part of HTML5 spec or referenced but likely to be used in conjunction with HTML5
- CSS3
- Flex Box Layout
- Multi-Column Layout
- Animations
- Transforms (2D and 3D)
- Transitions
- Masking and Effects (rounded corners, shadows, etc.)
- Gradients
- CSS3 Selectors
- Media Queries
- Web Fonts - CSS 2.1 @font-face + OpenType/WOFF (slight contention for OpenType vs. WOFF)
- W3C Geolocation
- Metadata - RDFa, Microformats (Some level of contention vs. Microdata)
- Web workers
- ARIA
- EcmaScript 5
- Faster JavaScript
- CSS styling of new HTML5 input types (color, range, etc.)
- IndexDB (in contention versus SQL Storage)
- querySelector/querySelectorAll
- GPU acceleration of HTML, Canvas, SVG, and CSS3 Animations/Transitions/Transforms
"HTML5++": More experimental technologies pushing the web forward; may or may not see broader adoption
- WebGL
- O3D
- Firefox Audio APIs
- XBL 2.0
Why I'm Going to Keep Calling it HTML5
Recently some people have gotten themselves in a tizzy about using the term HTML5 to refer to more than just the spec. I acknowledge that this is a noble quest, kind of like those who want to get the whole world to speak Esperanto.
Frankly it's an impossible task at this point. Language doesn't respect who came up with a term; it takes on a life of its own, and when a term has grown beyond one person you have to embrace and run with it.
I originally thought the term Open Web would become how people referred to these things. "Oh, CSS3, Geolocation, etc.? Those are Open Web technologies!" I was even part of a group here at Google called the Open Web Advocacy team that was all about pushing things like HTML5, CSS3, SVG, and more forward. You know what? The term Open Web never really took off; I would say the term "Open Web" and people would give me a quizzical look. I even tried boiling it down to a succinct set of bullet points about what makes something an "Open Web Technology," but no dice.
I was surprised when the term HTML5 ended up becoming the marketing brand -- I thought no one is going to use a technology term to refer to these things, but that is what happened.
We saw the same thing with the technical term Ajax and the more generic term Rich Internet Applications (RIA). Ajax took off, while the term Rich Internet Applications never went beyond being a somewhat awkward term. People like to use the specific (Ajax) versus the generic (RIA), so the term Ajax stuck and ended up growing to refer to any rich internet application (see?) that involved the use of JavaScript, JSON, dynamic page updates, and more.
The reason we are seeing the term HTML5 growing into our new generic term for the next wave of web technologies is because HTML5 is the real show here. Lots of ancillary technologies are riding the wave and opening HTML5 is making possible, including CSS3, SVG, and more.
In addition, most people in the industry, even the vast majority of web developers, don't really want to know about the specific sausage making behind HTML5. Do they really care that things like Local and SQL Storage were broken out of the main HTML5 spec? Do they care that the Web Socket protocol actually lives with the IETF now rather than being inside the HTML5 spec itself, as it originally was? Do they care about the "how many angels fit on the head of a pin" battles between HTML5 Microdata, RDFa, and Microformats? They don't. They just want to come up to speed on the newest developments and apply them to their jobs.
Sometimes when I want to be a bit more exact I will use the phrase "the HTML5 family of technologies" or "HTML5++", but both of those are a bit awkward and a mouth full.
Here's a challenge for you: if you can come up with a better term, AND actually get the mass of developers and industry to use it, then more power to you. Throw it out there and maybe it will take off. I doubt that will happen though. The language train has left the situation, and it looks like HTML5 is the new nom de guerre for a new iteration of the web.
As they say in Esperanto:
"Ne far monto el papulo monteto."
i.e.
Don't make a mountain out of a mole hill.
[Disclosure: I work for Google, but this is no way an official statement from Google and is merely my own personal ramblings on the topic.]
Frankly it's an impossible task at this point. Language doesn't respect who came up with a term; it takes on a life of its own, and when a term has grown beyond one person you have to embrace and run with it.
I originally thought the term Open Web would become how people referred to these things. "Oh, CSS3, Geolocation, etc.? Those are Open Web technologies!" I was even part of a group here at Google called the Open Web Advocacy team that was all about pushing things like HTML5, CSS3, SVG, and more forward. You know what? The term Open Web never really took off; I would say the term "Open Web" and people would give me a quizzical look. I even tried boiling it down to a succinct set of bullet points about what makes something an "Open Web Technology," but no dice.
I was surprised when the term HTML5 ended up becoming the marketing brand -- I thought no one is going to use a technology term to refer to these things, but that is what happened.
We saw the same thing with the technical term Ajax and the more generic term Rich Internet Applications (RIA). Ajax took off, while the term Rich Internet Applications never went beyond being a somewhat awkward term. People like to use the specific (Ajax) versus the generic (RIA), so the term Ajax stuck and ended up growing to refer to any rich internet application (see?) that involved the use of JavaScript, JSON, dynamic page updates, and more.
The reason we are seeing the term HTML5 growing into our new generic term for the next wave of web technologies is because HTML5 is the real show here. Lots of ancillary technologies are riding the wave and opening HTML5 is making possible, including CSS3, SVG, and more.
In addition, most people in the industry, even the vast majority of web developers, don't really want to know about the specific sausage making behind HTML5. Do they really care that things like Local and SQL Storage were broken out of the main HTML5 spec? Do they care that the Web Socket protocol actually lives with the IETF now rather than being inside the HTML5 spec itself, as it originally was? Do they care about the "how many angels fit on the head of a pin" battles between HTML5 Microdata, RDFa, and Microformats? They don't. They just want to come up to speed on the newest developments and apply them to their jobs.
Sometimes when I want to be a bit more exact I will use the phrase "the HTML5 family of technologies" or "HTML5++", but both of those are a bit awkward and a mouth full.
Here's a challenge for you: if you can come up with a better term, AND actually get the mass of developers and industry to use it, then more power to you. Throw it out there and maybe it will take off. I doubt that will happen though. The language train has left the situation, and it looks like HTML5 is the new nom de guerre for a new iteration of the web.
As they say in Esperanto:
"Ne far monto el papulo monteto."
i.e.
Don't make a mountain out of a mole hill.
[Disclosure: I work for Google, but this is no way an official statement from Google and is merely my own personal ramblings on the topic.]
Friday, April 09, 2010
New SVG Web Release: Dracolisk
I'm proud to announce a new release of SVG Web. Our tradition is to go geek-tastic and name them after classic D&D monsters. This release is named Dracolisk, a crossbreed of a basilisk and a black dragon.
The Dracolisk is a truly fearsome creature, able to turn an enemy into stone with merely the gaze of the basilisk coupled with the acidic breath of a black dragon. Someone get that monster a breath mint.

The fixes and additions in this release:
About SVG Web and SVG:
SVG Web is a JavaScript library which provides SVG support on many browsers, including Internet Explorer, Firefox, and Safari. Using the library plus native SVG support you can instantly target close to 100% of the existing installed web base. SVG itself stands for Scalable Vector Graphics, an open standard that is part of the HTML 5 family of technologies for interactive, search-engine friendly web vector graphics.
The Dracolisk is a truly fearsome creature, able to turn an enemy into stone with merely the gaze of the basilisk coupled with the acidic breath of a black dragon. Someone get that monster a breath mint.

The fixes and additions in this release:
- Issue 378: Undefined variable in svg.js source code
- Issue 435: Regression: test_js1.html and test_js2.html fail
- Issue 421: Reuse XML ActiveX object on Internet Explorer
- Issue 431: unsuspendRedrawAll not wired to several methods
- Issue 428: setAttribute gives error for undefined or null attribute value (Flash renderer)
- Issue 264: Text with fractional font-size not displayed
- Issue 405: Support x,y lists on tspan for positioning native font glyphs
- Issue 440: Text with large font-size displays smaller
- Issue 447: Text placement changes with different viewboxes
- Issue 296: appendChild of existing child should move it to the end
- Issue 462: clipPath outside of def tag renders and blacks out the image
- Issue 415: Dynamic change of HREF on <use> to different local definition does not work (setAttributeNS())
- Issue 456: xlink:href attribute on images does not properly change with the Flash renderer
- Issue 460: Event type is not passed through when mouse events are raised.
- Issue 465: Stretched images have no smoothing
- Issue 375: Problem with using svgweb and jquery together
- Issue 402: Make sure SVG Web and Mootools work together
- Issue 403: Make sure SVG Web and Prototype.js work together
- Issue 404: Make sure SVG Web and Ext.js work together
- Issue 438: Support SVG 'RenderingProperties' CSS Values for Performance Vs. Quality Tradeoffs
- Issue 437: Slow rendering with mitered corners
- Issue 452: Parsing complicated long path statements extremely slow
- Issue 251: data-path configuration via meta tag
- Le Roux Bernard
- Li Yang
- Jonathan Pasquier
- Michael Neutze
- Ken Stacey from svgmaker.com
- Karl from Zilles.com
- k5tm from morrisons.us
- bjtxmql
- David Stern
- drjlove
- Thomas Kelder
- Gregorio Palama
- rdworth
- Evan Adams
- antihadron
- alain.couthures
- Eugene Lazutkin
- Jeff Schiller
- Duffy.Ty
- rxt360
- don.barthel
About SVG Web and SVG:
SVG Web is a JavaScript library which provides SVG support on many browsers, including Internet Explorer, Firefox, and Safari. Using the library plus native SVG support you can instantly target close to 100% of the existing installed web base. SVG itself stands for Scalable Vector Graphics, an open standard that is part of the HTML 5 family of technologies for interactive, search-engine friendly web vector graphics.
Labels: open source, open web, release, svg, svgweb
Subscribe to Posts [Atom]