[css-images-4][css-overflow-3] How do `object-overflow` and `object-view-box` interact with `overflow` and `overflow-clip-margin`?

[SebastianZ]

In #7058 the properties object-overflow and object-view-box where introduced, which define whether and how content of replaced elements overflows its content box.

On the other hand we have overflow, overflow-x, overflow-y and overflow-clip-margin, which apply to all elements (including replaced elements) and define how overflow on them is handled and whether they can paint outside their bounds.

As I understand it, object-view-box only defines the size of the canvas an image or object is painted in but doesn't have any effect on painting outside its content box.

Though object-overflow's effect seems to overlap with the effects of overflow: clip/overflow: visible and overflow-clip-margin.

So I am wondering how those properties actually play together and if the functionality of the new object-* properties might not be covered by the overflow-* properties.

Sebastian

[khushalsagar]

That's a very good catch, thanks for bringing this up.

The fundamental way I expected these properties to differ is the content that's clipped. overflow:clip applies to the element's descendants while object-overflow would be limited to the replaced content so any descendants would not be clipped. But it looks like replaced elements can not have descendants so this point is moot.

object-overflow applies before other overflow properties. So object-overflow: clip (the behaviour today) implies there is no overflow that needs to be clipped by overflow* properties. But object-overflow: visible implies that the content can have an infinite overflow in any direction. overflow* properties can then be used to customize the extent of the overflow or to change the reference box used for clipping (since object-overflow defaults to content-box).

I can see object-overflow being redundant now, it has the same effect as overflow. If we were to reuse overflow for the desired effect then the result would be :

• Replaced elements would default to overflow: clip (as opposed to overflow: visible) for other elements.
• The only values supported for replaced elements would be overflow: visible and overflow: clip.
• Currently overflow: clip on a replaced element ignores overflow-clip-margin but now that won't be the case.

@tabatkins @vmpstr, what do you think? Any scenario where object-overflow is required in addition to overflow?

[progers]

But it looks like replaced elements can not have descendants so this point is moot.

With the spec server issues, I wasn't able to figure out if this is true in general. Videos are an example of user agent shadow dom descendants of a replaced element. A simple testcase of an img with a pseudo element descendant does not render:

<style>
  img::after {
    content: "test";
    color: green;
  }
</style>
abc<img style="width: 24px; height: 24px;" src="https://pr.gg/happy.png">

[khushalsagar]

Thanks for the insight philip. I didn't consider the case of pseudo elements/UA shadow DOM. But it looks like the shadow DOM is being clipped to the video element's bounds irrespective of overflow on the video element today.

I added a transform:translateX(100px) to the root of the shadow DOM (webkit-media-controls) and its clipped even if video has overflow: visible.

[tabatkins]

We can't reuse 'overflow' for this, as it is based on different assumptions that aren't quite compatible with how replaced element contents behave. The big one is that 'overflow' clips at the padding edge, while replaced contents are clipped at the content edge; the other is that, as noted, none of the scrollable values are viable. Trying to cram this behavior into 'overflow' isn't a great idea, imo.

I agree this interaction needs clarification, tho. I can see two possibilities:

1. The object-* properties affect the "content" of the replaced element, which is analogous to children of the element, so 'overflow' should apply "after" 'object-overflow'. In other words, 'object-overflow' just tells the replaced element's contents whether to clip themselves to the content area or not; if they don't, then they potentially become ordinary overflowing content and 'overflow' applies to those overhanging bits. (This implies that replaced elements could sprout scrollbars due to object-overflow + overflow, unless we explicitly disallow that and treat the scrollable values as "clip" on replaced elements.)
2. The content of a replaced element is, as far as CSS is concerned, the element's problem, and so whatever it does is similar to other painting effects caused by the element itself, like shadows. 'overflow' continues to have no effect.

I lean slightly towards (2) for simplicity, but would be fine with either.

'overflow-clip-margin' is currently defined to solely affect "overflow: clip" and other things using the "overflow-clip edge" (like "contain: paint"). So it would have an effect on replaced elements with "contain:paint" in either of the above two choices, and replaced elements with "overflow:clip" if we go with (1). We shouldn't need to define anything special for this; the behavior will just fall out naturally.

[khushalsagar]

The option 2 above is suggesting that the source of a replaced element (image, canvas etc) should be treated similar to self visual overflow effects like shadows/blurs. If that's the case then neither of the clipping properties (overflow: clip or contain:paint) would apply. contain:paint doesn't clip these effects either.

So it seems like a fundamental question here is whether the source of a replaced element should be defined as its content (which is clipped by overflow:clip or contain:paint) or a visual effect like a shadow. The children of the element (if any) could be treated similarly.

