Aaaaaaagh. I just spent a couple of hours yesterday upgrading a pile of elements to the new syntax. And, because I ended up making a variety of other edits while I was in there, I can't just roll back. Now I can block out an hour or so next week to put the old syntax back.
I'm actually fine with the decision (I'd been disappointed by the inability to combine /content/ with ">"), and you did recognize the fact that this is annoying and causes trouble for early adopters. But: Yes! Churn like this really does cause a lot of work. On Friday, March 21, 2014 10:53:57 AM UTC-7, Rob Dodson wrote: > > Another thing to add, native support for /content/ has been reverted in > blink and the old ::content syntax should be shipping in Canary any day now. > > On Friday, March 21, 2014 10:52:29 AM UTC-7, Rob Dodson wrote: >> >> 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]> 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]> >>>> 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]. >>>>> 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/c543fd34-1c9d-4d86-ba39-d379e6d08411%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
