Hey Jan, I agree and I feel your pain because I have the same refactoring task ahead of me. The spec was drafted yesterday late afternoon after a couple days (and nights) of serious discussion. We realized we were making a mistake and we didn't want to ship something that would suddenly be frozen and trip others up for years to come.
In the future, if I see rumblings of some kind of dramatic change, I might play the part of canary and squawk a bit on the list. I don't want to raise a bunch of false alarms, but we're all part of a big team here and everyone deserves to be as "in the know" as possible. On Friday, March 21, 2014 11:04:49 AM UTC-7, Jan Miksovsky wrote: > > 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/e175b973-3f2e-4902-bfed-2aec28104a2b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
