With 1,134 commits in the last week, development certainly is getting back on track after the holidays. This week’s highlights include some plans for improving the CSSOM, implementation plans for CSS Variables and the landing of Interactive Validation within WebKit. I won’t address H.264. Enough people have done that.
If you’re interested in updates related to HTML, Anne van Kesteren published an item on recent changes happening around the WHATWG. The article mostly covers discussions which took place on the whatwg@whatwg.org mailing list, and certainly is an interesting read!
Tab Atkins, member of the CSS Working Group and the Google Chrome team, has published the slides of a presentation he hosted last Wednesday. It talks about how the CSSOM, the interface between JavaScript and CSS, basically sucks. The presentation demonstrates four relatively new concepts:
- CSS Variables
By declaring a variable through the @var rule, its type and the value, anything from colors to lengths, rotations and functions can be defined and will be available to all CSS used in the document. Support for local variables will be available as well, through the @local at-rule.
@var petersh-paragraph-size length 12px;
@var petersh-paragraph-color color rgba(0,0,0,0);
p {
. color: var(petersh-paragraph-color);
. font-size: var(petersh-paragraph-size);
}
- CSS Mixins
Mixins come down to being able to extend any rule with certain, common properties. They take parameters similarly to CSS Variables, including the ability to have default values for them.
- CSS Nesting
Nesting in CSS, especially when used without classes or IDs, can be a pain. The @this at-rule will be introduced for usage in CSS rules. The selector you supply behind it will apply only to descendants of elements matched by the current rule. That clears the way for structures like this:
header {
. color: red;
. @this a {
. . color: blue;
. }
}
- CSS Modules
No, not the CSS Modules which make up CSS Level 3. CSS Modules basically are namespaces for CSS Variables and Mixins. Mixins and variables can still be referred to by prepending their name with the namespace’s name, or by including the @use at-rule to have the parser include all of them.
While the idea is fine, I personally think this shouldn’t be part of the specification. The use-case is easily obtainable by advocating authors to prefix their variable names, like “petersh-header-color” instead of “header-color”. Two types of namespacing, sharing similar syntax, is just going to cause confusion.
While the current code is only available on a few machines in Sydney, Google is planning to publish an initial specification this quarter, and implement the changes before the end of the year. Considering neither these plans for CSS Variables nor the CSS Mixins and Nesting have been shared on the www-style mailing list yet, it’ll be interesting to see how it will be received by other vendors. Related discussion from a few years ago has shown that it’s a fairly controversial issue, with many opinions being far apart.
Last Thursday, Kent Tamura landed support for the Interactive Validation UI using the new Shadow DOM model. With most bugs out of the way, messages and an –albeit internal– API being available for Chromium to enable the feature, it won’t be long before it becomes available in the nightlies.
In other specification-related news, the scroll event will now be fired asynchronously. The WebKitCSSMatrix object in the DOM now accepts none as a valid keyword, and using the toDataURL method for a canvas on Chromium will now composite onto a black surface when the destination format does not support an alpha channel.
Other changes which happened last week:
- Tony Gentilcore now is a WebKit reviewer, congratulations!
- Adam Barth is working on a proposal for embedding a security policy in an HTML document.
- He also announced to have finished moving WebKit’s source files to a separate directory.
- The about:sync page has been updated to use the new DOM UI displaying system.
- The media player from WebKit’s GTK port now features a slider to change the volume.
- Simon Fraser wrote an excellent article on his CSS3 Gradients implementation.
- Support for dropping data to WebKit2 has been implemented for Mac OS systems.
- Password synchronization has been enabled by default for Google Chrome.
- Some issues with Safari’s strict mode implementations have been fixed.
- The security model used chrome://-URLs has been updated, as described in this message.
- Three fixes in Safari’s JavaScript engine found via Mozilla’s jsfunfuzz.
- Crashed extensions will now be visible on the chrome://extensions page.
- Following this very commit, the –enable-page-prerender will now actually pre-render your pages.
- Chris Rogers added part of the Chromium-side for low-latency output for the Web Audio API.
And that’s all for this week!
Read more (7 comments) »
With the commit count being up 52 percent compared to last week, totaling 1,184 commits, activity has been a lot higher than two weeks ago. Highlights include Google Chrome 8, tomorrow’s announcement and lots of updates to standard support.
Exactly six weeks and over 8,472 commits after the release of Google Chrome 7, Google has updated the Stable channel to the 8th version of their browser. This release brings support for Element.classList, asynchronous script loading, support for the steps timing-function for transitions, the about:flags page and hyperlink auditing, enabled by default.
As a quick peek-ahead towards a feature for Google Chrome that’s currently scheduled for version 9, which would be around mid January: Google Cloud Printing. The idea is simple: connect your printer with GCP and you’ll be able to print to it from any computer or smart phone, regardless of where you are. Probably unrelated: an event will be happening in San Francisco tomorrow morning sharing some exciting news about Google Chrome. While I have a fair idea what it will be about, there is little point in more speculation.
WebKit has taken a huge leap forward in terms of support for various standards. ArrayBuffers may now be transmitted using XMLHttpRequest’s send-method, a form’s elements property now includes fieldset and keygen elements, getBoundingClientRect won’t truncate the coordinates to integers anymore and focussed <area> elements will no longer use the image’s focus-styles.
An <input type=color> will no longer accept named colors and the incremental property is now available on the DOM of all input elements. The toDataURL method of a canvas’ context in Chromium can now export the image as a JPEG, the marquee element’s properties have been updated per the HTML5 specification (besides the events) and, while they don’t have visual effects yet, support for the four text-emphasis properties from the CSS3 Text module was added.
Finally, support for both lower and upper Armenian list style types has been implemented and initial versions of the HTML5 <details> and <summary> elements have been added by Luiz Agostini. Even though they aren’t interactive yet, work has started!
Other interesting changes which occurred last week:
- Option elements will not be bold anymore for certain Chromium versions.
- The about:flags page will now show a drop-down for items where multiple values are possible.
- Hyperlink auditing (<a ping>) may now be disabled via the about:flags page.
- Two games have been made the default Apps: Entanglement and Poppit.
- A command line flag for accelerated layers is now available, from about:flags as well.
- data URLs within Chromium can now trigger downloads as well.
- The GTK WebKit port finished the implementation of the MSAA ROLE_COMBO_BOX.
- Pausing and resuming downloads now works for the WebKit2 architecture.
- A tab overflow problem with right-to-left text has been solved.
- The behavior of the decreasing outer-spin-button has been revised.
- The \s modifier for the YARR Regular Expression Engine now also matches BOMs.
- Safari on Mac OS X will be getting a panel for multiple suggestions for misspelled words.
- Intel’s Yuqiang Xian eliminated a large overhead for a certain way of writing to a canvas.
- The Qt port has enabled support for the Web Timing implementation.
- More fine-tuning for Chromium OS’ User Interface.
- Four more commits by Chris Rogers for the Web Audio API implementation.
No, of course I didn’t forget Web Inspector. The “revert to revision” system has been implemented for the revision-system in the Resources panel. The display name of an object will now equal its constructor rather than its type, copy(node) in the Console works again, the cookies tab for a Network resource will only show for Chromium, and, finally, the Inspector protocol has been cleaned up.
As already mentioned earlier in the post, the Google Chrome team scheduled an announcement for tomorrow. Be sure to keep an eye out for news and updates, I’ll certainly devote some tweets to the announcement!
Read more (8 comments) »
With 632 commits to the WebKit repository, and 608 towards the Chromium one -totalling 1240 commits-, it was a busy week. Safari seems to be gearing up for a new minor release, and Google pushed Chrome 7 to users participating in the beta-channel. Google also published a page explaining the differences between extensions, Packaged Applications and Hosted Applications.
Nikolas Zimmermann has done some amazing work on WebKit’s SVG implementation: almost all SVG Text layout-code has been rewritten. Because of this change, text in SVG files already consumes much less memory and performs better than it used to do. By splitting the layout process for texts into three phases rather than a single one, future patches can add various forms of caching. This will improve the rendering performance even more.
Following the WebM project, which provides a free and open-source video codec, Google has announced WebP: an image format based on VP8’s intra-frame techniques. According to Google’s announcement, using WebP will reduce the size of your images by an average of 39%, compared to today’s image formats.
In reality, I’m not so sure. Jason Garrett-Glaser, an x264 developer, concluded that the quality is poor, and that Google’s timing for announcing the format is odd. Jacob Miller, obviously being less biased, concluded that the compression schema indeed outperforms JPEG, but that WebP isn’t ready for real-world usage yet.
I absolutely agree that the timing surrounding this announcement is weird. There are some important features not (yet) available in WebP which could prove to be decisive in the success of the image format. I’m mainly talking about the limited file size it supports (a maximum of 16383 by 16383 pixels), no support for storing lossless images and no transparency (nor translucency?). For a future-proof image format, Google could also have looked at supporting other color-spaces (possibly even non-RGB, like the CIE XYZ one). It makes me think like the announcement was a bit rushed, especially due to a sentence starting with “we plan to add”…
In my opinion, one of the primary things lacking for web development was a convenient way to modify the classes which applied to an element. While jQuery offered some excellent methods to do so, a proper native way wasn’t available. For that reason HTML5 introduces the “classList” property, which provices such an interface to each element on your page. While support for the property was added to Firefox well over a year ago, Erik Arvidsson added support to WebKit last Monday!
Other changes this week include:
Starting next Thursday, Fronteers 2010 will be taking place at Pathé Tuschinski in Amsterdam. With speakers like Håkon Wium Lie, Christian Heilmann and Jeremy Keith it’s bound to become a success :). Finally, thanks to Finnur Thorarinsson for informing me about the issue, the Chromium Command-Line Flag RSS Feed will now properly include added arguments. They previously were included as if they got removed.
Read more (2 comments) »
Last week the CSS Working Group met at Opera’s office in Oslo, Norway, for a face to face meeting. Following tight planning, the members met three days in a row discussing topics ranging from the open CSS 2.1 issues, various CSS 3 modules and other subjects such as hit testing. Some of the results are clear: all open CSS 2.1 issues have been resolved and a range of specifications will have their priority increased (such as CSS Transitions and Transforms).
Furthermore, CSS 2.1 is expected to become a Proposed Recommendation by the end of the year. This would mean that the specification could be a W3C Recommendation early next year, allowing the working group to focus their attention to CSS 3 and beyond. During the meeting Mozilla’s David Baron also mentioned that Firefox will be implementing 3D Transforms, already available in Safari and Google Chrome.
As for Chromium and WebKit, a combined amount of 1282 commits were uploaded to their repositories. While this means there were fewer commits than to last week, there’s a lot more news to share about the projects. I’ll highlight some interesting items which occurred last week, and briefly list other interesting changes.
Firstly, it’s becoming more and more obvious to the Chrome team that their browser is lacking important features for the enterprise market. An area Google can tackle is policies. Policies are a way of defining the settings of the browser through the registry, Microsoft’s Administrative Template files or the, so far unannounced, ChromeOS Enterprise Daemon. Other policy and preference stores may be added in the future.
Policies allow companies to easily define common settings such as the proxy server to use, account synchronization and whether JavaScript should be enabled for websites. Unfortunately this also enables companies to block Chrome updates, but I’m sure the Chrome team will be looking at options to prevent people from doing this. Last week support for three new policies was added.
Another large update is the initial inclusion of the Google Chrome Labs page. Most other Google products, as well as Google itself, include a page with experimental features. Considering Chrome supports about 320 command line flags it won’t surprise you that adding such a page makes certain tests a lot more accessible. Google’s Nico Weber committed the initial version just over four days ago. You can try it out yourself by downloading a recent nightly and visiting about:labs.
The WebKit team has invested a lot of time in improving their support for various standards. Adam Barth and Eric Seidel enabled the last part of the new HTML5 Tree Builder: fragment parsing. Furthermore support for HTML5 compliant doctype switching was added, symbolic CSS3 list-style-types are now supported and file inputs now respect HTML5’s fake path. Finally, due to this addition, you can now use HTML5’s date input types to start making plans for your birthday in the year 275759.
Now that the new Tree Builder has been completed, except for a lot of fine-tuning of course, thousands of lines of code were up for deletion. The old Tree Builder itself wast removed on the 24th of August. Further cleanups were done with the removal of their current implementation of Mozilla’s XML Binding Language (XBL). It hadn’t been maintained in years, so the decision was made to remove it in total.
Further updates last week
Starting next Thursday I will be in Brighton, United Kingdom. Together with Krijn, Anne and Matijs I’ll be attending dConstruct 2010. Perhaps I’ll be seeing you there? 🙂
Read more (3 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) »
