Removal of the CSS Variables implementation and performance optimizations

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

Last week the projects received another 1,126 commits, 615 for Chromium and 511 for WebKit. Some highlights include updated Terms of Service and the removal of the CSS Variables code.

To start off with improved standards support, the stepUp and stepDown API methods for certain input elements have been updated to match the specification in case step-mismatching occurs. The unloadEventStart property has been added for the Web Timing implementation.

In scope of the Web Audio API, event hooks were added for JavaScript Audio Nodes, as well as custom bindings for AudioNode. More work has been completed on vertical text as well: support for vertical text in ruby was enhanced and fonts with no vertical metrics will now synthesize baselines.

WebKit’s implementation of CSS Variables has been removed. Even though it has been disabled for ages and the implementation never shipped in stable builds, I’m quite a fan of variables. It just makes creating and, more importantly, maintaining large websites a lot easier. Nevertheless, since Google really wants the feature to be implemented, be sure to keep an eye out for this bug if you’re interested as well.

Implementation is one thing, but getting them standardized and available in other engines won’t be easy. With an essay like this around from a member of the CSS Working Group and a lot of discussion in general, reaching a consensus on any syntax, behavior or draft won’t be simple.

Other updates which occurred last week:

  • Google Chrome’s Terms of Service have been updated, adding additional terms for Enterprise use.
  • The style property on attribute nodes has been removed, except for Objective-C bindings.
  • Internally Web Inspector’s Storage Panel has been renamed to Resources Panel as well.
  • CSS files included for Chromium’s Web Inspector will be concatenated.
  • WebKit now really passes the Acid 3 test, as two bugs were cancelling each other out.
  • Synchronization of resizing the renderer for accelerated compositing no longer is Darwin-specific.
  • Downloads in Chromium may now be restarted if they previously have been cancelled.
  • Asynchronous file writers will now be available for Web Workers.
  • The fullscreen UA-stylesheet will now only be injected when the document is in fullscreen mode.
  • Multiple background images on an element won’t cause repeated repaints anymore.
  • More message-functions have been added in preparation of full support for interactive validation.
  • Navigating on websites with dark backgrounds used to result in white flashes -- it won’t anymore.
  • The focus ring on image maps has been updated to take zooming into account.
  • The spatial navigation’s node selection algorithm has been updated quite significantly.
  • The network-error pages will now only contain gradients if the user’s display supports high color depths.
  • DirectX diagnostics will now be gathered asynchronously on about:gpuinfo due to performance reasons.
  • A search box has been added to the DOM UI, but it doesn’t actually do anything yet.
  • The Omnibox Extension API has been moved out of its experimental status.
  • The “Edit Bookmark” dialogs on Chromium for Windows are now resizable as well. Great change really.
  • Paul Kinlan, part of Chrome’s Developer Relations team, evidently thinks development is moving slowly 😉

And that’s all for this week. If you happen to be a member of Fronteers, the annual general meeting will be held on the 24th of November. Furthermore, I’ll be giving a presentation about the Audio APIs on the 13th of December in Groningen, the Netherlands. If you speak Dutch and would like to attend, feel free to sign up!

3 Responses to “Removal of the CSS Variables implementation and performance optimizations”

Both comments and pings are currently closed.

Looking forward to your presentation in Groningen, cool stuff! 🙂


Jon

November 23, 2010 at 6:30 pm

Bert Bos’ argument against variables in CSS is just waffle and FUD in in opinion, and an example of the W3C believing its philosophical objections should override browser vendor’s wishes. That didn’t work out so well in the case of HTML, and I doubt it will here either.


Andy L

November 24, 2010 at 11:33 pm

Jon: Exactly. The W3C must put pragmatism & actual use cases before the theories of some of its members.

When ideas in our heads prevent us from being more effective, it’s time to abandon them.