Skip to content
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.

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

[css-transitions-2] Should @starting-style add a teensy bit of specifity? #11263

Open
tabatkins opened this issue Nov 22, 2024 · 2 comments
Open

Comments

@tabatkins
Copy link
Member

See https://youtu.be/DNXEORSk4GU?si=FaHmoCzBpQPF9eeS&t=1161 for context. In this video, the dev explains that they used to put @starting-style at the top of their rule, which felt more natural, but now that we've changed how Nesting works, that no longer works - the plain declarations are no longer shifted above the nested rules, so the @starting-style styles lose due to order-of-appearance. Instead, you have to put @starting-style below your other declarations.

This feels like a frustrating footgun. Would it make sense to have @starting-style introduce a new, lowest bit of specificity, so it'll win over plain declarations in the same parent rule regardless of the order it appears in?

@benface
Copy link

benface commented Nov 23, 2024

I'd rather not. It would be confusing. Why would @starting-style affect the specificity but other at-rules like @media wouldn't?

@bramus
Copy link
Contributor

bramus commented Nov 29, 2024

I’m with @benface here. It would feel inconstent when compared to other at-rules.

I believe that the authors who are struggling with this right now are the ones that have used it before – which not that many have.

If they hadn’t seen/learned the old behavior, I think the current behavior caused by CSSNestedDeclarations is what they would have expected to happen in the first place (which is also something Kevin mentions in his video: it’s regular cascade now).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants