Skip to content

[css-scoping] [selectors] <compound-selector-list> should somehow affect :is() / :where() parsing #5093

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
emilio opened this issue May 20, 2020 · 6 comments
Closed

[css-scoping] [selectors] <compound-selector-list> should somehow affect :is() / :where() parsing #5093

emilio opened this issue May 20, 2020 · 6 comments
Labels
Closed Accepted by CSSWG Resolution css-scoping-1 Current Work selectors-4 Current Work

Comments

@emilio
Copy link
Collaborator

emilio commented May 20, 2020

https://drafts.csswg.org/css-scoping/#host-selector takes a <compound-selector-list> (that is, doesn't accept combinators). This is good, as otherwise it'd break the shadow tree encapsulation.

However strictly per the syntax technically something like :host(:is(div div)) should parse. I think this is a spec bug.
@emilio emilio added selectors-4 Current Work css-scoping-1 Current Work labels May 20, 2020
@emilio
Copy link
Collaborator Author

emilio commented May 20, 2020

Maybe :is() and :where() should be more subtly defined. I'd expect ::part(foo):is(:hover,:active) to parse, just like the individual selectors would, but I don't think ::part(foo):is([attr="value"]) should parse.

@emilio
Copy link
Collaborator Author

emilio commented May 20, 2020

This may also be an issue for pseudo-elements, so ::pseudo:is(:hover) may be fine, but ::pseudo:is(p) doesn't make sense.

@Loirooriol Loirooriol mentioned this issue Oct 4, 2020
Closed
@andruud
Copy link
Member

andruud commented Oct 5, 2020 •
edited
Loading

Also, should ::pseudo:is() be allowed? (I.e. empty :is() after pseudo elements).

I think probably yes (but matches nothing).

@Loirooriol
Copy link
Contributor

@andruud I think that's implied by #3264. ::pseudo:is(:hover, :bogus) should be treated as ::pseudo:is(:hover), ::pseudo:is(:bogus) should be treated as ::pseudo:is(), and ::pseudo:is() should match nothing.

webkit-commit-queue pushed a commit to WebKit/WebKit that referenced this issue Oct 29, 2021
@anttijk
Allow :is/:where after all pseudo elements
65e0162 
https://bugs.webkit.org/show_bug.cgi?id=232434

Reviewed by Dean Jackson.

LayoutTests/imported/w3c:

* web-platform-tests/css/css-scoping/slotted-parsing-expected.txt:

Source/WebCore:

Any subselectors that are not legal in the context will be removed by the forgiving parsing.
This matches the behavior in other engines and the discussion in w3c/csswg-drafts#5093.

The validity check is moved from the compound selector level to the simple selector level. This way if we are
inside forgiving selector list parsing, it can recover and continue.

* css/parser/CSSSelectorParser.cpp:
(WebCore::isLogicalCombinationPseudoClass):
(WebCore::isPseudoClassValidAfterPseudoElement):
(WebCore::isSimpleSelectorValidAfterPseudoElement):

:is(), :where(), and so on are always legal but their content is necessarily not.

(WebCore::CSSSelectorParser::consumeCompoundSelector):

Set the preceding pseudo-element as parser state.

(WebCore::CSSSelectorParser::consumeSimpleSelector):

Check if the pseudo-class or pseudo-element is valid immediately after consuming it.

(WebCore::CSSSelectorParser::consumePseudo):

Disallow nesting in all cases.

(WebCore::CSSSelectorParser::DisallowPseudoElementsScope::DisallowPseudoElementsScope): Deleted.
(WebCore::CSSSelectorParser::DisallowPseudoElementsScope::~DisallowPseudoElementsScope): Deleted.

Just use SetForScope.

* css/parser/CSSSelectorParser.h:



Canonical link: https://commits.webkit.org/243697@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@285054 268f45cc-cd09-0410-ab3c-d52691b4dbfc
philn pushed a commit to philn/old-webkit that referenced this issue Nov 3, 2021
Allow :is/:where after all pseudo elements
2da0ef8 
https://bugs.webkit.org/show_bug.cgi?id=232434

