Did the ::content syntax change?

[Jan Miksovsky]

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?

[Steve Orvell]

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.

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 polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/ad7d90f6-16de-43b2-9ce1-20d019f6ff36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jan Miksovsky]

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?

[Eric Bidelman]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/42675d85-a29e-45b2-bfa7-ecded1ca6b98%40googlegroups.com.

[Jan Miksovsky]

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.

[Hoa V. Dinh]

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/spark_split_view

Thanks!

-- 

Hoa V. Dinh

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/208ac81a-4d90-4d37-a032-490ae0416540%40googlegroups.com.

[Rob Dodson]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/D1C7319E23C94F2588AB61D134DA23D5%40google.com.

[Sergey Shevchenko]

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.

[Rob Dodson]

Hm that sounds like a bug. Pinging @sorvell

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/9b750e05-4e4c-4c1e-872b-78112e56f740%40googlegroups.com.

[Eric Bidelman]

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.

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 :)

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/9b750e05-4e4c-4c1e-872b-78112e56f740%40googlegroups.com.

[Sergey Shevchenko]

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! :) 

[Eric Bidelman]

That may be because polymer's shimming supported both in a small deprecation window?

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/d5da6634-1965-432e-8d76-f9d4d764a3b2%40googlegroups.com.

[Sergey Shevchenko]

Possible...

[Rob Dodson]

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

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.

[Rob Dodson]

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.

[Jan Miksovsky]

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.

[Jan Miksovsky]

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.

[Rob Dodson]

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.