[whatwg] Styling <details>
dglazkov at chromium.org
Sun Jan 6 11:36:26 PST 2013
On Wed, Jan 2, 2013 at 9:10 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 2 Jan 2013, Boris Zbarsky wrote:
> > On 1/2/13 4:37 PM, Ian Hickson wrote:
> > > Wait, Web Components isn't solving this? I thought this was one of the
> > > main use cases of Web Components.
> > [...] and it is certainly not doing:
> > 4) Defining the browser-defined "custom" widgets using the
> > capabilities of #2 such that authors can in fact style them.
> Why not? This seems like a pretty core feature. Without being able to do
> this, how can anyone reliably extend an existing widget, for example?
That's a good question! I am certainly interested in--and have been working
on--solving these use cases.
In fact, if you point your Chrome Dev/Canary to http://jsfiddle.net/nL747/,
you will see that you can indeed style an existing details/summary combo
just fine, using Shadow DOM (please pardon the bugs in WebKit <details>
implementation, we know they exist and are fixing them)
This is possible because Shadow DOM specifies that all HTML elements must
behave as if they already have an existing, UA-provided shadow tree (
which in turn allows the author-created shadow trees to properly override
(and even include) those UA-provided shadow trees.
You should be able to do the same exact thing with every other element
(though there's a very tricky issue with IMG, VIDEO, OBJECT, et al. about
the nature of "the insides" of the actual replaced content that will need
to be first resolved by CSS WG). So I wouldn't call this exactly vaporware
The remaining interesting question is how these shadow trees are created?
There are three ways:
1) Using shadow DOM API, in plain JS, as shown in the fiddle.
2) Using Custom Elements (
which enables authors to extend existing HTML elements to create new
3) Using Decorators (
http://www.w3.org/TR/components-intro/#decorator-section) to give new
shadow trees to existing elements.
Hope this helps.
More information about the whatwg