Intent to Ship: Add support for CSS properties "overflow: clip" and "overflow-clip-margin"

[Scott Violet]

Contact emails

s...@google.com

Explainer

https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip

Specification

https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip

Design docs

https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip

Summary

Adds two CSS features. The 'clip' value results in a box’s content being clipped to the box's overflow clip edge. In addition, no scrolling interface is provided, and the content can not be scrolled by the user or programmatically. The overflow-clip-margin property enables specifying how far outside the bounds an element is allowed to paint before being clipped.

Blink component

Blink>Layout

TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

I'm not aware of any risks other than not being fully approved by W3C.

Gecko: Shipped/Shipping (https://groups.google.com/g/mozilla.dev.platform/c/7oQm8PC0aU0) I marked this shipping, but Firefox is in the intent-to-ship phase.

WebKit: No signal

Web developers: No signals

Ergonomics

Not aware of any.

Activation

Not aware of any.

Security

Not aware of any.

Debuggability

Only support needed is to surface the new value and property.

Is this feature fully tested by web-platform-tests?

No

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1087667

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5638444178997248

This intent message was generated by Chrome Platform Status.

[Manuel Rego Casasnovas]

On 01/12/2020 17:35, 'Scott Violet' via blink-dev wrote:
> Explainer
>
>
> https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip
> <https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip>

This is not an explainer, an explainer should include a summary of the
feature and use cases that it covers.

> Summary
>
> Adds two CSS features. The 'clip' value results in a box’s content being
> clipped to the box's overflow clip edge. In addition, no scrolling
> interface is provided, and the content can not be scrolled by the user
> or programmatically. The overflow-clip-margin property enables
> specifying how far outside the bounds an element is allowed to paint
> before being clipped.

These look like 2 different but related features. What's the maturity
status in the spec regarding them? I see a few issues open on the CSSWG
about both of them, are them important? Should we try to clarify them
and agree on a common behavior before shipping?

> Interoperability and Compatibility
>
> I'm not aware of any risks other than not being fully approved by W3C.

One interop risk would be if other browsers don't support this. How that
would affect pages using these properties?

> Gecko: Shipped/Shipping
> (https://groups.google.com/g/mozilla.dev.platform/c/7oQm8PC0aU0
> <https://groups.google.com/g/mozilla.dev.platform/c/7oQm8PC0aU0>) I

> marked this shipping, but Firefox is in the intent-to-ship phase.

Gecko shipped "overflow: clip" in version 81:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/81#CSS

But they haven't implemented "overflow-clip-margin" yet:
https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip

> WebKit: No signal

Have we asked for WebKit signals https://bit.ly/blink-signals ?

I know there has been some work regarding overflow in WebKit recently,
so it'd be nice to check what they think about these features.

> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>
> No

Why not?

Note that "overflow-clip-margin" interacts with css-contain, so that
kind of things should be tested too.

Bye,
Rego

[Scott Violet]

Thanks for pointing out my lack of details. I'll send around an update shortly.

  -Scott

[Scott Violet]

Here's an updated version:

Contact emails

s...@google.com

Explainer

None

Specification

https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip

Design docs

https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip

https://drafts.csswg.org/css-overflow-3/#propdef-overflow-clip-margin

Summary

Adds two CSS features. The 'clip' value results in a box’s content being clipped to the box's overflow clip edge. In addition, no scrolling interface is provided, and the content can not be scrolled by the user or programmatically. The overflow-clip-margin property enables specifying how far outside the bounds an element is allowed to paint before being clipped.

Blink component

Blink>Layout

TAG review

https://github.com/w3ctag/design-reviews/issues/579

TAG review status

Pending

Risks

Interoperability and Compatibility

I'm not aware of any risks other than not being fully approved by W3C.

Gecko: Shipped/Shipping (https://groups.google.com/g/mozilla.dev.platform/c/7oQm8PC0aU0) Firefox supports overflow: clip as of 81. overflow-clip-margin is not yet supported. Request for status here: https://github.com/mozilla/standards-positions/issues/462

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2020-December/031635.html)

Web developers: No signals

Ergonomics

Not aware of any.

Activation

Not aware of any.

Security

Not aware of any.

Debuggability

Only support needed is to surface the new value and property.

Is this feature fully tested by web-platform-tests?

Yes

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1087667

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5638444178997248

[Scott Violet]

Hi Rego,

Thanks for taking the time to respond, and sorry for the rough first attempt. It's my first time through this process.

On Tue, Dec 1, 2020 at 10:10 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 01/12/2020 17:35, 'Scott Violet' via blink-dev wrote:
>         Explainer
>
>
> https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip
> <https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip>

This is not an explainer, an explainer should include a summary of the
feature and use cases that it covers.

>         Summary
>
> Adds two CSS features. The 'clip' value results in a box’s content being
> clipped to the box's overflow clip edge. In addition, no scrolling
> interface is provided, and the content can not be scrolled by the user
> or programmatically. The overflow-clip-margin property enables
> specifying how far outside the bounds an element is allowed to paint
> before being clipped.

These look like 2 different but related features. What's the maturity
status in the spec regarding them? I see a few issues open on the CSSWG
about both of them, are them important? Should we try to clarify them
and agree on a common behavior before shipping?

I wasn't aware of that. Can you point me at the open issues you are referring to?

 

>         Interoperability and Compatibility
>
> I'm not aware of any risks other than not being fully approved by W3C.

One interop risk would be if other browsers don't support this. How that
would affect pages using these properties?

Good point. I've updated the chrome status to say: "Developers have to take care that overflow: clip is supported only by Mozilla, and overflow-clip-margin is not yet supported by any other browser. Beyond that, the only other risk is this not being fully approved by W3C."

 

> Gecko: Shipped/Shipping
> (https://groups.google.com/g/mozilla.dev.platform/c/7oQm8PC0aU0
> <https://groups.google.com/g/mozilla.dev.platform/c/7oQm8PC0aU0>) I
> marked this shipping, but Firefox is in the intent-to-ship phase.

Gecko shipped "overflow: clip" in version 81:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/81#CSS

But they haven't implemented "overflow-clip-margin" yet:
https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip

I have reached out to Mozilla ( https://github.com/mozilla/standards-positions/issues/462 ). But no response yet.

 

> WebKit: No signal

Have we asked for WebKit signals https://bit.ly/blink-signals ?

I know there has been some work regarding overflow in WebKit recently,
so it'd be nice to check what they think about these features.

They are supportive: https://lists.webkit.org/pipermail/webkit-dev/2020-December/031635.html .

 

>         Is this feature fully tested by web-platform-tests
>         <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>
> No

Why not?

Note that "overflow-clip-margin" interacts with css-contain, so that
kind of things should be tested too.

Sorry about that. I forgot to update this part. I added pointers to the WPT files.

Please let me know if you have any other concerns.

Thanks for your feedback,

  -Scott

 

Bye,
   Rego

[Manuel Rego Casasnovas]

Thanks for the updates.

On 10/12/2020 15:51, 'Scott Violet' via blink-dev wrote:
> >         Summary
> >
> > Adds two CSS features. The 'clip' value results in a box’s
> content being
> > clipped to the box's overflow clip edge. In addition, no scrolling
> > interface is provided, and the content can not be scrolled by the
> user
> > or programmatically. The overflow-clip-margin property enables
> > specifying how far outside the bounds an element is allowed to paint
> > before being clipped.
>
> These look like 2 different but related features. What's the maturity
> status in the spec regarding them? I see a few issues open on the CSSWG
> about both of them, are them important? Should we try to clarify them
> and agree on a common behavior before shipping?
>
>
> I wasn't aware of that. Can you point me at the open issues you are
> referring to?

There are a few issues on the CSSWG github repo:
* https://github.com/w3c/csswg-drafts/issues/5130
* https://github.com/w3c/csswg-drafts/issues/5271
* https://github.com/w3c/csswg-drafts/issues/5404
* https://github.com/w3c/csswg-drafts/issues/5572
* https://github.com/w3c/csswg-drafts/issues/5601

I haven't checked them properly, maybe they're not important, I was just
curious about the status of things.

Anyway I'm glad Firefox already has an implementation of "overflow:
clip" and WebKit is supportive. Those are very strong signals.

Bye,
Rego

[Jan Gora]

> This value indicates that the box’s content is clipped to its overflow clip edge and that no scrolling user interface should be provided by the UA to view the content outside the clipping region. In addition, unlike overflow: hidden which still allows programmatic scrolling, overflow: clip forbids scrolling entirely, through any mechanism, and therefore the box is not a scroll container.

I guess this is not the case, but wanted to confirm that the `clip` attribute doesn't affect the contents of the iframe? That would be bad if it was possible to hide a scroll bar inside an iframe, or use it as a detection mechanism of such scrollbar. 

[Scott Violet]

Here's an explainer for this:

Prior to this work, it was not possible to have an element hide overflow and prevent scrolling of any kind (programmatic or user). The ‘clip’ value of ‘overflow’ adds this functionality. That is, the content is clipped to the element's padding box and scrolling of any kind is not allowed. The element is not a scroll container, and does not start a new formatting context. If you wish to start a new formatting context, you can use display: flow-root to do so.

For some uses, it is desirable to modify the clipping edge. For example, the shadow of a child element should still be visible. The ‘overflow-clip-margin’ property determines precisely how far outside the element's bounds the element is allowed to paint before being clipped. ‘Overflow-clip-margin’ may be used with ‘overflow: clip’ as well as ‘contain: paint.’

The following illustrates using ‘overflow-clip-margin’ with ‘contain: paint.’ For browsers that support overflow-clip-margin the box-shadow will be visible.

#container {
  width: 100px;
  height: 100px;
  contain: paint;
  overflow-clip-margin: 10px;
}
#child {
  width: 100px;
  height: 100px;
  box-shadow: 8px 8px blue;
  border: 1px solid;
}
</style>
<div id="container">
  <div id="child"></div>
</div>

  -Scott

[Chris Harrelson]

All of the spec issues for this intent are now resolved, and the corresponding code changes committed. I think it's ready for API owner re-review. 

(I am recused because I helped out with this feature.)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKARY_niBvimC0SsmhF_Q2ROnx%3D6R%2BJ_ZPKcXGWxvtHPqu5u5g%40mail.gmail.com.

[Yoav Weiss]

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9u1H_52F3FUgP2W%3DRb9Bjf5fqownwzRa1jhGs3on8KQA%40mail.gmail.com.

[Manuel Rego Casasnovas]

A few comments here.

I couldn't find tests for the "<visual-box>" part of the
overflow-clip-margin syntax:
https://drafts.csswg.org/css-overflow/#overflow-clip-margin
Actually I'm not sure if the implementation supports that or not.
Could you clarify that?
I'd suggest also adding parsing tests for this property.

The runtime flag is still marked as "test" in
runtime_enabled_features.json5. I believe the usual thing is to have it
marked as "experimental" for a while before shipping it.
That means that we cannot check the status of tests interop in wpt.fyi
for example: https://wpt.fyi/results/css/css-overflow
Also some tests are passing in all browsers even without support for the
overflow-clip-margin property yet (also some are only passing on WebKit
I guess due to the overlay scrollbars).

It's a pity we missed the TAG review due to lack of explainer. Anyway
all browsers seems onboard for these features which is great.

Bye,
Rego

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKARY_niBvimC0SsmhF_Q2ROnx%3D6R%2BJ_ZPKcXGWxvtHPqu5u5g%40mail.gmail.com

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKARY_niBvimC0SsmhF_Q2ROnx%3D6R%2BJ_ZPKcXGWxvtHPqu5u5g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9u1H_52F3FUgP2W%3DRb9Bjf5fqownwzRa1jhGs3on8KQA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9u1H_52F3FUgP2W%3DRb9Bjf5fqownwzRa1jhGs3on8KQA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>

[Chris Harrelson]

On Wed, Feb 3, 2021 at 12:07 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:

A few comments here.

I couldn't find tests for the "<visual-box>" part of the
overflow-clip-margin syntax:
https://drafts.csswg.org/css-overflow/#overflow-clip-margin
Actually I'm not sure if the implementation supports that or not.
Could you clarify that?
I'd suggest also adding parsing tests for this property.

<visual-box> was added to the spec in the last week, and is not part of this intent. We'll add it later.

 

The runtime flag is still marked as "test" in
runtime_enabled_features.json5. I believe the usual thing is to have it
marked as "experimental" for a while before shipping it.
That means that we cannot check the status of tests interop in wpt.fyi
for example: https://wpt.fyi/results/css/css-overflow
Also some tests are passing in all browsers even without support for the
overflow-clip-margin property yet (also some are only passing on WebKit
I guess due to the overlay scrollbars).

There is not a best practice that requires this (in fact, I have advocated in the past for using experimental less because it prevents testing the not-enabled state that we actually ship to users)...isn't it enough just to ask that all the tests pass when shipping?

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/027de420-a9f3-2b60-68d7-fdf6496499c6%40igalia.com.

[Manuel Rego Casasnovas]

LGTM2.

On 03/02/2021 17:32, Chris Harrelson wrote:
> On Wed, Feb 3, 2021 at 12:07 AM Manuel Rego Casasnovas <re...@igalia.com
> <mailto:re...@igalia.com>> wrote:
>
> A few comments here.
>
> I couldn't find tests for the "<visual-box>" part of the
> overflow-clip-margin syntax:
> https://drafts.csswg.org/css-overflow/#overflow-clip-margin
> <https://drafts.csswg.org/css-overflow/#overflow-clip-margin>
> Actually I'm not sure if the implementation supports that or not.
> Could you clarify that?
> I'd suggest also adding parsing tests for this property.
>
>
> <visual-box> was added to the spec in the last week, and is not part of
> this intent. We'll add it later.

Ok, thanks for the info. Please update the chromestatus entry to reflect
that (also it mentions shipping in Firefox which is only true for
"overflow: clip" but not for overflow-clip-margin).

Anyway I believe adding a parsing test should be done as part of
shipping this. I'd even include the new syntax on the parsing test so
it'd be clear which things are shipping in Chromium.

> The runtime flag is still marked as "test" in
> runtime_enabled_features.json5. I believe the usual thing is to have it
> marked as "experimental" for a while before shipping it.
> That means that we cannot check the status of tests interop in wpt.fyi
> for example: https://wpt.fyi/results/css/css-overflow
> <https://wpt.fyi/results/css/css-overflow>
> Also some tests are passing in all browsers even without support for
> the
> overflow-clip-margin property yet (also some are only passing on WebKit
> I guess due to the overlay scrollbars).
>
>
> There is not a best practice that requires this (in fact, I have
> advocated in the past for using experimental less because it prevents
> testing the not-enabled state that we actually ship to users)...isn't it
> enough just to ask that all the tests pass when shipping?

Yeah I know there's nothing that requires this, it was just a comment
because I got somehow surprised that tests were not passing in wpt.fyi.
I believe that when we're sending an intent-to-ship, we should be ready
to switch to "experimental" and let web authors play with the features.
Maybe we should think about this and see if we can define some kind of
policy around this, but this would be unrelated to this intent.

Anyway coming back to the other point regarding tests, it'd be nice to
improve them so they don't pass in browsers that don't support the
feature at all.

Bye,
Rego

[Daniel Bratell]

LGTM3

/Daniel