- From: <bugzilla@jessica.w3.org>
- Date: Tue, 27 Mar 2012 02:47:23 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16519 --- Comment #4 from Roland Steiner <rolandsteiner@chromium.org> 2012-03-27 02:47:22 UTC --- (In reply to comment #3) > Why? I just invented a new selector, surely I can invent a new behavior for it? > :) Impossible is nothing, of course :) but I do think it could open quite a can of worms: That would mean the presence of :host allows a selector to exceed the scoping element (where FWIW we've decided against this with :scope and :root and went with @global instead). But not only that, it would allow a rule to STYLE an element outside the scope - at least I suppose that's the main purpose (?) - something that's not even possible with @global. Allowing access to the host element looks even fishier if the <style scoped> in question is not a direct child of the ShadowRoot, but happens to be at some arbitrary point within the shadow DOM, where there are elements "in between". Lastly, it also raises the question what, e.g. ":host div" means (or whether it's allowed). To be sure, I don't have any good answer for all of this either. Dropping the requirement to ignore non-scoped <style> elements could resolve it. Another brainstorming thought: what about a @host rule instead? This would have the advantage that the breaking behavior is explicit, and makes sure only the host element is affected (rules inside @host can match the host element only) E.g.: @host { div { background-color: white; } .warning { background-color: yellow; } .important .warning { background-color: orange; } } -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 27 March 2012 02:47:25 UTC