Polygonal text-wrapping, the output element and “wicked fast” page loading

Published on in Google Chrome, Last Week, Standards, tech, WebKit. Version: Chrome 9

Although, statistically seen, it has been quite a regular week with 1,096 commits, 494 for WebKit and 602 for Chromium, there have been some very nice changes and announcements over the past seven days.

As for ongoing work, Dave Hyatt added support for selections on vertical text, and made sure that repaint invalidation now works with vertical lines as well. Dan Bernstein committed basic support for multiple writing modes in tables, including support for collapsing borders.

Meanwhile, Chris Rogers has been busy landing parts of the Audio API in WebKit. The RealtimeAnalyser (and its Node) landed about a week ago, just like the ConvolverNode and the AudioBufferSourceNode. A class to pass on the active buffers to the onaudioprocess event, named the AudioProcessingEvents Interface, has been committed as well. With more patches in the queue, progress on the API steadily continues.

Several announcements were done during one of the keynotes at Adobe’s MAX conference last month, some of which illustrated Adobe’s interest in HTML5. Mark Anders introduced EDGE, giving web developers an interface similar to Adobe Flash for creating HTML-based animations on their websites. Furthermore, it was also announced that Adobe will be contributing an animation framework to jQuery, as well as proposing and contributing changes to WebKit.

Last week Paul Gubbay demoed one of the prototypes the team at Adobe has been working at, showing text-wrapping around arbitrary shapes. It actually consists of two parts: a JavaScript framework, which is likely to work with jQuery, allowing the user to move the text and image around, as well as handling text reflows. The WebKit-side of the demonstration exists of a CSS property in which a polygon gets defined. This polygon defines a region to which text should be clipped, or from which text should be excluded.

Adobe is working together with Google to accelerate the process of landing the changes in WebKit, and thus making them available in a browser release. While the CSS property’s syntax is expected to evolve following community feedback, Adobe certainly intends to propose the feature to the CSS Working Group.

In terms of standards compliance, getComputedStyle received an update allowing you to retrieve all backgrounds instead of just the first one. The window.name property will now return an empty string for unnamed windows and frames and, in preparation of landing the actual interactive validation UI, a framework for showing the messages has been added as well.

Kenichi Ishibashi added support for the HTML5 <output> element, which is intended to represent the result of a calculation of two or more other form fields. After a way too long period of time, Erik Arvidsson landed an adjusted version of my patch to support the unprefixed box-sizing CSS property. Finally, since the IETF now seems to consider prefixed HTTP headers harmful, the “X-Purpose” header has been renamed to “Purpose”.

More updates which occurred last week:

Many thanks to Paul Gubbay and Alexandru Costin from Adobe for answering my questions. Also, this page contains a clear lead about what’s (hopefully!) to expect for next week ;)

5 Responses to “Polygonal text-wrapping, the output element and “wicked fast” page loading”

Both comments and pings are currently closed.

Andy L

November 9, 2010 at 5:05 am

Excellent post! Thank you, Peter.


Tobias

November 9, 2010 at 11:03 pm

Too bad that chromium disables spatial nav.


Michael Hixson

November 11, 2010 at 7:35 am

The page-preloading feature sounds interesting.

The “meta-bug” concept in the Chromium bug tracker is relatively new, isn’t it? Do you know why they chose to start using that?


Peter Beverloo

November 11, 2010 at 9:40 am

The meta template was introduced on the 20th of October, in place for the release-cycle of Chrome 9 and later.

Basically, because of the new, shorter (6-week) release cycle which is active now, many features will take two or more releases before they’re completely finished and ready to be included. The milestone-label system proved not to be sufficient for this.

Next to that, when a developer creates a new issue with the “New Feature” template, additional questions are asked for the internal process. Has the feature been reviewed for it’s privacy impact, does it need UI or adjustments to Google’s web services? It’s more complete and makes the tracking-issues clearer.