Re: [csswg-drafts] [css-overflow] Is the box a scroll container if only one of 'overflow-x' or 'overflow-y' is 'clip'?

Sorry for missing the meeting. There are a few things that are missing in this resolution.

The resolution above isn't clear about this, but various comments during the discussion, as well as https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-376947739 suggest that places that require something to be (non) visible, should be changed to require something to be (non) visible or clip. I think it depends on which case we're talking about:

1. The motivating use case for adding `overflow:clip` (recently, not the one for the original CSS2 design) was to be able to do `contain: strict; text-overflow: ellipsis;` or `contain: strict; resize: both;` and have it work. Both of these properties require overflow to be non-visible. This could be achieved by using `overflow:hidden`, but this has the unintended side effect of introducing (programmatic) scrollability, which may cause browsers to consume more resources than necessary (e.g. prerendering the overflowing areas, to be able to display them without delay should scroll happen).

    → I would be very unhappy if `text-overflow` and `resize` did not work with `overflow:clip`

2. The propagation of `overflow` to the viewport says that once you've set the value of the viewport (based on the value on `:root` or `body`), if it is visible, it gets changed to auto. I don't think that this should be changed to visible or clip get changed to auto, as this effectively means that overflow:clip on the root/body does nothing. If we do allow `clip` to stay `clip` on the viewport, should there still be scrollbars to "see" the invisible projected geometry? Hopefully not, but that looks like special casing.

Also, Along the way, we had discussed how the vast majority of `overflow:hidden` uses did not actually want programatic scrollability, and that teaching people to use `overflow:clip` instead would be nice, since it would have a (small but) positive effect on resource consumption (for the same reason as in 1.). The current resolution would require people to do `overflow: clip; display: flow-root` instead, which is a lot less easy to teach. Also, combining this with 1., even when used without `contain`, I would be unhappy if `text-overflow` and `resize` did not work with `overflow:clip`.

So, all in all, I am a bit skeptical of the above resolution: are people willing to implement `overflow:clip` as a paint time effect and at the same time allow `text-overflow` and `resize` to apply, and to implement the root element / viewport special casing (at least clip instead of compute to auto, preferably don't have scrollbars)?

If yes, I'm not super convinced by the resolution, but I suppose I can live with it.
If no, I'd like to see arguments why not, but I would probably object to the resolution.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-377078084 using your GitHub account

Received on Thursday, 29 March 2018 00:14:44 UTC