search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.51k stars 671 forks source link

[css-conditional-5] scroll-state(overflowing) is confusing because it ignores clipped overflowing content #11182

Closed fantasai closed 1 day ago

fantasai commented 1 week ago

The overflowing scroll state query, whose values are none | top | right | bottom | left | block-start | inline-start | block-end | inline-end, is described as

The overflowing container feature queries whether a scroll container has clipped scrollable overflow rectangle content in the given direction which is reachable through user initiated scrolling. That is, overflowing does not match for a hidden container, nor for a negative scrollable overflow region.

But colloquially, content that overflows and is clipped is still considered overflowing.

If the question is, "can I scroll in this direction", perhaps a better name would be scrollable?

lilles commented 1 week ago

If the question is, "can I scroll in this direction", perhaps a better name would be scrollable?

Yes, I agree that scrollable would be a better name.

yisibl commented 1 week ago

"can I scroll in this direction"

This is indeed easier to understand and fits the perception of CSS authors.

To accommodate more common scenarios, I've also come up with a new syntax: scroll-state(scroll-to)

Add scroll-state(scroll-to) container feature queries

css-meeting-bot commented 2 days ago

The CSS Working Group just discussed [css-conditional-5] scroll-state(overflowing) is confusing because it ignores clipped overflowing content, and agreed to the following:

The full IRC log of that discussion <TabAtkins> futhark: there's scroll-state(overflowing) which is true if there is content overflowing in that axis
<TabAtkins> futhark: elika points out that there may be overflowing content that can't be scrolled to. she recommends renaming the value to 'scrollable'
<miriam> +1 scrollable
<argyle> +1 scrollable
<TabAtkins> futhark: I agree. Suggest we use this name unless people have other suggestions.
<TabAtkins> +1
<TabAtkins> fantasai: think this is a good summary
<kbabbitt> +1 scrollable
<fantasai> s/content overflowing/content overflowing and scrollable to/
<smfr> q+
<kizu> q+
<TabAtkins> astearns: proposed resolution is to rename 'overflowing' to 'scrollable'
<astearns> ack smfr
<TabAtkins> smfr: is this only user-scrollable overflow? or also overflow:hidden?
<kizu> q- same question
<dbaron> s/hidden/hidden, which can be programmatically scrolled/
<TabAtkins> futhark: overflowing content that can be scrolled to *with the UI*
<astearns> ack kizu
<TabAtkins> kizu: yeah same, in a lot of aspects 'hidden' behaves as other scrollable values like 'auto' or 'scroll'
<emilio> I think it should apply to hidden fwiw
<astearns> ack fantasai
<TabAtkins> kizu: i think there are situations authors might want to know if there is clipped content that could be script-scrolled to
<emilio> (but not clip=
<TabAtkins> fantasai: maybe a separate issue, i think i agree it should apply to hidden as well
<TabAtkins> fantasai: the author knows if it's hidden or not, that's not an interesting part of the query
<TabAtkins> fantasai: but i think that should be another issue
<TabAtkins> +1 to fantasai
<TabAtkins> astearns: are you okay punting to a separate issue?
<TabAtkins> kizu: yup
<TabAtkins> astearns: so proposed resolution, rename "overflowing" to "scrollable". objections?
<fantasai> s/that's not an interesting part of the query/this becomes an uninteresting query for hidden elements if it doesn't work on hidden
<emilio> +1 on the rename
<TabAtkins> RESOLVED: Rename "overflowing" to "scrollable"
<emilio> +1 to make it work on hidden too :)
<TabAtkins> astearns: I'll get the other two async resolutions going today.
<emilio> There's no point on allowing auto with scrollbar-width: none but not hidden for example