I'm more inclined to treat them as contents since it would allow developers to customize the clip (reference box and margin) using overflow:clip and overflow-clip-margin similar to other elements. I'm unsure about whether we should allow a replaced element to become a scrollable container in that case.

[bradkemper]

We can't reuse 'overflow' for this, as it is based on different assumptions that aren't quite compatible with how replaced element contents behave. The big one is that 'overflow' clips at the padding edge, while replaced contents are clipped at the content edge; the other is that, as noted, none of the scrollable values are viable.

Don't forget textarea, which is a replaced element that can be styled with regular old overflow css.

[vmpstr]

I agree this interaction needs clarification, tho. I can see two possibilities:

I'm leaning towards 1, since we also have something like content-visibility that when applied to images does affect the contents (ie stops painting it). I think paint containment should clip any overflow that results from object-view-box that reason. All in all, I think Tab said it well in option 1: replace element's content should be treated as "content" which is subject to all of the things that "regular content" is subject to.

[Loirooriol]

Usecase for option 1: #7188

[khushalsagar]

Sounds like the consensus is for option 1. For the point below,

This implies that replaced elements could sprout scrollbars due to object-overflow + overflow, unless we explicitly disallow that and treat the scrollable values as "clip" on replaced elements

This sounds good to me. I figured scrolling won't be an issue since the overflow allowed for a replaced element is ink overflow and only layout overflow can extend the scrollable area?

[khushalsagar]

Summarizing a discussion I had with @progers in the process of implementing this today that further complicated explaining the interaction between object-overflow and overflow. Turns out SVGs already allow overflow and have the behaviour as specified in option 1.

• By default an SVG clips similar to other replaced elements. The difference is that as opposed to other replaced elements, where developers can not change this behaviour, SVG clipping is applied using a UA style rule. A developer can override this to visible to allow the SVG content to overflow. Example:

<svg style="border: 1px solid black; width: 200px; height: 200px; overflow: visible;">
  <rect x="100" y="100" width="200" height="200" fill="blue"></rect>
</svg>

• overflow:hidden when applied to an SVG element does end up diverging from the behaviour on other elements because replaced contents are clipped at the content edge and the scrollable values are ignored (i.e overflow:scroll is equivalent to overflow:hidden).

It seems like we can encapsulate the behaviour for replaced elements with a combination of overflow property and UA CSS instead of introducing the object-overflow property. The idea is for all replaced elements to respect the overflow property except making it scrollable (similar to SVG). And achieve the special behaviour using UA CSS instead of the new object-overflow property.

Each replaced element will have the following CSS to clip it to content-box by default:

overflow: hidden;
overflow-clip-margin: content-box;

Some replaced elements would have this set to !important if we want to disallow overflow in general because of security risks highlighted in #7143.

[css-meeting-bot]

The CSS Working Group just discussed [css-images-4][css-overflow-3] How do object-overflow and object-view-box interact with overflow and overflow-clip-margin?, and agreed to the following:

• RESOLVED: Add this path forward to the spec with a note linking back to this issue

The full IRC log of that discussion

