I wanted to share this with you guys because we've been talking a lot about this particular topic over the past few days. It looks like the proposal is *to move /content/ back to the previous ::content syntax, /shadow/ back to the previous ::shadow syntax, and /shadow-deep/ to just /deep/*. These changes are now captured in a draft spec which you can monitor to keep tabs on any changes.
CSS Scoping Module Level 1 <http://drafts.csswg.org/css-scoping/> Sorry for all of the churn, but after working with /content/ for a little while it was decided that the new combinator syntax (/content/) was all cost with little gain. For instance, using /content/ meant having to select the content element on the left hand side (usually done with a * for brevity) and specify a top level element immediately to the right of the combinator, even if you weren't targeting that element. Ex: * /content/ ul li The previous pseudo selector did not have this same limitation so you could just do ::content li. The /content/ syntax also prevented the use of >, because you can't have a combinator followed by a combinator. So it would be impossible to do * /content/ > .my-thing. Again, the pseudo syntax does not suffer from this limiation, ::content > .my-thing is totally valid. Obviously it's super annoying for early adopters, like you guys, because we go one way, then another, then back to where we started :) But after using the new syntax it just didn't feel right and we wanted to make sure we weren't shipping something that folks were going to hate years into the future. On Thursday, March 20, 2014 1:38:06 PM UTC-7, Sergey Shevchenko wrote: > > Possible... > > > On Wed, Mar 19, 2014 at 4:08 PM, Eric Bidelman <[email protected]<javascript:> > > wrote: > >> That may be because polymer's shimming supported both in a small >> deprecation window? >> On Mar 19, 2014 6:02 PM, "Sergey Shevchenko" >> <[email protected]<javascript:>> >> wrote: >> >>> >>> On Wednesday, March 19, 2014 2:22:09 PM UTC-7, Eric Bidelman wrote: >>>> >>>> IIRC, an invalid selector in Blink will make the entire rule not work. >>>> So even though the second rule is valid, the first (using ::content) is no >>>> longer valid and the rule is thrown out. >>>> >>> This makes sense... However, I can't explain why the following worked >>> then: >>> >>> :host[direction=up], :host([direction=up]) { >>> ... >>> } >>> >>> This was after Chrome had switched to the latter syntax, but Dartium was >>> still using the former. Maybe it's that :host([direction=up]) wasn't "as >>> broken" as /content/ from the Blink's perspective? Anyway, that doesn't >>> matter anymore, I guess. >>> >>> >>> >>>> FWIW, disruptive changes like this won't happen when the native stuff >>>> snips. We're so close to that inflection point that final spec updates >>>> are >>>> still being made. It's an unfortunate side effect of using features when >>>> they're still behind a flag. We've tried to announce Blink updates on this >>>> list, but it's understandable not everyone sees those updates :) >>>> >>> Can't wait until we flip the native support for everything and are in a >>> more-or-less stable land! :) >>> >>> >>>> On Mar 19, 2014 3:18 PM, "Sergey Shevchenko" <[email protected]> >>>> wrote: >>>> >>>>> Thanks, Steve, Eric and Rob. One more question: I can't get the old >>>>> and the new syntax to work when the two selectors are separated with a >>>>> comma and listed in front of a single rule: >>>>> >>>>> /* Doesn't work: */ >>>>> ::content > *, * /content/ * { >>>>> color: red; >>>>> } >>>>> >>>>> /* Works: */ >>>>> ::content > * { >>>>> color: red; >>>>> } >>>>> * /content/ * { >>>>> color: red; >>>>> } >>>>> >>>>> This is very inconvenient, especially for large rules. We need to keep >>>>> both for a while for the code to work across the latest Dartium and >>>>> Chrome >>>>> on Windows/Max/Linux. I was able to get similar old-vs-new syntax to work >>>>> before, e.g. when :host.something changed to :host(.something). >>>>> >>>>> Also, could changes like this be rolled out gradually, with a >>>>> transitional period when both syntaxes are supported and the old one >>>>> reported as deprecated, e.g. in the console? This abrupt change has >>>>> disrupted our work here at Spark quite a bit yesterday. >>>>> >>>>> On Tuesday, March 18, 2014 10:56:48 PM UTC-7, Rob Dodson wrote: >>>>>> >>>>>> Hi Hoa, >>>>>> >>>>>> I think that would be... >>>>>> >>>>>> :host([direction="left"]) > content[select=":nth-child(2)"] >>>>>> /content/ * >>>>>> >>>>>> >>>>>> I think I got that right :) Let me try to explain... >>>>>> >>>>>> You no longer need to do :host(.foo:host) to match a shadow host with >>>>>> class .foo. Previously you needed the second :host in there to make sure >>>>>> you were selecting only the shadow host and not an ancestor. Now we have >>>>>> the :ancestor() selector, so :host() only targets the shadow host itself. >>>>>> >>>>>> as we mentioned ::content has been replaced by /content/, so that >>>>>> part changes >>>>>> >>>>>> lastly, the thing to the right of /content/ must always be a top >>>>>> level element. so content /content/ * will select any distributed top >>>>>> level >>>>>> element, which looks like what you were previously trying to achieve >>>>>> with >>>>>> ::content > * >>>>>> >>>>>> one thing to note, there's a chrome bug that causes /content/ * >>>>>> .something-else to not work at the moment (https://code.google.com/p/ >>>>>> chromium/issues/detail?id=353606). But I think content /content/ * >>>>>> will still work... Let me know if you have issues :D >>>>>> >>>>>> >>>>>> On Tue, Mar 18, 2014 at 10:30 PM, Hoa V. Dinh <[email protected]>wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On the same topic, I was wondering how to write the equivalent of >>>>>>> such a selector with the new syntax: >>>>>>> :host([direction="left"]:host) > >>>>>>> content[select=":nth-child(2)"]::content >>>>>>> > * >>>>>>> >>>>>>> See: >>>>>>> https://gist.github.com/dinhviethoa/af8a952892fdf8a8c046 >>>>>>> >>>>>>> and >>>>>>> >>>>>>> https://github.com/dart-lang/spark/tree/master/widgets/lib/s >>>>>>> park_split_view >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> -- >>>>>>> Hoa V. Dinh >>>>>>> >>>>>>> On Monday, March 17, 2014 at 10:21 PM, Jan Miksovsky wrote: >>>>>>> >>>>>>> Eric: Thanks. I could have sworn the native form *didn't* work for >>>>>>> me in Canary when I posted this, but it works now. So I was either >>>>>>> hallucinating, or the problem was fixed quickly. Either way, glad to >>>>>>> know I >>>>>>> can /content/ as expected. >>>>>>> >>>>>>> On Sunday, March 16, 2014 2:40:25 PM UTC-7, Eric Bidelman wrote: >>>>>>> >>>>>>> That works for me in the latest Canary (35.0.1895.0). For polyfill >>>>>>> support, you still need to add the equivalent polyfill-next-selector {} >>>>>>> rule. This should work in Canary (with flags) and stable: >>>>>>> >>>>>>> http://jsbin.com/gacogeda/3/edit >>>>>>> >>>>>>> On Fri, Mar 14, 2014 at 6:43 PM, Jan Miksovsky <[email protected]>wrote: >>>>>>> >>>>>>> Ah, thanks. I'd seen discussion of /shadow/ and /shadow-deep/, but >>>>>>> not /content/. >>>>>>> >>>>>>> Should /content/ work right now? The updated jsbin at >>>>>>> http://jsbin.com/gacogeda/2/edit still doesn't seem to work. Or are >>>>>>> we in some place where ::content no longer works, but /content/ doesn't >>>>>>> work yet? >>>>>>> >>>>>>> On Friday, March 14, 2014 5:41:47 PM UTC-7, Steve Orvell wrote: >>>>>>> >>>>>>> Yes, it was changed to match the spec here: http://dev.w3.org/csswg/ >>>>>>> shadow-styling/. >>>>>>> >>>>>>> The ::content pseudo-element was removed. The /content/ combinator >>>>>>> was added. So your rule could be: >>>>>>> >>>>>>> content /content/ * { color: red; } >>>>>>> >>>>>>> Note, a combinator must have some selector to the left of it. >>>>>>> >>>>>>> In addition the ^ and ^^ combinators were renamed to /shadow/ and >>>>>>> /shadow-deep/. >>>>>>> >>>>>>> Hope that helps. >>>>>>> >>>>>>> On Fri, Mar 14, 2014 at 5:08 PM, Jan Miksovsky <[email protected]>wrote: >>>>>>> >>>>>>> I just upgraded Canary to 35.0.1892.2, and CSS rules with ::content >>>>>>> CSS selectors no longer seem to be applied as expected. I'm wondering >>>>>>> if >>>>>>> the ::content syntax changed recently. >>>>>>> >>>>>>> As far as I know, the syntax for ::content looks like: >>>>>>> >>>>>>> ::content * { >>>>>>> color: red; >>>>>>> } >>>>>>> >>>>>>> This is what's shown in the Guide to Styling article on the Polymer >>>>>>> site, for example. >>>>>>> >>>>>>> Repro: http://jsbin.com/gacogeda/1/edit. This jsbin works in an >>>>>>> older Canary (35.0.1887.0), but not in the latest Canary. >>>>>>> >>>>>>> I also happened to notice a recent Polymer checkin that used a >>>>>>> different content syntax like: >>>>>>> >>>>>>> ::content(*) { >>>>>>> } >>>>>>> >>>>>>> But I haven't seen a breaking change announcement anywhere — did I >>>>>>> miss it? >>>>>>> >>>>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Polymer" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/polymer-dev/ad7d90f6-16de- >>>>>>> 43b2-9ce1-20d019f6ff36%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/ad7d90f6-16de-43b2-9ce1-20d019f6ff36%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>>> >>>>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Polymer" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/polymer-dev/42675d85-a29e- >>>>>>> 45b2-bfa7-ecded1ca6b98%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/42675d85-a29e-45b2-bfa7-ecded1ca6b98%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>>> >>>>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Polymer" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/polymer-dev/208ac81a-4d90- >>>>>>> 4d37-a032-490ae0416540%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/208ac81a-4d90-4d37-a032-490ae0416540%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>>> >>>>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Polymer" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/polymer-dev/D1C7319E23C94F >>>>>>> 2588AB61D134DA23D5%40google.com<https://groups.google.com/d/msgid/polymer-dev/D1C7319E23C94F2588AB61D134DA23D5%40google.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Polymer" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/polymer-dev/9b750e05-4e4c-4c1e-872b-78112e56f740% >>>>> 40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/9b750e05-4e4c-4c1e-872b-78112e56f740%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Polymer" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/polymer-dev/d5da6634-1965-432e-8d76-f9d4d764a3b2%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/d5da6634-1965-432e-8d76-f9d4d764a3b2%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/a3ff013c-18ec-434d-bf82-096f19a8b5fe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
