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

An extra keyword to disable inheritance? #9531

Open
simevidas opened this issue Oct 27, 2023 · 9 comments
Open

An extra keyword to disable inheritance? #9531

simevidas opened this issue Oct 27, 2023 · 9 comments

Comments

@simevidas
Copy link
Contributor

The blog https://nerdy.dev/ has a transparent retractable sticky nav bar with a few buttons and links on the side. Since the bar is transparent, the website uses the following styles to allow the mouse cursor to go through the “empty” parts of the bar:

.Nav {
  pointer-events: none;
}

.Nav > * {
  pointer-events: auto;
}

This works, but I think the code would be more readable and robust if we didn’t have to set and unset none in two steps. Imagine if there existed an optional keyword that disabled inheritance for a declaration.

.Nav {
  pointer-events: none no-inherit;
}

Does something like this exist?

@argyleink
Copy link
Contributor

what if pointer-events: painted; worked on DOM!?

@Loirooriol
Copy link
Contributor

This clashes with existing syntax, e.g list-style: none no-inherit is currently valid, it expands to

list-style-position: outside;
list-style-image: none;
list-style-type: no-inherit;

I'm also not convinced that your proposal is more readable and robust.

@simevidas
Copy link
Contributor Author

simevidas commented Oct 27, 2023

It’s more readable in the sense that it contains the whole information in one declaration, that information being “set pointer-events to none only on the .Nav element itself”. A developer inspecting a web page in the browser currently cannot get this information by inspecting the .Nav element alone. They see the pointer-events: none, but they don’t know if the intention was to set it only on that element or the entire DOM sub-tree. They have to check one of the child elements to confirm that. That takes extra time. It can also be missed and cause confusion and bugs. It would be better if the whole information was contained within one declaration. That’s what I meant by more readable.

@Loirooriol
Copy link
Contributor

Loirooriol commented Oct 27, 2023

It's also not clear what kinds of inheritance this would avoid, e.g.

<style>
div { color: cyan no-inherit }
</style>
<div>
  <p>foo</p>
  bar
</div>

Presumably the intention would be for color: cyan to only affect "bar" but not "foo"?

However, "bar" has a style of its own, that inherits from its parent element. There is also an anonymous block. So I guess no-inherit should still allow text nodes and anonymous boxes to inherit?

And what about pseudo-elements? Presumably you want ::first-line to still inherit the color. What about ::before and ::after? Etc.

Just unsetting with an universal selector and desired pseudo-elements seems more straightforward and clear to me.

@simevidas
Copy link
Contributor Author

As far as I know, there exist only one kind of inheritance in CSS.

https://drafts.csswg.org/css-cascade/#inheriting

color: cyan no-inherit would behave as if the color property was not an inherited property.

@Loirooriol
Copy link
Contributor

This would imply that "bar" wouldn't be cyan in the example above. Is that your intention?

@simevidas
Copy link
Contributor Author

simevidas commented Oct 27, 2023

If that’s how inheritance works, then yes, “bar” would not be cyan. If no-inherit did not match exactly how inheritance works in CSS, that would be confusing because then developers would need to learn and remember in what ways no-inherit is different from actual inheritance. That would not be good.

Btw, no-inherit is just a placeholder name. It could be a different syntax like !important.

@Loirooriol
Copy link
Contributor

Then this would be useless in most cases.

@SebastianZ
Copy link
Contributor

From an author's point of view, the behavior of such a switch should be the same as not inherited properties work. Otherwise it would cause a lot of confusion.

Sebastian

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

4 participants