There is so much movement with existing, new, and experimental specs that it is often difficult to keep up. Lets have a look at some of them that are being implemented in browsers right now or in the very near future.
Replacing Mutation Events
DOM Mutation Events were deprecated in DOM 3 Events. This was due to a number of known issues that cause real world performance problem. The three main problems include the overhead required by event propagation, the excessive times they need to fire when a DOM mutation happens, and the amount of information that needs to be stored by the event due to needing to store both the before and after state of the mutation. These issues are summarised on the W3C Webapps wiki.
Due to the issues above it was decided that we need to define a replacement. Developers from both Chromium and Mozilla worked together to produce a proposal. This proposal is called Mutation Observers. The discussion can be followed on the WebApp mailing list. This was designed to avoid the pain points of DOM Mutation Events mentioned above. It is a recent proposal so there is no specification yet, but Google are starting to develop a vendor prefixed implementation in the very near future. This is a much needed part of the Open Web platform so it is good to see movement in this space if we are recommended not to use DOM Mutation Events.
Filter effects in HTML
This is one for those that like eye candy. Many of you will be aware of filters in programs like Photoshop. Examples include saturation, blur, drop shadows, saturation, etc. While these kind of advanced effects have not been possible in CSS, they have been available to SVG for quite some time (Except in Safari where it is switched off, and IE which hasn’t implemented it yet). For example for Opera’s Standards.Next event page in 2009, I added some blur, lighting, and sepia tone to age the photos using SVG filters.
CSS has always lacked a way to do this, but now filters will be allowed to apply to HTML content via CSS with the Filter Effects 1 spec. The filters spec is being realigned by both the SVG and CSS working group to apply to both languages. You will be able to apply SVG filters to HTML using the CSS filter property. As SVG filters can be quite complex to write and understand there will be a number of pre canned shorthands that map directly to a specific SVG filter. This is somewhat similar to how in CSS3 Transitions you can use property values like ease-in and linear in transition-timing-function rather than writing the corresponding cubic bezier. The current shorthands include:
There are also others under consideration. This is going to not only allow these filters to work in HTML but also make it easier to do the common filters in SVG too. Expect these filters to be (ab)used all over the web in the coming years. Mozilla’s Robert O’Callahan originally came up with the original prototype for SVG filters in HTML, as well as other related concepts such as SVG masks. Now that there is a spec in the works, Apple are starting to implement it in WebKit in the near future. This will reuse their existing SVG filters code, so that should hopefully speed up the development work. Filters in HTML has been one of my top pet bugs for a while when I worked at Opera, so hopefully Erik will implement it soon too ;).
Of the things most hotly contested in HTML5–with the possible exception of longdesc–the mechanism for adding machine readable semantic metadata to HTML is perhaps the most talked about. Microformats have existed for a number of years now, using existing HMTL attributes. RDFa looked to formalise this with its own set of attributes and grammar. The WHATWG community were not fans of RDFa and came up with their own approach called Microdata.
It is not clear who will win this particular battle yet, but Microdata already has one implementation in the form of Opera. It looks like one could become two as Motorola has just provided a basic implementation in WebKit. If it gets accepted in WebKit and is compatible with the Opera implementation then that will give us the two implementations needed for a spec to go to recommendation status.
Joystick and Gamepad Events
The Open Web is becoming a better gaming platform. Canvas started the craze, but now we also have WebGL (AKA Canvas3D) and Audio APIs. Mozilla believe that the next piece of the puzzle is the Joystick API. This will provide events for joysticks and games pads so that developers can listen for them in much the same way as the mouse or touch. Mozilla have a prototype of this API available to try.
This prototype has evolved into a draft Gamepad spec produced by Google and Mozilla. This provides a GamepadEvent event and a Gamepad interface, which provides access to information about the buttons and axes of the controller. Shame there is no force feedback ;). Google has now implemented a prototype in WebKit.
Dashes in canvas
Canvas doesn’t support the humble dashed stroke. Well, not in the spec anyway. There was much demand for this feature and thus Mozilla invented their own mozDash and mozDashOffset. Company100 (developers of the Dorothy browser) have implemented this for WebKit under the similarly but differently named webkitLineDash and webkitLineDashOffset. This follows the specified behaviour in SVG for stroke-dasharray and stroke-dashoffset, but only supports floating point numbers. As there is no spec yet and it isn’t even integrated into WebKit then don’t be surprised if this changes before shipping in a browser.
XBL2 is dead. Long live Component Model
XBL2 is more or less formally dead. There was an informal meeting recently in the Bay Area between a number of browser vendors to discuss its replacement; the Component Model. There is no official spec yet, but you can find a lot of information about the goals on the WHATWG Wiki. The basic aim is to allow new DOM elements to be created. For example if you would like to create controls for the video element you can create DOM elements and hide the implementation details from the actual document DOM using on of the building blocks of the Component Model; the Shadow DOM. This should allow HMTL to be much more extensible.
There are no implementations currently, but Google have started development on this feature in WebKit. Hopefully we will see the fruits of this labour in the near future.
This is just a hint of the new toys that are being implemented by browser vendors and we may get to play with in the near future. I’m sure Opera and Microsoft are also cooking up some tasty treats hidden away in their bug tracking systems. Its a good time to be in the web.