Ruby overhang, HTML5 track element and a full-screen button

Published on April 11th, 2011 in Browser Vendors, Google Chrome, Last Week, tech, WebKit. Version: Chrome 12

The 630 commits at WebKit and 707 commits at Chromium add up to a total of 1,337 commits. And I’m not even kidding. Highlights are two removed events, automated ruby overhang behavior and offline audio rendering for the Web Audio API.

Quite some visual changes have been made to Chromium. The concept of scrolling tabs has been introduced for the Touch UI, ensuring that selected tabs stay in the view. Users of Side Tabs will have noticed two new arrows at the top of the tab-bar, allowing you to scroll through the tabs upwards and downwards. The profile button has been moved a bit, making space for a new full-screen button and a stub implementation has been added for Panels, one thing I really miss for extensions.

New features have been given quite some attention. Feature defines have been added for an implementation of the <track> element, which means that work will be starting. The getUserMedia method and JavaScript bindings have been implemented for the Media Stream API and WebKit is now capable of rendering fonts using Skia, bringing its PDF rendering one step closer to handling Chrome’s print previews.

Following some discussion and a change to the HTML specification, WebKit has removed support for the onformchange and onforminput events. The CSS parser won’t accept #papayawhip as a valid color anymore, WebKit’s Server-Sent Events implementation will now only accept UTF-8 as its encoding and negative shadow spread should not round inset shadows. Finally, hidden iframes won’t receive focus anymore.

Dan Bernstein had a go at improving WebKit’s ruby implementation by adding support automated overhang, which means that ruby text can overhang characters adjacent to the base text. While this has become the default and only behavior for WebKit, as the ruby-overhang CSS property has not been implemented yet, the specification’s draft does not reflect the new initial value yet.

Now that the Web Audio API has been in development for well over a year, work has begun on making it testable. Offline audio rendering has been added to the AudioContext API and DumpRenderTree (the testing-framework) for WebKit’s Mac port has been improved with supporting audio tests.

Other changes which occurred last week:

WebKit’s GTK port is now capable of running WebGL!
Spin-buttons for numeric input elements are clickable again when large paddings are used.
A WebUI implementation for HTTP Authentication dialogs has landed for Chromium OS.
The default favicon to show for websites has been changed to the address bar’s little globe.
Tabs on Chromium’s Touch UI tab-bar will be using 32×32 pixel favicons, double their normale size.
TCP-classes have been renamed to Transport in scope of unifying APIs for TCP, UDP and SCTP protocols.
Dragging multiple tabs in Chromium will now show an accurate thumbnail showing all tabs.
Just pre-loading the metadata for video elements can now be done by setting preload=metadata.
Adam Barth’s Content-Security-Policy system can now block plugins, inline scripts, images, styles
and fonts and has been given an options directive.
A fast path has been added for rendering simple color-based backgrounds.
A recently closed option has been added to Chromium’s Touch UI New Tab-page.
Another fast path is now available for parsing simple CSS values, such as dimensions and colors.
Repaints during style recalculation will be deferred, improving performance.
The page up, page down, home and end buttons will now affect selection in the <select> element.
Bouncing for single-finger panning gestures on Windows Touch systems is now available in WebKit2.
Skia’s PDF back-end has been pulled in to Chromium’s repository and will be compiled for Print Preview.
The HTML5 <meter> element now uses the Shadow DOM, and <progress> has been refactored.
The new HTML5 Media Elements will now be rendered using Dimitri’s Shadow DOM as well.
Similar to Mac OS X, Chromium on Windows will now also fade tab titles.
The Bali release of libvpx, used by the WebM video codec, has been pulled in to Chromium.
Support has been added to the WebKit 2 API for Windows 7 gestures.
Incoming source can now be preload scanned even if the parser is blocked.
Web Inspector’s feature to export HAR-files of resource loading has been improved.
Several changes to Chromium’s Web Driver implementation add versioning and health checking.
Web Inspector’s protocol format will be updated towards the JSON-RPC 2.0 specification.
Searching in Web Inspector’s Resources panel has been fixed.
Some layout tests were added for Chromium’s detailed heap snapshots’s summary view.
Work in WebKit has begun on implementing an unified storage quota for websites.
Chrome will start gathering statistics on modal dialogs in unload events.

And that’s it again. If you hadn’t noticed yet, last Tuesday I announced that I’ll be joining the Google Chrome team in June. While the set-up of these updates may change, I definitely intend to continue making them!

8 Responses to “Ruby overhang, HTML5 track element and a full-screen button”

Both comments and pings are currently closed.

[…] im Blog eines Chromium-Entwicklers entdeckt, der bald ins Chrome-Entwicklerteam wechselt: Chrome bekommt […]

Peter, what are these Side Tabs? How do I open them?

Hey Andy L, if you navigate to about:flags, the first item in the list of experiments should be “Side Tabs”. If you enable it and then restart Chrome, there should be a new item in the tab-srip’s context menu to turn on side tabs.

However, I have a vague feeling these may only work on windows. And also the UI is kinda lame. Not terrible, but not up to the usual Chrome hotness.

You might want to note that “scrolling tabs” are only in the touch UI, not for the standard tabstrip.

@Jon Rimmer: Thanks for your reply.

Yeah, I can’t see that flag because I’m on a Mac. And I’ve just remembered reading about Side Tabs several months ago…

In fact, I love the idea. Back when I was using Firefox, I had a plugin for that. To me, Side Tabs make perfect sense, they allow us to see a longer piece of the title when many tabs are open.

But how will pinned tabs work with the Side Tabs feature? I hope each pinned tab won’t occupy a single whole (horizontal) position.

Peter, thanks! I’ve updated the post.

I’ve been using side tabs in Chromium for quite a while now (although Chrome-dev is my day-to-day browser) and, while it is quite rough, think it’s quite convenient if you often have a lot of tabs open. Right now they’re only available for Windows and Chromium OS.

Peter, apologies for the newbie question, but does this mean that the getUserMedia method is functional in nightly WebKit and/or Chromium builds, or merely that method stubs were added to be filled in later when someone actually implements them?

I’m really excited about the prospect of being able to access audio from the user’s microphone via javascript… I feel like device access is one of the biggest things html5 lacks vs. Flash.

Matt, the implementation of the HTML5 device-related APIs has begun but is not yet functional. Parts of the implementation will become functional over the next few weeks, which I look forward to as well!