For some vendor-specific CSS research I’m doing, I’ve created an overview of vendor-prefixed CSS properties that are currently supported in the four most popular rendering engines. The overview also contains references to the specifications they’re part of (if any), non-prefixed versions in other browsers and some notes on special conditions of a property.
One thing I noticed when creating the overview, is the amount of non-standard properties in WebKit. Looks like they got some catching up to do in terms of documenting their features. If you have any feedback or corrections, feel free to post a comment or poke me on Twitter!
Read more (11 comments) »
Today, exactly 217 days after the first Internet Explorer 9 announcement, Microsoft has released the third Developer Preview of the latest version of their browser. One of the most awaited and unannounced features this preview brings is the addition of the HTML5 Canvas Element. Defined in section 4.8.11 of the HTML5 specification, already implemented in all other major browsers, and now upcoming for Microsoft’s Internet Explorer 9: 2D Canvas is a go!
The history of <canvas>
The first signs of the -then still proprietary- element were committed to the WebKit source tree by Richard Williamson on the 25th of May, 2004. Apple’s idea came down to exposing Mac OS X’s Quartz drawing system to JavaScript and HTML in order to ease up writing graphical widgets for the Apple Dashboard. Consequently, as both products share the rendering engine, the element became available in the Safari browser as well.
In July of that year Dave Hyatt announced the new element on the Surfin’ Safari blog. This immediately brought up a lot of controversy, of which Eric Meyer’s post is a clear example: “What the bleeding hell?!?” In defense, Hyatt elaborates Apple’s rationales for including the proprietary features and said to submit a proposal to the WHATWG lists, however, it never came. Ian Hickson therefore, despite his opinion on how Apple handled the new elements, reverse engineered a draft based on available source code.
A few years earlier, late October 2001, Joe Hewitt opened bug 102285 in Mozilla’s bug tracker. Sharing the same name and rationale, his proposal was to implement a custom painting control to Mozilla’s XML User Interface Language. Interestingly enough, Brendan Eich, founder of the JavaScript language, tore down the idea as something for rendering fanboys. The patches were never used, and inclusion in official builds was unlikely, as Eric Murphy stated in the discussion.
On the first day of April in 2005 Mozilla’s Vladimir Vukicevic uploaded a patch featuring basic canvas functionalities, which opened the road for further work in Firefox. While this first implementation only worked on Linux due to different color formats on Windows and Mac OS X, the release of their “Deer Park” project late November, known as Firefox 1.5, featured a cross-platform implementation of canvas.
Opera introduced the <canvas> element mid 2006 with their Opera 9 release, in quite a humble way (can you see it without searching?). This meant that all major browsers, with the exception of Internet Explorer, implemented the element natively. However, it didn’t mean that the element was unusable, as Google’s ExCanvas and Mozilla’s IECanvas projects brought limited support for the element to Microsoft’s browser.
The long and juridical path to standardization
The path to proper standardization wasn’t very smooth. This began with the lack of a proper proposal coming from Apple’s side, resulting in the initial specification being based on reverse engineering works by Ian “Hixie” Hickson, editor of the HTML5 specification. In 2005, Jayant Sai brought up an initial idea for drawing text on a canvas, which later got formalized into a decent proposal by Stefan Haustein.
However, not everything went nice and smooth. After Mozilla Firefox and Opera had implemented the element, Apple’s Senior Patent Counsel Helene Plotka Workman sent a message to the WHATWG and Ian Hickson stating that Apple believed to have intellectual property over the canvas element, and would only consider to release these IP Rights if the Web Applications draft would become a formalized draft standard with the W3C.
Despite the fact that the rationale behind Apple’s message was unclear, the timing of their message was interesting. Exactly a week before, the W3C would be re-launching the HTML Working Group. Less than half a year later, in February 2008, the first draft of the HTML5 specification was published as a W3C Working Draft. On the 18th of June that year, Apple disclosed patent 11/144384 for use by the HTML5 specification. The same patent has been disclosed in six other jurisdictions, enabling the WHATWG to continue including <canvas>.
Going 3-dimensional with WebGL
More recently, on December 10 last year, Mozilla’s Arun Ranganathan announced the first draft of the WebGL specification. While you would expect the specification to be hosted by either the WHATWG or the W3C, because it defines a context for the HTML5 Canvas Element, WebGL is available at Khronos. This can be explained by the fact that the specification originally was intended as a simple binding of OpenGL ES2.0 to JavaScript, whereas the Khronos consortium already hosted the OpenGL ES specs.
WebGL is the second context that can be used with the <canvas> element. As said before, it has been based on the OpenGL ES 2.0 specification and provides a JavaScript interface for 3D graphics. The specification has evolved out of an experiment by Mozilla’s Mozilla’s Vladimir Vukicevic. He first demoed the possibilities in his “Web Graphics: Canvas, SVG, and more” talk at XTech 2006, and later announced as the “moz-glweb20? context. Opera published their opera-3d context late 2007, but decided to add abstraction in order to leave the door open for other implementations based on, for example, Direct3D.
WebGL is a specification in which all browser vendors, with the exception of Microsoft, participated. This can be clearly seen by the fact that nightly builds of Firefox, Google Chrome and Safari contained implementations of WebGL. While Opera actively participated in discussions, they have yet to release a public build containing the 3D context. Nokia has announced WebGL support in a new firmware version for their Nokia N900 phone.
Of course, Google hasn’t been silent either. In May they announced the ANGLE project, which basically translated OpenGL calls to their DirectX equivalents. Two weeks later, on April Fools’ this year, Googler Chris Ramsdale announced a WebGL port of the Quake II Game Engine.
No really, Thank You, Microsoft!
Even before the Internet Explorer 9 announcement, Microsoft tried to move the Canvas 2D context to its own module. There was no word about <canvas> in the first two Developer Previews, and the company’s position could best be described as vague. In May, Microsoft Evangelist Giorgio Sardo publically stated that he would like the element to be included, but also added that the company was in no way committed to Canvas.
More recently, at the SVG Working Group meeting earlier this month, Internet Explorer’s General Manager Dean Hachamovitch stated that the team wouldn’t be talking about implementing Canvas at that point. However, he added the following: “all your graphics needs will be taken care of, and I’m smiling broadly.” Today they finally confirmed the suspicion a lot of web developers have been having for months: the 2D canvas has been included in Internet Explorer 9.
Thank you, Microsoft, you’ve just made us smile broadly as well.
Read more (7 comments) »
Last Friday Maciej Stachowiak submitted a patch for supporting the HTML5 hidden attribute in WebKit. While supporting new features the HTML5 draft specifies usually is a good thing, I’m having quite some doubts about the added value of the new attribute. Shelly Powers submitted an issue to the HTML Working Group with quite an extensive change proposal, which has led to a decent amount of discussion on the subject.
Something which undoubtedly has been affecting the discussion are the other issues opened by Powers, which propose removal of <progress>, <meter>, <aside>, <figure> and various attributes. While her rationales often are decent and complete, it’s more of less becoming a vengeance: getting anything removed from HTML5 which does not directly improve semantics or accessibility. While I disagree with removing tags like <meter>, I do believe removing the hidden attribute would be a good idea.
What exactly is the hidden attribute?
It’s one of the clearest and most straightforward definitions of an attribute available. Defined in section 8.1 of the HTML5 specification, any element which has the attribute should be considered irrelevant and thus shouldn’t be rendered by the browser. However, the specification also defines that the attribute should not be used for content that could legitimately be shown in another presentation, like tabs or collapsible menus.
Using the attribute is really simple, take the following snippet as an example:
<section hidden>
<h1>The HTML5 hidden-attribute</h1>
<p>
This text should not be displayed by a browser.
</p>
</section>
While the example could contain any element, as the hidden attribute can be applied on all HTML elements (including on <html>), I think it’s quite clear. The section, including all its contents, should not be rendered by the browser, even though it will be available in the DOM and for search engines.
The primary problems I see with the current definition of the hidden attribute are the following:
- Its purpose is going to be misunderstood — it will be abused.
When I’m thinking about use-cases for the hidden attribute, one of the first things that comes to mind is using it for tabs. Easily hide any tab which isn’t active at that very moment without having to use a CSS class like “hidden-tab”. This is, however, wrong. Tabs could be defined as a form of presentation, which specifically has been excluded by the specification as a use-case.
- There are two identical alternatives available, one of which is widely used already.
The first alternative is quite clear: use a CSS class or inline style which sets the “display” property to none. The second alternative would be using the “aria-hidden” attribute, which would be identical after adding a CSS attribute-selector hiding the element. Laura L. Carlson of the Accessibility Taskforce has already replied to the proposal stating that the accessibility gains are negligible, and given “aria-hidden” takes precedence over the normal display property, using both statements could create a contradiction. Browsers could automatically assign the “aria-hidden” attribute/role to elements which are hidden if accessibility would really be an issue here.
- It’s a clear layering violation.
Now that a fair number of presentational elements have been removed from HTML5, such as <u>, <font> and <center>, layering problems are becoming more visible. Layering means using HTML strictly for the content, CSS for the presentation and any JavaScript code for behavior of the page, which the hidden attribute is violating. Considering all the attribute does is setting the display property to none, the attribute barely is different from tags like <u> and <i>.
The added semantical value of @hidden
Of course, since the attribute has been accepted as a feature of HTML5, it isn’t all bad. The attribute initially was named “irrelevant” but was renamed to “hidden”, mostly because the former is unclear. Having native attributes which could be used to address accessibility is one of the more important use-cases for the attribute. Web developers are much more likely to include a “hidden” attribute, than they are to type aria-hidden=”true”. In fact, most of the developers won’t even know what aria is in the first place.
On top of that, it could be beneficial for search engines. Even today the more popular spiders, such as GoogleBot and Yahoo Slurp, do not download or parse the CSS code used on any page. Consequently, all hidden content on a page will therefore be included in the search results, which leads to less accurate search results. The text you’re searching for is not per definition visible on the page itself, it might very well be (legally) hidden using JavaScript or CSS.
Keeping the attribute in the spec, or remove it?
I personally support Shelly’s proposal to remove the hidden attribute. Even though there is a semantical improvement, mostly for applications which are not capable of parsing CSS, a possible improvement in terms of accessibility and the ease of simply hiding an element, I believe the attribute is too prone to being abused, imposes a layering violation, already has two valid and widely used alternatives and does not add sufficient value in order to be included in specification.
Furthermore, your browser does not support the attribute yet 😉
Read more (7 comments) »