Reviewed by Dean Jackson.

LayoutTests/imported/w3c:

* web-platform-tests/css/css-scoping/slotted-parsing-expected.txt:

Source/WebCore:

Any subselectors that are not legal in the context will be removed by the forgiving parsing.
This matches the behavior in other engines and the discussion in w3c/csswg-drafts#5093.

The validity check is moved from the compound selector level to the simple selector level. This way if we are
inside forgiving selector list parsing, it can recover and continue.

* css/parser/CSSSelectorParser.cpp:
(WebCore::isLogicalCombinationPseudoClass):
(WebCore::isPseudoClassValidAfterPseudoElement):
(WebCore::isSimpleSelectorValidAfterPseudoElement):

:is(), :where(), and so on are always legal but their content is necessarily not.

(WebCore::CSSSelectorParser::consumeCompoundSelector):

Set the preceding pseudo-element as parser state.

(WebCore::CSSSelectorParser::consumeSimpleSelector):

Check if the pseudo-class or pseudo-element is valid immediately after consuming it.

(WebCore::CSSSelectorParser::consumePseudo):

Disallow nesting in all cases.

(WebCore::CSSSelectorParser::DisallowPseudoElementsScope::DisallowPseudoElementsScope): Deleted.
(WebCore::CSSSelectorParser::DisallowPseudoElementsScope::~DisallowPseudoElementsScope): Deleted.

Just use SetForScope.

* css/parser/CSSSelectorParser.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@285054 268f45cc-cd09-0410-ab3c-d52691b4dbfc
@tabatkins
Copy link
Member

@fantasai checked in an edit to fix this:

The [=logical combination pseudo-classes=]
are allowed anywhere that any other [=pseudo-classes=] are allowed,
but pass any restrictions to their arguments.
(For example, if only [=compound selectors=] are allowed,
then only [=compound selectors=] are valid within an '':is()''.)

Just need CSSWG thumbs-up for the edit.

This was referenced Dec 9, 2022
Closed
Closed
Closed
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-scoping] [selectors] <compound-selector-list> should somehow affect :is() / :where() parsing, and agreed to the following:

  • RESOLVED: Accept the edit
The full IRC log of that discussion <dael> TabAtkins: Summary is after some discussion across a few related issues, basic idea is logical combo pseudos that combine things together passes down any restrictions the outer pseudo is in
<fantasai> :is(), :where(), and :not() are the set in question
<dael> TabAtkins: You can use is in a compund context, but it has to be compound too. That way you can't smuggle in a more complicated selector
<dael> TabAtkins: Have spec text. Need approval
<TabAtkins> also :nth-child() i think
<dael> astearns: Text is in last comment. seems good to me
<dael> astearns: Other opinions?
<dael> astearns: Prop: Accept this restriction and the edit that defines it
<dael> fantasai: Kind of more of an expansion. Previously only allowed some things and adds :is and :where
<dael> TabAtkins: Lot of places where they were allowed but could contain whatever. But doesn't matter
<dael> astearns: Prop: Accept the edit
<dael> astearns: Obj?
<dael> RESOLVED: Accept the edit

@mozilla-apprentice mozilla-apprentice mentioned this issue Jan 5, 2023
Open
@fantasai fantasai closed this as completed Jan 7, 2023
roytam1 pushed a commit to roytam1/UXP that referenced this issue Feb 23, 2023
@fofajardo @roytam1
Issue #2078 - Follow-up: Propagate combinator restriction to :is()/:w…
439c671 
…here()

Based on spec discussion: w3c/csswg-drafts#5093
fofajardo added a commit to FranklinDM/UXP that referenced this issue Feb 27, 2023
@fofajardo
Issue #2078 - Follow-up: Propagate combinator restriction to :is()/:w…
826464c 
…here()

Based on spec discussion: w3c/csswg-drafts#5093
@byung-woo byung-woo mentioned this issue Aug 19, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution css-scoping-1 Current Work selectors-4 Current Work
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@andruud @tabatkins @fantasai @emilio @Loirooriol @css-meeting-bot