Shadow DOM, Pointer Lock and a new CSS Lexer

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

929 changes landed at Chromium’s repository last week, whereas WebKit’s received 626, totaling up to 1,555. Highlights include quite some progress on implementing the Shadow DOM and the Pointer Lock API.

Web Inspector’s Timeline Panel has been extended with three graphs, all hidden behind the Experimental Settings option, showing information about objects and events in the DOM. Hovering over a function in the Script Panel may now show an overlay with general information and it’s source-code and elements within iframes are selectable again.

The Flexible Box module implementation has been taught about distributed packing and now supports scrollbars for overflowing content, also taking the flex direction into account. Furthermore, floated pseudo-elements within table captions will now be positioned correctly.

In order to verify whether ES.next’s let keyword will be compatible with websites, Apple has reserved the word from normal usage in JavaScriptCore. Support for Uint8ClampedArray has landed for both V8 as JSC, values for the dropzone attribute will be normalized and various issues with radio-button groups have been fixed.

In terms of the Shadow DOM, registering of scoped stylesheets with the scoped element has been implemented and an initial version of the <content> element is now available as well. Following an API change and the actual interface, Vincent Scheib’ Pointer Lock API has made it into Chrome Canary as well.

Other changes which occurred last week:

And that’ll be all again, thanks for reading!

4 Responses to “Shadow DOM, Pointer Lock and a new CSS Lexer”

Both comments and pings are currently closed.

EGWUNYE FIDELIS S.

January 31, 2012 at 1:11 am

I SINCERELY APPLICIATE ALL YOU ARE DOING. I KNOW THROUGH YOU SUCCESS WILL COME, PLEASE CONTINUE YOUR GOOD WORK. THANK YOU.


Matt Diamond

February 1, 2012 at 2:02 am

Just grabbed the latest Chrome Canary build to check out getUserMedia support. While the flag does enable navigator.webkitGetUserMedia, it seems this method is little more than a stub… both { audio: true } and { video: true } result in a “not supported” error. Am I doing something wrong, or is it still too early to get my hands on functional getUserMedia support in Chrome/Webkit?


Matt Diamond

February 1, 2012 at 3:57 am

Okay just came across a working getUserMedia example in Canary… apparently they’ve implemented what I believe is the older spec where the user simply specifies “audio” or “video” rather than a dictionary object. So I stand corrected: getUserMedia works!