Less throws an error with the ">>>" combinator

[tigerhawkvok]

Eg,

ParseError: Unrecognised input in path\to\less\main.less on line 25, column 7:
24
25 html >>> .materialblue {
26

However, this is valid.

See:

• https://developer.mozilla.org/en-US/docs/Web/Web_Components/Shadow_DOM
• https://code.google.com/p/chromium/issues/detail?id=446051
• https://w3c.github.io/webcomponents/spec/shadow/#composed-trees
• http://dev.w3.org/csswg/css-scoping/#deep-combinator

This should be correctly passed through.

[seven-phases-max]

Well, they change the draft every week (see #1801, #2023). So it's not surprise.
Either way you can always use escaping:

@whatever: ~">>>"; // or any other magic garbage
a @{whatever} b {
    color: red;
}

[mgolois]

any update on this issue other than the answer above?

[seven-phases-max]

I don't think so. Or will you submit a PR (adding the new combinator syntax and removing an old one) every time they change the draft?

[tigerhawkvok]

Well, this has been stable for over a year, so honestly saying "every time they change the draft' is a bit misleading

[seven-phases-max]

@tigerhawkvok A year is just a twink in the CSS realm. I usually like to recall of CSS vars that were hanging there for decades and yet changed the syntax at Draft->CR transition almost at the last moment...
Either way, I don't see how this "over a year" changes anything - if none is willing to implement and then maintain any draft staff, it's not going to appear itself. And after #1801, #2023 boogie-woogie (leaving some garbage in the code-base) it's no wonder these things are treated sceptically.

[aminpaks]

Can we have >>> selector soon?

[Jack-Works]

Maybe less should consider about support >>> now?

vuejs/vue-loader#913

[matthew-dean]

I'm with @seven-phases-max. There's still some debate on if shadow-piercing combinators are going to ever make it, since there are some that debate the philosophy of it (preferring locally-scoped styles). It's not tracked on caniuse.com, it doesn't have browser support, so that's why it's not supported (natively) in Less. But, as pointed out, it can be hacked in. I recommend closing this issue and re-opening only if this reaches CR status.

[IEvangelist]

I'm working on an angular app and believe we should start switching over to using >>> instead of /deep/.

Why not support >>>. It is valid .css, so why not? Perhaps I'm being naive but in looking at the /deep/ notation I found this SO issue that led me to believe that we should be using >>> instead, however less doesn't support it. What am I missing?

[aminpaks]

@IEvangelist Regarding Angular stuff according to this post apparently you don't need >>> if you use ::ng-deep instead. And bottom line is >>> or /deep/ will be deprecated from css as far as I understood.

[Jack-Works]

::ng-deep is not working for me, because I'm dealing with a vue app, not an angular app.

…

On Wed, 30 Aug 2017, 05:37 Amin Pakseresht ***@***.***> wrote: According to this post <https://angular.io/guide/component-styles#deprecated-deep--and-ng-deep> apparently you don't need >>> if you use ::ng-deep instead. And bottom line is >>> or /deep/ will be deprecated from css as well as far as I understood. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2623 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFJBf4ZyVbcJ0spORtCXTC9aSEXCOqvkks5sdISggaJpZM4FOiQI> .

[aminpaks]

@Jack-Works it's already explained for now you can use escape string as:

@deep: ~'>>>';
// use @deep value in your selectors
.base-class @{deep} .deep-selector-class { }

[seven-phases-max]

Closing until they make a final decision (according to latest rumors >>> is going to be kicked out too).
The universal workaround (see the escaping trick above) is given and it fits any experimental/draft combinator/selector syntax just fine.

TODO: Open a generic issue to make combinator parsing more "relaxed" to accomodate some anticipated syntax (e.g. https://drafts.csswg.org/selectors-4/#descendant-combinators etc., possibly including even not existing things like >>>>> and /*&^$*^&$/ with a low level warnings or so).

[matthew-dean]

@seven-phases-max I agree it would be forward-thinking to think of a a regex that would just capture any experimental combinators. I'm not sure there's a lot of reason for Less to be terribly discriminating with selectors. But it's true that browsers are intent now on removing shadow-piercing of any kind as an unwanted complexity.