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/9e36aabd-8aa9-4559-8ede-eeec1a7adfb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to