Deferred printing stylesheets, text emphasis and Firebug-like CSS editing

Published on December 20th, 2010 in Google Chrome, Last Week, tech, WebKit. Version: Chrome 10

With 611 commits to the Chromium repository last week, and 449 commits to the WebKit one, my guess is that last week was the last week this year with more than a thousand changes. Highlights include support for the text-emphasis property and Web Inspector’s style editing panes, which now support Firebug-like editing.

Good news for fans of Firebug: editing CSS properties in Web Inspector will now be done with separate fields for the property’s name and value. Using the arrow keys to increment or decrement a numeric value will cause immediate changes again. Furthermore, some more work was done on the Extension API. Specifically, support was added for adding and overriding HTTP request headers.

As for specification related changes, the endedPlayback property for HTML5 media elements won’t return true anymore if the media file couldn’t be loaded. The -webkit-appearance property no longer accepts the value caps-lock-indicator and the delete method for IndexedDB Cursors has been added.

Work on two text-related CSS properties has continued as well. Firstly, Dan Bernstein has been working on the text-emphasis property, the final part of which landed last Friday. This property allows you to include small symbols next to the text, which Eastern Asian documents may use to emphasize the run of the text. Takumi Takano updated the values for text-combine to match the current CSS proposal.

Other changes last week include:

Kenneth Russell ported the Web Audio API’s FFTFrame implementation to MKL.
Stylesheets defined under the “print” media will now be downloaded with a lowered priority.
Chromium OS now also reports to accept the language “en”, following the Chromium browser.
Chrome Frame will now ignore IE’s conditional comment tags when parsing a HTML stream.
The --enable-page-prerender flag will now imply content prefetching as well.
Hyphens are now allowed in the domain names of e-mail addresses for the Chrome OS users UI.
The GTK WebKit port implemented two new accessibility roles: STATE_FOCUSED and STATE_FOCUSABLE.
Inline flow layers are now able to paint floating descendants.
Hooray! Inset box shadows will now render properly within Chromium.
No access will be given anymore in Safari to existing databases in private browsing.
The usual bits of work on the DOM UI / Web UI pages.
WebKit2 is now capable of displaying an IME on Windows.
The Qt port has implemented the File Reader API specification.
More fine-tuning has been done for the Web Timing implementation.

Since the next article will take another seven days: Merry Christmas! I’m going to spend my time with family, so expect next week’s post to be rather short. However, I probably won’t be the only one. Enjoy!

7 Responses to “Deferred printing stylesheets, text emphasis and Firebug-like CSS editing”

Both comments and pings are currently closed.

FF started to freeze up way too often, even if it was the only thing running. So I switched to Chrome and was happy to find out about Inspector as I thought I will die without Firebug.

I reverted the omnibox instant change this weekend.

‘Hooray! Inset box shadows will now render properly within Chromium.’

This is what I been waiting for. Thank god.

Thanks, Peter, I’ve updated the post.

I hope this comment is in context.

One annoying issue with the webkit dev tools when editing css, occurs when I edit the background position on a css rule. For example:

.my-background-image { background: url(/images/my_image.jpg) no-repeat 100px 100px; }

As soon as I edit the horizontal or vertical coordinates the image totally disappears from the dom.

I like the webkit dev tools but as a longtime Firebug user I would appreciate the ability to mess with background positioning.

One other side note about a beloved extension I use for Firefox called FireSass by @nex3. He has expressed interest in making a Chome Extension but in his words, “The issue is that the Chrome dev tools are built in to the browser, and thus (I believe) can’t be overridden by extensions.” IMHO SASS is the future of css authoring and it would be amazing if one of the premier web engines allowed for the development of this essential SASS tool.

All comments made with good intention 🙂 Not complaining just a little wish list.

Hi Josh,

I’ve tried to reproduce your problem (using a test case), but it seems to be working fine here. Could you note the browser + version + os you’re using, and perhaps some steps to reproduce it?

Web Inspector / Chrome’s Dev Tools will be getting an extension API, allowing authors to write extensions changing or adding behavior to the tools. The API hasn’t been exposed yet, but hopefully it won’t take too much longer, I can’t wait to start playing around with it myself!