[Webkit-unassigned] [Bug 49142] Implement HTML5 style scoped attribute

Wed May 25 08:46:18 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=49142

Dimitri Glazkov (Google) <dglazkov at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackalmage at gmail.com

--- Comment #12 from Dimitri Glazkov (Google) <dglazkov at chromium.org>  2011-05-25 08:46:18 PST ---
> Also, the scope element might already have an ID of its own that can't be overwritten. Although we may be able to re-use that instead of generating a new one, that is another issue that needs to be tracked.

Ah, I think I understand the source of confusion now. The scoped-id is not going to interfere with element id. It's a parallel structure that's like id.

> > >If I understand correctly, it would also meant that we have to update the Document-wide style rule set whenever an element is inserted or removed from the DOM that has a scoped style associated in its shadow DOM.
> >
> >I think that's something that needs to be tackled orthogonally. This problem is still in place with all other stylesheets removal/addition.
> 
> But inserting or removing an <x-foo> that happens to have a scoped style declaration in its shadow DOM is likely a far more common occurrence than specifically adding/removing a style sheet to/from the Document. Esp. note that it doesn't have to be the <x-foo> directly - attaching/detaching any subtree that contains an <x-foo> would need to trigger the update, as would adding/removing an <x-bar> that happens to be composed of an <x-foo>. 
> 
> Also, I would argue that adding/removing style-sheets to/from the Document is understood to have performance implications, while adding/removing <x-...> elements may not, esp. if the <x-foo> comes from some widget library.

This is a good point. The approach with scoped-id creates no room for reuse optimizations. It is the approach that we know we'll have to re-evaluate once we get to that point. So here's what we need to determine:

1) Overall design of the approach where CSSStyleSelector is TreeScope-based, and the rules are coalesced using TreeScope hierarchy.

2) Whether this design's complexity and performance impact outweighs the quick gains we can make with scoped-id approach.

I can see that this is a classic pay-now or pay-later decision.

Also, cc-ing Tab, because he had bright ideas on scoped stylesheet specificity.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.