Re: [webkit-dev] Implementing style scoped
On Wed, Sep 14, 2011 at 1:26 AM, Roland Steiner rolandstei...@google.comwrote: On Mon, Sep 12, 2011 at 4:21 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: Yeah. You're right. We should get Hixie to change the spec. I don't think we should implement currently spec'd behavior or change the name. That last option sounds exceptionally bad. Roland, can you post on that thread and request the spec change? Posted. :) In those threads it seems we arrived at a preliminary agreement: On Wed, Sep 28, 2011 at 2:49 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Sep 2011, Roland Steiner wrote: Hm, AFAICT Hixie's mail on www-style@ didn't raise any objections against the idea [of scoped selectors] itself, the discussion just revolves around what the exact syntax should be. Given that, what is the chance that we are able to go forward and declare selectors within style scoped as scoped, and leave the question how such selectors can breach the scoping as an orthogonal problem? Go for it. I recommend going with [@global] for now, too. Unless a better proposal gets put forward, I'll spec it in the near future. (So far nothing better has been put forward.) In this light, are there any remaining objections to implement this with 'scoped' as the attribute name? Cheers, - Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
On Mon, Sep 12, 2011 at 4:21 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: Yeah. You're right. We should get Hixie to change the spec. I don't think we should implement currently spec'd behavior or change the name. That last option sounds exceptionally bad. Roland, can you post on that thread and request the spec change? Posted. :) - Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
Ryosuke Niwa wrote: Why do diverge? It seems like we should at least prefix the attribute with webkit in the case spec changes in the future. See above linked discussion for details. In the end we felt limiting the selector matching to the scope is more natural, and - with the proposed exception providued by :root and :scope - is more flexible. However, naming the attribute 'webkit-scoped' may certainly be a good idea. Yes, please use webkitscoped (no - since this is content attribute?). The spec requests that vendor-specific attributes take names of the form x-vendor-feature: http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#extensibility So x-webkit-scoped would be the way to go. Ted ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
On Sep 8, 2011, at 2:28 PM, Roland Steiner wrote: Hi all, After several discussions on the whatwg@ mailing list and others, we would like to go forward with adding style scoped to WebKit. Overview: Style rules within style scoped only apply to the parent element of style scoped (the scoping element), as well as descendants of it. Any other nodes are unaffected. This allows authors to style specific parts of a page without requiring ID prefixes. It also has potential performance benefits, as scoped rules do not need to be evaluated outside their scope. As per discussion on http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html, our implementation would diverge from the current HTML5 spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-style-element) in that we would match selectors only up to, and including, the scoping element. E.g.,: It sounds like there wasn't consensus to make this spec change. In particular, Hixie's last comments seemed to disagree with the proposed change. My preferences would be: 1. Implement what the spec says rather than diverging. 2. Get the spec actually changed, or at least agreement in principle to change the spec, then implement the proposed behavior. 3. Make sure to webkit prefix it and maybe even call the attribute something other than scoped if we are not confident of the spec change coming through. It's definitely *not* ok to call the attribute scoped but not match what the spec says, in my opinion. I would strongly prefer #1 or #2 to #3. I don't have any particular opinion on the substantive issue, but I don't think we should just diverge without agreement from others. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
On Mon, Sep 12, 2011 at 4:11 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 8, 2011, at 2:28 PM, Roland Steiner wrote: Hi all, After several discussions on the whatwg@ mailing list and others, we would like to go forward with adding style scoped to WebKit. Overview: Style rules within style scoped only apply to the parent element of style scoped (the scoping element), as well as descendants of it. Any other nodes are unaffected. This allows authors to style specific parts of a page without requiring ID prefixes. It also has potential performance benefits, as scoped rules do not need to be evaluated outside their scope. As per discussion on http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html, our implementation would diverge from the current HTML5 spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-style-element) in that we would match selectors only up to, and including, the scoping element. E.g.,: It sounds like there wasn't consensus to make this spec change. In particular, Hixie's last comments seemed to disagree with the proposed change. My preferences would be: 1. Implement what the spec says rather than diverging. 2. Get the spec actually changed, or at least agreement in principle to change the spec, then implement the proposed behavior. 3. Make sure to webkit prefix it and maybe even call the attribute something other than scoped if we are not confident of the spec change coming through. It's definitely *not* ok to call the attribute scoped but not match what the spec says, in my opinion. I would strongly prefer #1 or #2 to #3. I don't have any particular opinion on the substantive issue, but I don't think we should just diverge without agreement from others. Yeah. You're right. We should get Hixie to change the spec. I don't think we should implement currently spec'd behavior or change the name. That last option sounds exceptionally bad. Roland, can you post on that thread and request the spec change? :DG Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
On Fri, Sep 9, 2011 at 12:28 AM, Roland Steiner rolandstei...@chromium.orgwrote: ad 3.) Implementation of scoped selector matching works as follows: .) scoped style sheet rules are contained in a separate map scoping element address - RuleSet .) add a field to ParentStackFrame that identifies the closest ParentStackFrame that refers to a scoping element .) during matching only check RuleSets that are thusly identified in ParentStackFrame (plus a slow path that climbs the tree in case ParentStackFrame isn't applicable), plus global rules .) add a 'scope' parameter to the matching functions that identifies the scoping element that limits the matching. Note that with this implementation rules in scoped RuleSets that are not in scope aren't even looked at. Also note that the actual selector data is NOT modified for this. I.e., a selector in a scoped style sheet is not different from a global selector. This has several benefits: Sounds good to me. We don't currently rely on ParentStackFrames to get any semantics right, it is just for performance optimization. You will need to take care that it is now functional (rebuild as needed) in all cases. Inroducing root should be ok for fastCheckSelector path too, testing against root element shouldn't be slower than testing against null. I was anyway thinking of moving the parent stack to SelectorChecker. With this it will actually be needed for querySelectorAll. antti .) no updating necessary if a style element is inserted or removed from the document, nor when the 'scoped' attribute is set/unset. .) paves the way for a trivial implementation of a similarly scoped querySelector[All]. .) for components: several component instantiations can re-use the same template style sheet without the need to clone its rules. Please let me know your thoughts, - Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
On Thu, Sep 8, 2011 at 6:51 PM, Ryosuke Niwa rn...@webkit.org wrote: Very excited for this feature! On Thu, Sep 8, 2011 at 2:28 PM, Roland Steiner rolandstei...@chromium.org wrote: As per discussion on http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html, our implementation would diverge from the current HTML5 spec Why do diverge? It seems like we should at least prefix the attribute with webkit in the case spec changes in the future. See above linked discussion for details. In the end we felt limiting the selector matching to the scope is more natural, and - with the proposed exception providued by :root and :scope - is more flexible. However, naming the attribute 'webkit-scoped' may certainly be a good idea. Can we take these steps behind a flag given the attribute doesn't work properly without some steps? I would prefer not to use a flag for the following reasons: .) I already have the basic functionality working, with the exception of scoped @keyframes and @font-face, so landing should not take a long time (I am currently in the process of breaking the patch up, and adding more tests). .) There are quite a few changes that add parameters to functions, etc., which makes adding a flag ugly. Cheers, - Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
On Fri, Sep 9, 2011 at 12:51 PM, Roland Steiner rolandstei...@google.comwrote: On Thu, Sep 8, 2011 at 6:51 PM, Ryosuke Niwa rn...@webkit.org wrote: Very excited for this feature! On Thu, Sep 8, 2011 at 2:28 PM, Roland Steiner rolandstei...@chromium.org wrote: As per discussion on http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html, our implementation would diverge from the current HTML5 spec Why do diverge? It seems like we should at least prefix the attribute with webkit in the case spec changes in the future. See above linked discussion for details. In the end we felt limiting the selector matching to the scope is more natural, and - with the proposed exception providued by :root and :scope - is more flexible. However, naming the attribute 'webkit-scoped' may certainly be a good idea. Yes, please use webkitscoped (no - since this is content attribute?). I would prefer not to use a flag for the following reasons: .) I already have the basic functionality working, with the exception of scoped @keyframes and @font-face, so landing should not take a long time (I am currently in the process of breaking the patch up, and adding more tests). .) There are quite a few changes that add parameters to functions, etc., which makes adding a flag ugly. Okay. SGTM. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Implementing style scoped
Hi all,
After several discussions on the whatwg@ mailing list and others, we would
like to go forward with adding style scoped to WebKit.
Overview:
Style rules within style scoped only apply to the parent element of style
scoped (the scoping element), as well as descendants of it. Any other nodes
are unaffected. This allows authors to style specific parts of a page
without requiring ID prefixes. It also has potential performance benefits,
as scoped rules do not need to be evaluated outside their scope.
As per discussion on
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html,
our implementation would diverge from the current HTML5 spec (
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-style-element)
in that we would match selectors only up to, and including, the scoping
element. E.g.,:
html
body
div id=bar class=X!-- A --
div id=foo !-- B --
style scoped
div { ... } // applies to B, C, D
.X { ... } // applies to C
.Y { ... } // applies to D
.X .Y { ... } // doesn't match
#foo { ... } // applies to B
#bar { ... } // doesn't match
div div { ... } // applies to C, D
div div div { ... } // doesn't match
#foo div { ... } // applies to C, D
div #foo div { ... } // doesn't match
#bar .X { ... } // doesn't match
.X div { ... } // doesn't match
.X + div { ... } // apples to D
.X + .Y { ... } // apples to D
/style
div class=X!-- C --
/div
div class=Y!-- D --
/div
/div
/div
div class=Y!-- E --
/div
/body
/html
If authors want to have a selector be able to bridge this barrier (but still
only apply to elements within the scope), we propose that the selector must
explicitly contain :root or :scope. E.g., with above HTML example:
:scope { ... } // applies to C
div:scope { ... } // applies to C
#foo:scope { ... } // applies to C
#foo:scope div { ... } // applies to C, D
#bar:scope div { ... } // doesn't match: match exceeds scope due to
presence of :scope, but A (#bar) isn't the scoping element
div :scope div { ... } // applies to C, D: match exceeds scope due to
presence of :scope
:scope div div { ... } // doesn't match: no 2 nested divs beneath the
scoping element B
:root div { ... } // applies to B, C, D: match exceeds scope due to
presence of :root, but still doesn't apply to elements outside the scope
:root div div div { ... } // applies to C, D: match exceeds scope due to
presence of :root
However, this functionality (esp. implementation of :scope) would not be
part of the initial patch series.
The implementation plan is as follows:
1.) Add 'scoped' to HTMLStyleElement.idl and HTMLAttributeNames.in, as well
as adding the required plumbing for the attribute
2.) Implement registering with the scoping element. For efficient matching
it is necessary that an element can quickly discern whether or not it has
style scoped as direct child(ren).
3.) Implement the meat of the matching (see below)
4.) Add support for scoped @keyframes and @font-face
Note: https://bugs.webkit.org/show_bug.cgi?id=49142 already has a patch for
steps 1-3 that works as advertised. In order to make it easier to review, I
would just break it up into smaller chunks as outlined above.
ad 3.) Implementation of scoped selector matching works as follows:
.) scoped style sheet rules are contained in a separate map scoping element
address - RuleSet
.) add a field to ParentStackFrame that identifies the
closest ParentStackFrame that refers to a scoping element
.) during matching only check RuleSets that are thusly identified in
ParentStackFrame (plus a slow path that climbs the tree in case
ParentStackFrame isn't applicable), plus global rules
.) add a 'scope' parameter to the matching functions that identifies the
scoping element that limits the matching.
Note that with this implementation rules in scoped RuleSets that are not in
scope aren't even looked at. Also note that the actual selector data is NOT
modified for this. I.e., a selector in a scoped style sheet is not different
from a global selector. This has several benefits:
.) no updating necessary if a style element is inserted or removed from
the document, nor when the 'scoped' attribute is set/unset.
.) paves the way for a trivial implementation of a similarly scoped
querySelector[All].
.) for components: several component instantiations can re-use the same
template style sheet without the need to clone its rules.
Please let me know your thoughts,
- Roland
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
Very excited for this feature! On Thu, Sep 8, 2011 at 2:28 PM, Roland Steiner rolandstei...@chromium.orgwrote: As per discussion on http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html, our implementation would diverge from the current HTML5 spec Why do diverge? It seems like we should at least prefix the attribute with webkit in the case spec changes in the future. The implementation plan is as follows: 1.) Add 'scoped' to HTMLStyleElement.idl and HTMLAttributeNames.in, as well as adding the required plumbing for the attribute 2.) Implement registering with the scoping element. For efficient matching it is necessary that an element can quickly discern whether or not it has style scoped as direct child(ren). 3.) Implement the meat of the matching (see below) 4.) Add support for scoped @keyframes and @font-face Note: https://bugs.webkit.org/show_bug.cgi?id=49142 already has a patch for steps 1-3 that works as advertised. In order to make it easier to review, I would just break it up into smaller chunks as outlined above. Can we take these steps behind a flag given the attribute doesn't work properly without some steps? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
