RESOLVED FIXED 77853
<style scoped>: Allow <style scoped> as a direct child of a ShadowRoot
https://bugs.webkit.org/show_bug.cgi?id=77853
Summary <style scoped>: Allow <style scoped> as a direct child of a ShadowRoot
Roland Steiner
Reported 2012-02-05 22:54:08 PST
Currently, registration of scoped style elements expects an Element parent. For the purposes of shadow DOM, it must also work if it is a child of a ShadowRoot node.
Attachments
Patch (33.08 KB, patch)
2012-02-06 23:11 PST, Roland Steiner
no flags
Patch (34.93 KB, patch)
2012-02-09 00:46 PST, Roland Steiner
no flags
Patch (24.42 KB, patch)
2012-02-09 22:06 PST, Roland Steiner
no flags
Patch (23.91 KB, patch)
2012-02-09 22:24 PST, Roland Steiner
dglazkov: review+
dglazkov: commit-queue-
Roland Steiner
Comment 1 2012-02-06 23:11:02 PST
Created attachment 125771 [details] Patch patch - contains same forwarding as registration code in bug 67790. This was moved more or less verbatim from Element into ContainerNode. See discussion there regarding cleanup (moving into helper class or some such).
WebKit Review Bot
Comment 2 2012-02-06 23:14:03 PST
Attachment 125771 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'ChangeLog', u'LayoutTests/ChangeLog', u'La..." exit_code: 1 Source/WebCore/dom/ContainerNode.cpp:1092: The return type should use PassOwnPtr instead of OwnPtr. [readability/pass_ptr] [5] Total errors found: 1 in 24 files If any of these errors are false positives, please file a bug against check-webkit-style.
Roland Steiner
Comment 3 2012-02-06 23:47:23 PST
Note: the function the style bot complains about is virtual, so I can't change the signature (or at least that should be a separate patch). Will try to fix Win build failure in a follow-up patch, provided the general direction of the patch is OK.
Dimitri Glazkov (Google)
Comment 4 2012-02-07 09:46:56 PST
Comment on attachment 125771 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=125771&action=review > Source/WebCore/html/HTMLStyleElement.cpp:116 > + ContainerNode* scope = parentNode(); I have an alternative idea, but not sure if it's better. Instead of adding a new type of rare data, which seems rather high-caliber, we could declare a StyleScope interface, and have both element and ShadowRoot implement it. Since the rare data is just an int, we could just make it a member variable of the ShadowRoot. WDYT?
Roland Steiner
Comment 5 2012-02-07 16:31:00 PST
(In reply to comment #4) > I have an alternative idea, but not sure if it's better. Instead of adding a new type of rare data, which seems rather high-caliber, we could declare a StyleScope interface, and have both element and ShadowRoot implement it. Since the rare data is just an int, we could just make it a member variable of the ShadowRoot. WDYT? Hm, but how to get from [HTMLStyleElement]->parentNode() to the StyleScope interface? It seems I'd either need (a) dynamic_cast or (b) have to branch it like "if (parentNode->isElementNode()) { ... } else if (parentNode->isShadowRoot()) { ... }". In the latter case I could just call the respective implementation directly, without going through an interface (?). Alternatively, (c) I could declare the interface functions virtual on ContainerNode (thus making them directly accessible from parentNode()) and implement them in Element and ShadowRoot. Variant (d) of that: StyleScope could become a super-class of ContainerNode to encapsulate the interface, but implementation would still have to happen in Element & ShadowRoot. Using ContainerNodeRareData just seemed simpler to me... ;)
Antti Koivisto
Comment 6 2012-02-08 09:51:33 PST
Comment on attachment 125771 [details] Patch This seems wrong. Why isn't ShadowRoot an Element if it is supposed to act like one?
Dimitri Glazkov (Google)
Comment 7 2012-02-08 10:07:20 PST
(In reply to comment #6) > (From update of attachment 125771 [details]) > This seems wrong. Why isn't ShadowRoot an Element if it is supposed to act like one? Other than this behavior, there's really nothing about ShadowRoot that makes it look like an Element. It doesn't receive events, has no attributes, it's never rendered (so no styles or dimension/position information). Also, it can't be cloned into another ShadowRoot or appended to a document tree. (more here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html). If we were to make it an Element, we'd have to add a larger set of exceptions in handling the specific case of the ShadowRoot, compared to just this one.
Roland Steiner
Comment 8 2012-02-09 00:46:35 PST
Created attachment 126253 [details] Patch patch, should fix Win bot. Still ContainerNodeRareData version: it is the most straightforward, and I wanted to avoid making hasScopedHTMLStyleChild virtual, as it is used rather heavily in <style scoped> CSS code. However, if you still prefer any of the versions (a) to (d) of comment #5 - or '(e) something completely different' - I'm happy to change the implementation.
Dimitri Glazkov (Google)
Comment 9 2012-02-09 10:12:10 PST
Comment on attachment 126253 [details] Patch The patch doesn't seem to apply. Also -- can we not just reuse NodeRareData? Do we have to introduce the ContainerNodeRareData?
Roland Steiner
Comment 10 2012-02-09 22:06:44 PST
Created attachment 126451 [details] Patch Certainly can do! Updated patch, moved registration to Node / NodeRareData as suggested.
Roland Steiner
Comment 11 2012-02-09 22:24:37 PST
Created attachment 126456 [details] Patch Same patch as above, missed a small bit of cleanup.
Dimitri Glazkov (Google)
Comment 12 2012-02-10 09:22:28 PST
Comment on attachment 126456 [details] Patch This looks great, but can you please land it by hand? I could be superstitious and old-fashioned, but I'd watch the tree after landing this patch :)
Roland Steiner
Comment 13 2012-02-12 23:04:55 PST
Will do, once the tree goes back to a sane state.
Roland Steiner
Comment 14 2012-02-15 01:17:38 PST
Note You need to log in before you can comment on or make changes to this bug.