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

[bugzilla-daemon at webkit.org]

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





--- Comment #11 from Roland Steiner <rolandsteiner at chromium.org>  2011-05-24 20:00:13 PST ---
(In reply to comment #10)

Disclaimer: Note that below I don't want to argue against your approach (it indeed is probably simpler than mine) - just trying to understand the implications!

> (In reply to comment #9)
> >It also means that that unique artificial id mustn't take part in the normal specificity resolution.
> 
> Can you explain a bit more here? Specificity is just an order in which the rules are applied. I don't understand how this approach would complicate anything here.

If we just rewrite a scoped selector "span" to "#<ID-of-scope-element> span" then the specificity would change, affecting style resolution later on. E.g.

<style>
    .red { color: red }
</style>
<p>
    <style scoped>
        span { color: green }
    </style>
    <span class="red">Should be red</span>
</p>

Without the rewrite, the ".red" selector has higher specificity, and the text should be red. With the rewrite, the scoped "#<id-of-p> span" selector has higher specificity, and the text would be green.

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.

> >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.

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