<dael> Topic: [css-images-4][css-overflow-3] How do object-overflow and object-view-box interact with overflow and overflow-clip-margin?
<dael> github: https://github.com//issues/7144
<dael> khushal: supporting css overflow and overflow clip
<dael> khushal: all replaced elements clip to content box by default. each except svg don't support overflow. When overflow is on svg it diverts
<dael> khushal: svg clips to content box and we don't support properties that make it scrollable
<dael> khushal: discussion on issue toward supporting overflow for all replaced elements sim to SVG. All values supported except those that make it scrollable
<dael> khushal: Ways in clipping diverges instead of doing the behavior in engine retail with UI css. Because it's in UI CSS devs can override
<florian> q+
<smfr> q+
<florian> q- later
<dael> khushal: Want to mention that we brought up this question with overflow for replaced elements and talked about adding object-overflow to permit
<dael> khushal: In trying ti explain interaction with overflow we realized it was easier to do similar so we can remove this property from the spec
<astearns> ack smfr
<dael> smfr: Sounds like in prop that you're allowing author to set overflow:visible on replaced element. Is that true?
<dael> khushal: If a website had overflow:visible today and defaulted to clip, it would now apply and cause visible
<dael> smfr: Seems like could be compat issue
<dael> khushal: Did come up that it might break backwards compat. Applying this prop on existing page wouldn't have worked and does now. Could try and get use counter for how often it's used to confirm compat isk is minimal
<dael> smfr: 2nd question is UA applys overflow:hidden. Does that allow scripts to progmattically scroll?
<dael> khushal: that's a way replaced have behaved differently. Script won't be able to
<dael> smfr: Sound UA stylesheet use overflow:clip?
<dael> khushal: Yes, you're right
<dael> smfr: Thought I saw issue on iframes. IS this proposed for that?
<dael> khushal: Another issue about which elements to limit this. Security reasons for iFrames so could make it !important so devs can't override for something like iframe
<dael> smfr: When a replaced element has overflow b/c overflow:visible, ink or layout?
<dael> khushal: ink overflow
<dael> smfr: Different to overflow on normal element, irght?
<dael> khushal: Right. Had discussed for object overflow that overflow for replaced should be considered ink
<dael> smfr: I think b/c list of issues I'm not a big fan, but want to hear others
<astearns> ack florian
<dael> florian: I overlap with some of smfr. You said all values except scroll. but all of overflow other than visible and clip support scrolling
<iank_> is it enough to support just overflow:clip & overflow:visible ?
<dael> florian: You talked about UA using overflow:clip, but it said in issue if author did overflow:scroll it was like hidden but hidden is scrollable.
<smfr> what about overflow-x & overflow-y?
<dael> khushal: It should say clip. Anything that defines scroll maps to clip for replaced elements
<dael> astearns: And for values of overflow that are not clip or visible do we want them to work and make a scrollable thing or should they all function as overflow:clip
<dael> khushal: later. All overflow:clip for replaced elements
<dael> astearns: So they only get clip and visible
<dael> khushal: Right. Either clipped or visible
<dael> astearns: q on IRC about overflow-x and -y. If we set -x are things visible in -y?
<dael> khushal: I think it's reasonable for overflow clip and visible to be different in x or y direction
<dael> khushal: I'm interp if you set overflow-x:clip and -y:visible it will clip in x and not y
<iank_> I think part of the question is if you do overflow-y: scroll for example
<dael> florian: Yeah, Id on't see why different for this
<dael> smfr: Yeah, sounds okay
<dael> astearns: Other questions or concerns?
<dael> iank_: I think part or a question that needs to be answers if you set overflow-y:scroll what happens
<chrishtr> q+
<dael> iank_: There's various fixup today
<dael> florian: I guess either you first fixup the other dimension to be a scrolling value and then they both become clip or you coerce scrolling to slip immediately and other remains visible
<astearns> ack chrishtr
<dael> chrishtr: 3rd alternative could be ignore values other than visible and clip. Can set but don't do anything. Compute to visible
<dael> chrishtr: May be less confusing than apply some behavior but not all. It would clip but not scroll and might not know why
<dael> astearns: Use counter suggested for overfow:isible. If we want that need a use counter for all the other values on replaced elements
<dael> chrishtr: Then alternative is we could go with new css property to avoid the concerns. Does seem behaviors are similar to svg
<dael> iank_: chrishtr if I understand correct and we just do visible and clip are there compat concerns since clip hasn't been out long
<dael> chrishtr: Good point. coerce hidden and scroll to visible then it's only sites with overflow clip
<dael> smfr: Isn't compat issue overflow:visible?
<dael> vmpstr: Right, it's the other side
<iank_> my bad sorry.
<dael> smfr: And object:fit would leak pixels
<dael> khushal: I think it's something like object:position that would leak
<dael> smfr: a/r resize version of object:fit doesn't that cause bits of image to leak and if it's overflow:visible it adds ink overflow
<dael> khushal: right. If dev used overflow:visible and object-fit:cover they would get slipping now but overflow visible would start after this
<dael> florian: Back to visible in 1d and scroll in the other...I suspect doesn't matter for use case b/c you can get one behavior so for impl PoV seems easier to add conflict resolution as is. Visible in 1 and scroll in other leads to visible dimension hidden and now both behave as clip
<dael> florian: Suggest to me we don't need to change style computation ass
<dael> s/ass/pass
<dael> khushal: 2 issues. 1 how to deal with overflow in x and y direction being different. If 1 d says visisble and other scroll we coerce to scroll and then clip
<dael> khushal: second is if it's set to visible in both directions where previously ignored and now visible. Is there a way to check or is thisa deal breaker
<dael> florian: Need use counter. If it's a lot it's a deal breaker but if it's rare maybe not a problem
<dael> smfr: Do we know if reset stylesheets set overflow:visible
<astearns> ack fantasai
<Zakim> fantasai, you wanted to bring up Tab's point about content-edge vs padding-edge
<dael> iank_: I don't think it's common. Might be wrong
<dael> fantasai: I want to bring up opint from TabAtkins in thread. Overflow as a property currently clips to padding edge. Type of clipping we're looking at is content box. Replaced elements are special magic or do we need 2 properties?
<fantasai> https://github.com//issues/7188
<dael> fantasai: oriol mentioned 7188 with a use case for clipping replaced elements to padding box. Haven't looked in detail but woth considering before we decide to merge to 1 prop
<heycam> wonder if it would be difficult to make the use counter check for overflow:visible only if there's ink overflow
<dael> khushal: Suggestion on issue for changing ref box is UI CSS rule. The discussion on issue was toward if start allowing overflow on replaced elements makes sense for overflow to work as well. Idea was default behavior is done with existing properties and devs can change
<dael> fantasai: Okay
<florian> that makes sense to me
<dael> astearns: [reads IRC from heycam]
<dael> astearns: I think use counter is of overflow:visible is set on replaced elements at all. if it is can eval us to see if introducting ink overflow is going to be unacceptable change
<dael> heycam: Just looking to see if can skip manual step to check influence
<dael> astearns: Before we collect use counter, say the use counter gives it as very rare. Would anyone continue to have a problem with this change? Is it worth the use counter?
<dael> smfr: Need use counter data b/c would be compat. If use counter data is okay I'm okay with it
<dael> astearns: use counter seems like the next step. Given the details about various values and which replaced elements this impacts and overflow-x and -y and writing all that down. Once we have use counter data we can come back
<dael> chrishtr: So accept pending use counter?
<dael> astearns: Resolution is collect data and wait to resolve until it's anayzed
<dael> fantasai: With a bias toward accepting if use counter says it's okay
<dael> chrishtr: I think reasonable in my opinion to accept change and if use counter says otherwise we revert
<dael> plinss: Quick point on use counter data. I think if use counter shows a lot of usage it's easy to say no. If use counter shows little usage that doesn't mean it's clear Could be a lot of data behind something like corporate firewalls. If use counter is extremely low fine, but if use count is marginal might be breaking more than we think
<dael> astearns: As far as accept change for now and revert I do like having spect ext as opposed to a summary
<dael> chrishtr: I would point out failure is showing more ink overflow which is not that bad
<dael> astearns: But could obscure content. Making things unreadbale that used to be readable is something we have to avoid
<smfr> q+
<dael> fantasai: Example from smfr about cover image that is visible outside of image suddenly could be significant data loss. If we do find singificant use. Currently doesn't have effect but if someone used overlay general could have effect
<dael> florian: I think use counters are in engine so could get behind corporate firewalls, but wouldn't get offweb like epub.
<fantasai> s/overlay genera/overly-general selectors/
<dael> iank_: not necessarily. Depends on if org has opted into metrics collection. Orgs typically do opt out
<fantasai> s/image suddenly/img element suddenly/
<astearns> ack smfr
<dael> iank_: other point is we do have some usecounter blindness. I don't think will be case for this. Corps tend to use frameworks so if we see something on public likely to see it in the blindspot as well. Fair bit of correlation for these rendering changes
<fantasai> +1 to iank, unlikely to find this problem on intranets if open web doesn't show the problem
<dael> smfr: I think might be first time we allow contents to overlap border. Makes me wonder if we spec the paint order
<dael> fantasai: Same as other elements
<dael> smfr: So paint on top of borders?
<dael> khushal: Was going to add sg allows overflow today and I think they draw on top of border
<dael> smfr: Okay
<dael> iank_: So replaced elements paint in content phase?
<dael> astearns: We have spec a content phase in painting?
<fantasai> CSS2 appendix Z
<dael> khushal: Another question - earlier resolved having new behavior thought object overflow which is new prop where if set to visible only contents of replaced element can overflow.
<fantasai> s/Z/E/
<fantasai> https://www.w3.org/TR/2011/REC-CSS2-20110607/zindex.html#q23.0
<fantasai> The painting order of border vs replaced content is already defined
<dael> khushal: If we do see use counter usage is high enough that change is risky, would it be good to continue using object overflow and come back to group on how to handle if visible is defined?
<dael> astearns: Makes sense to me. If what discussed today dones't work we figure out how object overflow would work as a sep property for this use case
<dael> khushal: Issue was if object-overflow as defined in spec exists how does overflow interact with replaced and my take away is it continues as is. We can come back for more concrete resolution
<dael> astearns: So adding the path of using overflow on replaced elements in a draft
<dael> fantasai: Add and mark as tentative pending data with a link to the issue
<dael> astearns: Remove object overflow or put an issue on that?
<dael> fantasai: I would go with remove from spec and mentioning in issue that if we can't go in direction we're trying we may reconsider
<dael> astearns: Obj to Add this path forward to the spec with a note linking back to this issue
<dael> RESOLVED: Add this path forward to the spec with a note linking back to this issue