[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

[tabatkins]

So, unfortunately this discussion happened while I was on vacation. If I'm reading the above minutes correctly, the resolution is to remove object-overflow and just use overflow, right?

We're really okay with this, despite the number of substantially different behaviors exhibited between "normal" overflow and object-overflow?

1. Clip edge differences - content vs padding box
2. Overflow type differences - layout vs ink
3. Scrollability differences - allowed vs not (everything scrollable treated as 'clip')

[khushalsagar]

Discussed with @tabatkins offline about these differences existing (across browsers) in how overflow is supported for svg. So it seems reasonable to consistently have this overflow behaviour for all replaced elements.

[khushalsagar]

This is a follow up to the open questions from the previous resolution on this issue:

• Adding a use counter to measure the usage of overflow:visible. Since this change would change the behaviour of this property for replaced elements and cause ink overflow.

• Clarifying the behaviour for overflow values other than visible or clip.

The use counter data collected by Chrome over 1 week of a stable release (M102) is as follows. We collected 2 different counters explained below.

• The first measures any instance where overflow is explicitly set from developer styles to visible. The percentage of page loads with this is 2.16%.

• The second measures the above instances but only includes the cases with object-fit set to cover or none or object-position set to any value other than the default (50% 50%). The rationale behind this counter is to exclude cases which can not cause overflow (such as object-fit:contain), even if overflow is set to visible. The percentage of page loads with this is 0.017%.

Also note that the data above is limited to replaced elements excluding <svg> and embedded content (<iframe>, <embed>, <object>). The reason for this is as follows:

• <svg> already supports using overflow:visible so no behaviour change is needed.
• We don’t intend to allow visible overflow for embedded elements so no behaviour change is needed.

Assuming the usage is low enough to accept a change in behaviour, the proposal is as follows:

• overflow: visible on all replaced elements causes any potential overflow to paint as ink overflow.

• Values other than clip or visible, if specified, are coerced to clip. This implies that overflow values can be different in x and y directions.

• UA CSS specifies the following style rules to implement the default behaviour of replaced elements which clip to the content-box.

  img, video, canvas, svg:not(:root) {
     overflow: clip;
     overflow-clip-margin: content-box;
  }
  
  iframe, object, embed, fencedframe {
     overflow: clip !important;
     overflow-clip-margin: content-box !important;
  }

Note that the change above is consistent with the current behaviour for <svg> where all values other than visible clip the element’s contents but don’t make the element scrollable:

​​<html>
<body>
<svg id=foo style="border: 1px solid black; width: 200px; height: 200px; overflow: scroll;">
  <rect x="100" y="100" width="200" height="200" fill="blue"></rect>
</svg>
</body>
<script>
  foo.scrollTo(0, 50);
</script>
</html>

This proposal would change the UA style rule to override overflow for svg from hidden to clip (spec), which aligns with the implemented behaviour.

[tabatkins]

All right, changed Images and Overflow to match this resolution, based on the promising results from @khushalsagar. Just need to get the UA stylesheet change added to HTML and we're done here.

[Loirooriol]

Yes, I worry there may be scripts checking overflow in getComputedStyle, e.g. when displaying a fake modal dialog they may want to prevent scrolling, by turning overflow: auto or scroll into hidden, but leaving visible as either visible or clip. Defaulting to normal may break such logic.

Well, overflow could get some special handling in https://drafts.csswg.org/cssom/#resolved-values to resolve normal in getComputedStyle, but it seems hacky.

[fantasai]

@Loirooriol I think special-casing gCS() to use the used value here is better than having incorrect behavior. This is not something very unusual for us to do. But having the wrong behavior for CSS-replaced elements or non-replaced object fallback content seems like it could be an actual problem.

[khushalsagar]

Constructing the layout tree, which creates the layout objects associated with an element, is when we are guaranteed to have all the inputs which decide whether an element will render as a replaced element. The above implies that a script call to getComputedStyle on any element will also still need to construct the layout tree. My reading of the code is that the latter is already the case so this won't be an issue perf wise but something to confirm.

[khushalsagar]

Another point to consider, if we go with an approach to switch overflow to have an initial value of normal which resolves to clip or visible based on whether the element is replaced. We'll need the same for overflow-clip-margin which resolves to content-box if the element is replaced and padding-box otherwise.

[Loirooriol]

While being able to control the clipping with just 2 properties is nice, I'm not sure the required amount of workarounds affecting existing properties is really worth it. It may actually be less problematic to re-add object-overflow, then on replaced elements:

• The default object-overflow: clip clips to the content area regardless of overflow and overflow-clip-margin
• object-overflow: visible + overflow: visible shows all overflow
• object-overflow: visible + overflow: clip + overflow-clip-margin clips to the desired area
• overflow different than visible behaves as clip
• object-overflow, overflow and overflow-clip-margin have a consistent default value

[khushalsagar]

The default object-overflow: clip clips to the content area regardless of overflow and overflow-clip-margin

This doesn't hold for SVG which already causes overflow: visible to show all overflow. We could have a different default value of object-overflow: clip just for SVG to work around that. But the property combination above is not intuitive for a developer using these properties.

If the SVG behaviour didn't exist, it might've made sense to say overflow is always ignored on replaced elements in favour of object-overflow. And object-overflow works the same as overflow (except 2 values). But since SVG has already set up the pattern to use overflow on a replaced element, it makes sense to standardize that pattern for all replaced elements.

[cornedor]

I've already created a bug report here: https://bugs.chromium.org/p/chromium/issues/detail?id=1400940 since this discussion was not linked in https://developer.chrome.com/blog/overflow-replaced-elements/ and did not find any other resources at the time.

But the current implementation in Chromium results in a difference between the img element and a input with type="image". After reading through the discussion here, I don't think the input is considered.

There could be two situations in the end. One where the input is also using the overflow property. However, this could cause issues since an ink overflow is not enough here (since the user can not interact with the overflowed ink).

A second situation is one where input does not use the overflow property, and thus keeps working as before. This however results in different behavior in replaced elements.

[fantasai]

Btw, I backed out the application of overflow to replaced elements from L3 and shifted it to L4, since we're trying to stabilize L3 for CR and beyond and this clearly needs a bit more work. (See also #8271 about shuffling the levels of some other features in these specs, so that L4 is in cleaner shape, too.)

[khushalsagar]

Thanks for bringing this up. We indeed didn't consider input elements. The case with the CSS content property that @fantasai pointed out has the same issue. Example below:

<!DOCTYPE html>
<html>
<head>
  <style>
    div {
      content: url("data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wCEAAoHCBYVFRgUFRYYGRgaHBgZHBocHBgcHB4hHhUcHBwcGiMcLi4lIR4rIBwhJzgnKy8xNTU1HCQ7QDs0Py41NjEBDAwMEA8QHhISHzQrJSs2NDQ2NDQ2PTQ0NDQ2NDQ0NDQ2NDQ9NDQ0MTQxNDQ0NjQ0NjQ0NDQ0NDQ0NDQ0NDQ0NP/AABEIAK4BIgMBIgACEQEDEQH/xAAbAAEAAgMBAQAAAAAAAAAAAAAABQYDBAcCAf/EADoQAAEDAgMGBAQFAwMFAAAAAAEAAhEDIQQSMQUGQVFhcRMigZEyobHBQlJi0fAj4fEVJIIHFHKSsv/EABkBAQADAQEAAAAAAAAAAAAAAAABAgMEBf/EAB8RAQEBAQADAQADAQAAAAAAAAABAhEDITESE0FRYf/aAAwDAQACEQMRAD8A7MiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiLC6u0ENLgCbASJQZkREBERAREQEREBERAREQEREBERAREQEREBERAREQfFqbSxPh0qlT8jHO9mkrbWhtynmw9ZvOm/wD+CovxM+xRdl7Wr/GKj7n4XAvnibCIHpKuOydtsreUw13IkX6jiqfsBzX0w1j4MfhBaO5JGqyYrDvaM2aIMy4tJnnLRb5LDOrPcdW/HL6+OiIqrsXeQGKdcgO0DpbDotNvrEXVoDwdCtpqVzazZ9e0XgPB4heiVZV9Recw5hefEExInug9r4SsdSs1oJJAAEmTw5qpbU274zjSouytHxOjXgGi4iex+arrUi2c21K43bEuy0rgGHO9NBxULj2uALgXSL9/bVbOEptYAAHQdS4Se3JaW8jJYCPzAA6EX+fZY3V52ujGJ3kXbDPJY0nUtaT6gLKsdFsNaOQA+SyLojlr6iIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICx1GS0g6EEe4hZEQco2U7wXPpZJex7mm0/iUlVqOcCWBw/UHAexWDevD/7x2UEEhrnC15Go56H2Wzh6YyZg/KeBF8p52/nVcc9dz/j0dWWTX+xrMwtR9y7LFyXEHOAdL+WeTh6rcq7Za0ZKbictiePPTuYPdYMdiiQ2k90yBLmgtnUkmJvwvMz7atF7KWUMpF0ODDUIvE3niIE3PJTysLXrFbRrU6gqQ40gyMo1zakn0+hUy/EVC1pLXBxykmbCxJ14Ry6KvVnvxLzQ0guDiI0jMJHUifVb2JFQtMv89J+Q2/NTDrT3HVTNWIs6yu245mdrmFzW2DgIkw0ls+ojnK0dm42tDrHJ4hIJ4NMEz0GZ3aFuDCuqU2UWkjxMzwRYtDcuUg8DBBnmSsGztouc8UfKHMgkjQwYAdxuIE90t6jjf/1RtSaLw6CJzQGixJaDPIAeq+twQZBbdrrtdNyec9f5otbG0WOfkqiHObIAMRcumO7gI9ys2ExXhMax7YDTlbN4+HvxJ4/hPIKPaZf8bIxTmiS7pLgAexP7rXc/x6lNg/E5oc2SRAvm9gpLH5PDzPMgAXIAInpr7la+7bGtriBIcxzw48Bpbr9k77k/1tLPxdSe4ugX1EXW4BERAREQEREBERAREQEREBERAREQEREBERAREQEREFR3vwIvWHxOaKcHSA4n55vkoXCYXwWZGtPmbOV14PJswSD0Ktu2iCWtOgvcSJ0AUU1hY+NBxNrzrBlc+pP1a6M6tzI06eynPZmcSCCSJnMOXb119Ft4JjWsLHHOb+Y5ZHKYVd303mc3/b0HGmGtL6tUtuxgI+Dm8kwFQt49qUqNdv8A22Lr1mkNc6p4jpDpNo+F1oMRaYSdvxFvPVdF3UpCm+u9582d3AjhA7g/2XrEVGubUOYjO8yNOGUEctJWpujVdiqTiSM4gOcLZgWy1/SRbuCtt9DL5XA6n+BZe7Gsufsbmz64FRjpgAPAE6h2Uu9i36rxiMIw45lRkAOaS+NIAtPIyfmVr0cKXvbHCfbr1UXvrjzhmhjHZHFpe94gua2coDZ/E42B/SVPuRF59W3aeHbVePPkBjTX+cVjxeyTlhrr/hMXAsdD217rku6+0cO/xn18XXwz2AOpkVHuLjcmQ6Q64Hli8rpW6W8rqrTRxBaajYOdohr2uAc1w4CQdFpfX1nL34+3ePCqOJIcfNYk2JEDRoA0J116qwbs0W5ZvmZmbJ1GYgnpwGixMoBziRccefMfDeJW3sow4uB+KMw6pmT9SmtX88TiIi6GAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiCm7fxYz/ABBrWnzGYjj9lr7MxTKmas4AyfLJmw0gNMdbhRO9ez31MT4Xmy/GS1wBg8I46LBUYWZWMgECMrjwnUydVybvK6cTsau/uzS9zq4tRq0vCc6DFJ7Xh7HVIHlYTYu4SuYjd7EZ8nhOnnbLHPN8OXrK7RhNpPYS0m5tGovzHEe+nFSuAxTB5mUaYjiGNBJ6ZRqk1Z8V1iqvuBSdhqz2vY4M8KmxriIzObJLo1DTmMSNBOhCtOJexziTHTjx/nsoja4fJrfCHOmeMf3XrZeNpxmqPgjUEfVZfrXfy2njkz1O4YMY6RB48J0XNt9qFTEV65ykU3sYGv1a0sJcM8Xa1xcRJsrZtLHMJ/pvm9yJGo49Oq2NmsdScytZwiCRHHWQOCfrX64a8cueuG0thVy7Lky8S9xAaB+Yu0jtK65uNsw0mvr1GkMcGU6YeC0llNmUPINwHGSOiseNxga7MWMbBsQ0T7xqoSrin1XE5jA/FMyJnjbhwWt3b9ZZxW5vDi20cldjgAHCb2cCYI48/lotnZWMHitIeHB4kQb8DeTpCjK2FdUAY6XseL2Av6rzu5svwcUGBgyuu18yRHAi8HqOiYvVtTkdLX1EXW5RERAREQEREBERAREQEREBERAREQEREBERAREQEREFX29Qayp4zuWth+8/JVLa21cOYcXNJ6HT2/wug7d2azEUix+ms3+y5idlsY+7GkzYgEAdRqVzeWcv/HT4b2Mmz8K6q/MxsMDbPe7NOmgBgDup+hUefLTY2pBAOV0Bo4FxuNBN1r4LC5ctQwGcJtm7c/SfRTGPrhrADncLEMpyHE9T1VJPXV9X29swjMQ0txDMs+WzxeRfKWG0GRbkqDvTu8/AONZlR9Sg4EAOuWOny5iNQbjNrOqumDIZ5/BYw3hpILgTe8WmSefdQ29u2CKT87rO8rW9YMGFpnObOWKzWs6ll+NPdXdU4knEYipUZScQWUZyZmhti+LgEyYBuCJ5K4vp+GDTo0i8WEB7BAJA4mYi/MxzUHsLbJfTa9pBBEZeAItHQfspGmcxzsYwnUhpyuMAiATabk3jRRrMnOQ/WtW23608WzOPDc17HHRrmuJsYJaSIi3UXUezDCl561FzzNg0wOpywACrVRe4tAPna2BDxFRvcmzwecjTitHGUYdJAZOhA1HT+yprP9pzr+mjhtv0SQCQ0fqLQfbUKx7Gw7HP8RsdxPHv9lVsVs9tU5Syeun3lXbYWCbSpNa2dONyreKW1Xy8k9JNERdTmEREBERAREQEREBERAREQEREBERAREQEREBERAREQYMS6Gm8WVLx9Wmx05Q93Mxlae34j3EdFL7Z2h5g38I10En1VQxWNAebySTz9LrDyabePLDjnVHv8QOl3Akkgdp/spbY+OeGDxIDnEtYeB/M/sP3UXQwznua0GJgduZ/ZZsVii57ixsNYMjCeU5c3qA73WWfV63vucTlfDyHBgALpuL+/wAwoR+7wLTmlx4k34/usD8TWaZDsrbmTqXF7iBHQR7qZ2ftiwa8ZuuhK1lzWfNR4wW7rWgESwzNjY9D06KabgmNAzECDqel5+6i8ftl5afCaBbjrxUc7EOcG5ySXeYidOEfX5KLqImbU/jNo5mkUyC5sh0zFviHcfS/Q6FBzhJJzsJux1wD05HqNR6x8ofmbqQx4P6hafW6ymq1rW1HQxptfQE/hP6TqOSrfftb1JyN+nQAaXsBP6dT6REhTOy60jLyuFWX4gktyE5QZkEWPIx/D7qW2bjgXw74vzDQ+nP6q+LJWepbFgREW7EREQEREBERAREQEREBERAREQEREBERAREQEREHxeKzoaT0XtRe2se2m2C4BxuAot5Opk7eIDa7C6ftwVI2lLXe8SYI9b/RW3F4xgZncT5vwxP0uoOpSbXMNaCJ1mYXJr26s+mphqr2U3vaTncwhmhAk5JbHuf+BWPA1ntpnO8FznkTERlaIA7SvW1RkMzlDW3HIubI01IaGt/4BVuntElkTpVvx+Jkif8A0Kp228jScn1c6rxeLknMPUCO1oXh9bKYOvL+cFgweJ8o0kCD9fv8lCbZxT8zSy9wY53n2spl9p4nK2Ie2AAJM2M6ZR+49l9wuGcAXjU6g31tblr/ACFqU68Bj32LRf8A5CT9x6BbWL2i1gyW8zss8vMIKrfZ8TDcTDGFpvBju17jB9vmlSsM2R4ljtQdIcMzXN6g6+qg6eJLAwRMDMes1HrNiqrntZ+QgzaSIdMgjUAOA7BWmlLlIYLEZXuAuLtOgJAMQQeIUzgMweLyLEECJH84d1DU6bAQWidA70EA/wA5Kw4PEtIF76gTB6iPsr4qm4tVI+UTyWRY6J8o7BZF1uUREQEREBERAREQEREBERAREQEREBERB8WhjtqU6XxuAJ0Gv0XjbmOFGi95MQD/AIHVUnAY84horlpAiBmjl5o7G0zwKw8vlufUa+Px/r3Vgrb1U8xa1wMR8N9ecaLRpb3+YSLTEyYF4kyAIUVXex72lrQ+A+XSAB5hY8eE+y0WV6DqhYMgc0uBAIMRa44duh6Lmu9X37bzGF/pbcabGx5wY+SisaHOLg9s5hYi/a6qO1N4jgtGNeCdC4N/DoC6xMNMAXVh2ftZtegyvS+B4mI0OjmwNDKtrWtZlqJnObyIZ9EszMf8NzBkyeHy4/wZNnnKII8pIboLTYwBbSf5ZZdqV6b2EuDgRraD3H7qOwWOIb8JIh7gBEkkZW25W+Y4Kub1azjT21QdVnLIzGTHUnisWx9iNaHh0EEAi0mWEkfLMt7xQbhxBFja2twOboBvzWvisW9hljT5Yka3HbgLD/KjnGnetuq1jQWjl7nSFEuqsc/haw9ot7j3Xqq8uc4TADSRyyyRHpp6LUZhDmJY2wcB5uED5CIVP7WTFbDh4ItYtI9yI91hrbPzAB2v7CP52WLAOcCZOfzN0IiSfsQpI4qXhuhLvL0hzvtCnnVe8a9SGFgkgta1hkc2SZ4amVK4drQwT+Yz0zNAHzaoLFVA5865iDrYaEHqDp6LcOMa6mTTcPiAE8SG/DJtF+PRWk9ovxtU8QGuM5RwkHW9j6GCtrYlV76hOV0g8ffhbXl9lWqYc92UNgkyddSbz10+avmCp+GySQBlJcdOHmN/X3VpVNROnbDWNAdrHCTEc1E47evI7KBJGt7CdBaTKpuH3yGJe6lTY0M8wa6W5iAQJyjzAEmxOq2sdUosILy2TPENBJE6nifup1vffzVc4z9WqhvYyA5xABIF9Ln82imsHtujUMNe2e/05qhtyBzHlgDIccwcIHkJzGe0fPtuV6kN8RgLslxFyRF/kNOiZ82oa8Wa6GEVb3P2yMTTJHBzhB1sbH1F1ZF2Z1+p1y6nLx9REVkCIiAiIgIiICIiAiIgIiIKp/1DwBrYOo0SDEgiZBBkEQqvsFgZg6TdTkgnrx/aOC6dXpBzSHCQeCgMZuuwty0jkF/KSXNuZtNxdc/lxb8bePcz9ULZjMj64aXNDocRa5BIJnWI4LUbs4U8bTqNuKrXB4mQHNLSHCOJAv37rf29sDEYRza5fTex/wDTyjMHS4SHExBuB9bqw092X4hjCagYWZSHtu8cwJEQRAvyVJjXxe6n1XNvYOnUJY4/hDo+KS1wjXTylysGxNhObhMPSpN8rWgvOYC5bePUkqYw25uHbUbVeX1HtBHncMpnWWtAB9VY2sAAAAAGgFgOy0x4uTlU15ffYqT9hVoPkaTwGZv3UPit0sRDixrcxaG3cLXbOtjoV0hFb+HKs8uo5O3c/Gl5e+m2dGw9sATf1iTPPLyvtt3VxcA+G0HiA9sRMDje3zXTUT+HKf5dOZVd1MVdrabYOUA52iBYO04eUHuVpVtzMa4nytAmwztjSCT7BdaRRfBmpnn1HJKe5+Oa3KykwWF8zefC/Ikeqy4jdTHSXspMLplsvZ+KC4dtV1ZfUnhzEXzarhtXcTabn5sjMsgj+o0ZfKAQI4fsCpTD7i4wNDXMZdz3OIeI8wboO4PuuuorXxZpPLqKHs7dOoy7mjNxvr111Uv/AKdUaIcJZlc11xMGFZUUTw5k4i+XVrimx9jU8O/KLEvIj9LXPLb9y32WXeTZ4r18NSNmS57iCZhrYDb85v2XSNp7q4es4PLSx4JIcxxbc6kj4T6hQ1TdQ0Xur+KanlgZwAWiZOXKIM6SVnfHZr9NJ5JZxV9psmgWFxyuc1pAykRIJA5WgevBTGygPDykWj1FlDt2TiMViDRpvpt8Muc4uzHMDYAADWCb8Os2u2yt1ywf1nB3/iXCbRBNjEWss/49Xi38kiv/APSfZxpis8kuzuMHoCYA4Rx7krpK1cDgKdFoZTaGtHC5+q2l1Ylk9ufV7X1ERXVEREBERAREQf/Z");
      width: 100px;
      height: 100px;
      object-fit: none;
      object-position: 0% 0%;
      overflow: visible;
    }
    img {
      width: 100px;
      height: 100px;
      object-fit: none;
      object-position: 0% 0%;
      overflow: visible;
    }
    
  </style>
</head>
<body>
  <div></div>
  <img src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wCEAAoHCBYVFRgUFRYYGRgaHBgZHBocHBgcHB4hHhUcHBwcGiMcLi4lIR4rIBwhJzgnKy8xNTU1HCQ7QDs0Py41NjEBDAwMEA8QHhISHzQrJSs2NDQ2NDQ2PTQ0NDQ2NDQ0NDQ2NDQ9NDQ0MTQxNDQ0NjQ0NjQ0NDQ0NDQ0NDQ0NDQ0NP/AABEIAK4BIgMBIgACEQEDEQH/xAAbAAEAAgMBAQAAAAAAAAAAAAAABQYDBAcCAf/EADoQAAEDAgMGBAQFAwMFAAAAAAEAAhEDIQQSMQUGQVFhcRMigZEyobHBQlJi0fAj4fEVJIIHFHKSsv/EABkBAQADAQEAAAAAAAAAAAAAAAABAgMEBf/EAB8RAQEBAQADAQADAQAAAAAAAAABAhEDITESE0FRYf/aAAwDAQACEQMRAD8A7MiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiLC6u0ENLgCbASJQZkREBERAREQEREBERAREQEREBERAREQEREBERAREQfFqbSxPh0qlT8jHO9mkrbWhtynmw9ZvOm/wD+CovxM+xRdl7Wr/GKj7n4XAvnibCIHpKuOydtsreUw13IkX6jiqfsBzX0w1j4MfhBaO5JGqyYrDvaM2aIMy4tJnnLRb5LDOrPcdW/HL6+OiIqrsXeQGKdcgO0DpbDotNvrEXVoDwdCtpqVzazZ9e0XgPB4heiVZV9Recw5hefEExInug9r4SsdSs1oJJAAEmTw5qpbU274zjSouytHxOjXgGi4iex+arrUi2c21K43bEuy0rgGHO9NBxULj2uALgXSL9/bVbOEptYAAHQdS4Se3JaW8jJYCPzAA6EX+fZY3V52ujGJ3kXbDPJY0nUtaT6gLKsdFsNaOQA+SyLojlr6iIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICx1GS0g6EEe4hZEQco2U7wXPpZJex7mm0/iUlVqOcCWBw/UHAexWDevD/7x2UEEhrnC15Go56H2Wzh6YyZg/KeBF8p52/nVcc9dz/j0dWWTX+xrMwtR9y7LFyXEHOAdL+WeTh6rcq7Za0ZKbictiePPTuYPdYMdiiQ2k90yBLmgtnUkmJvwvMz7atF7KWUMpF0ODDUIvE3niIE3PJTysLXrFbRrU6gqQ40gyMo1zakn0+hUy/EVC1pLXBxykmbCxJ14Ry6KvVnvxLzQ0guDiI0jMJHUifVb2JFQtMv89J+Q2/NTDrT3HVTNWIs6yu245mdrmFzW2DgIkw0ls+ojnK0dm42tDrHJ4hIJ4NMEz0GZ3aFuDCuqU2UWkjxMzwRYtDcuUg8DBBnmSsGztouc8UfKHMgkjQwYAdxuIE90t6jjf/1RtSaLw6CJzQGixJaDPIAeq+twQZBbdrrtdNyec9f5otbG0WOfkqiHObIAMRcumO7gI9ys2ExXhMax7YDTlbN4+HvxJ4/hPIKPaZf8bIxTmiS7pLgAexP7rXc/x6lNg/E5oc2SRAvm9gpLH5PDzPMgAXIAInpr7la+7bGtriBIcxzw48Bpbr9k77k/1tLPxdSe4ugX1EXW4BERAREQEREBERAREQEREBERAREQEREBERAREQEREFR3vwIvWHxOaKcHSA4n55vkoXCYXwWZGtPmbOV14PJswSD0Ktu2iCWtOgvcSJ0AUU1hY+NBxNrzrBlc+pP1a6M6tzI06eynPZmcSCCSJnMOXb119Ft4JjWsLHHOb+Y5ZHKYVd303mc3/b0HGmGtL6tUtuxgI+Dm8kwFQt49qUqNdv8A22Lr1mkNc6p4jpDpNo+F1oMRaYSdvxFvPVdF3UpCm+u9582d3AjhA7g/2XrEVGubUOYjO8yNOGUEctJWpujVdiqTiSM4gOcLZgWy1/SRbuCtt9DL5XA6n+BZe7Gsufsbmz64FRjpgAPAE6h2Uu9i36rxiMIw45lRkAOaS+NIAtPIyfmVr0cKXvbHCfbr1UXvrjzhmhjHZHFpe94gua2coDZ/E42B/SVPuRF59W3aeHbVePPkBjTX+cVjxeyTlhrr/hMXAsdD217rku6+0cO/xn18XXwz2AOpkVHuLjcmQ6Q64Hli8rpW6W8rqrTRxBaajYOdohr2uAc1w4CQdFpfX1nL34+3ePCqOJIcfNYk2JEDRoA0J116qwbs0W5ZvmZmbJ1GYgnpwGixMoBziRccefMfDeJW3sow4uB+KMw6pmT9SmtX88TiIi6GAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiCm7fxYz/ABBrWnzGYjj9lr7MxTKmas4AyfLJmw0gNMdbhRO9ez31MT4Xmy/GS1wBg8I46LBUYWZWMgECMrjwnUydVybvK6cTsau/uzS9zq4tRq0vCc6DFJ7Xh7HVIHlYTYu4SuYjd7EZ8nhOnnbLHPN8OXrK7RhNpPYS0m5tGovzHEe+nFSuAxTB5mUaYjiGNBJ6ZRqk1Z8V1iqvuBSdhqz2vY4M8KmxriIzObJLo1DTmMSNBOhCtOJexziTHTjx/nsoja4fJrfCHOmeMf3XrZeNpxmqPgjUEfVZfrXfy2njkz1O4YMY6RB48J0XNt9qFTEV65ykU3sYGv1a0sJcM8Xa1xcRJsrZtLHMJ/pvm9yJGo49Oq2NmsdScytZwiCRHHWQOCfrX64a8cueuG0thVy7Lky8S9xAaB+Yu0jtK65uNsw0mvr1GkMcGU6YeC0llNmUPINwHGSOiseNxga7MWMbBsQ0T7xqoSrin1XE5jA/FMyJnjbhwWt3b9ZZxW5vDi20cldjgAHCb2cCYI48/lotnZWMHitIeHB4kQb8DeTpCjK2FdUAY6XseL2Av6rzu5svwcUGBgyuu18yRHAi8HqOiYvVtTkdLX1EXW5RERAREQEREBERAREQEREBERAREQEREBERAREQEREFX29Qayp4zuWth+8/JVLa21cOYcXNJ6HT2/wug7d2azEUix+ms3+y5idlsY+7GkzYgEAdRqVzeWcv/HT4b2Mmz8K6q/MxsMDbPe7NOmgBgDup+hUefLTY2pBAOV0Bo4FxuNBN1r4LC5ctQwGcJtm7c/SfRTGPrhrADncLEMpyHE9T1VJPXV9X29swjMQ0txDMs+WzxeRfKWG0GRbkqDvTu8/AONZlR9Sg4EAOuWOny5iNQbjNrOqumDIZ5/BYw3hpILgTe8WmSefdQ29u2CKT87rO8rW9YMGFpnObOWKzWs6ll+NPdXdU4knEYipUZScQWUZyZmhti+LgEyYBuCJ5K4vp+GDTo0i8WEB7BAJA4mYi/MxzUHsLbJfTa9pBBEZeAItHQfspGmcxzsYwnUhpyuMAiATabk3jRRrMnOQ/WtW23608WzOPDc17HHRrmuJsYJaSIi3UXUezDCl561FzzNg0wOpywACrVRe4tAPna2BDxFRvcmzwecjTitHGUYdJAZOhA1HT+yprP9pzr+mjhtv0SQCQ0fqLQfbUKx7Gw7HP8RsdxPHv9lVsVs9tU5Syeun3lXbYWCbSpNa2dONyreKW1Xy8k9JNERdTmEREBERAREQEREBERAREQEREBERAREQEREBERAREQYMS6Gm8WVLx9Wmx05Q93Mxlae34j3EdFL7Z2h5g38I10En1VQxWNAebySTz9LrDyabePLDjnVHv8QOl3Akkgdp/spbY+OeGDxIDnEtYeB/M/sP3UXQwznua0GJgduZ/ZZsVii57ixsNYMjCeU5c3qA73WWfV63vucTlfDyHBgALpuL+/wAwoR+7wLTmlx4k34/usD8TWaZDsrbmTqXF7iBHQR7qZ2ftiwa8ZuuhK1lzWfNR4wW7rWgESwzNjY9D06KabgmNAzECDqel5+6i8ftl5afCaBbjrxUc7EOcG5ySXeYidOEfX5KLqImbU/jNo5mkUyC5sh0zFviHcfS/Q6FBzhJJzsJux1wD05HqNR6x8ofmbqQx4P6hafW6ymq1rW1HQxptfQE/hP6TqOSrfftb1JyN+nQAaXsBP6dT6REhTOy60jLyuFWX4gktyE5QZkEWPIx/D7qW2bjgXw74vzDQ+nP6q+LJWepbFgREW7EREQEREBERAREQEREBERAREQEREBERAREQEREHxeKzoaT0XtRe2se2m2C4BxuAot5Opk7eIDa7C6ftwVI2lLXe8SYI9b/RW3F4xgZncT5vwxP0uoOpSbXMNaCJ1mYXJr26s+mphqr2U3vaTncwhmhAk5JbHuf+BWPA1ntpnO8FznkTERlaIA7SvW1RkMzlDW3HIubI01IaGt/4BVuntElkTpVvx+Jkif8A0Kp228jScn1c6rxeLknMPUCO1oXh9bKYOvL+cFgweJ8o0kCD9fv8lCbZxT8zSy9wY53n2spl9p4nK2Ie2AAJM2M6ZR+49l9wuGcAXjU6g31tblr/ACFqU68Bj32LRf8A5CT9x6BbWL2i1gyW8zss8vMIKrfZ8TDcTDGFpvBju17jB9vmlSsM2R4ljtQdIcMzXN6g6+qg6eJLAwRMDMes1HrNiqrntZ+QgzaSIdMgjUAOA7BWmlLlIYLEZXuAuLtOgJAMQQeIUzgMweLyLEECJH84d1DU6bAQWidA70EA/wA5Kw4PEtIF76gTB6iPsr4qm4tVI+UTyWRY6J8o7BZF1uUREQEREBERAREQEREBERAREQEREBERB8WhjtqU6XxuAJ0Gv0XjbmOFGi95MQD/AIHVUnAY84horlpAiBmjl5o7G0zwKw8vlufUa+Px/r3Vgrb1U8xa1wMR8N9ecaLRpb3+YSLTEyYF4kyAIUVXex72lrQ+A+XSAB5hY8eE+y0WV6DqhYMgc0uBAIMRa44duh6Lmu9X37bzGF/pbcabGx5wY+SisaHOLg9s5hYi/a6qO1N4jgtGNeCdC4N/DoC6xMNMAXVh2ftZtegyvS+B4mI0OjmwNDKtrWtZlqJnObyIZ9EszMf8NzBkyeHy4/wZNnnKII8pIboLTYwBbSf5ZZdqV6b2EuDgRraD3H7qOwWOIb8JIh7gBEkkZW25W+Y4Kub1azjT21QdVnLIzGTHUnisWx9iNaHh0EEAi0mWEkfLMt7xQbhxBFja2twOboBvzWvisW9hljT5Yka3HbgLD/KjnGnetuq1jQWjl7nSFEuqsc/haw9ot7j3Xqq8uc4TADSRyyyRHpp6LUZhDmJY2wcB5uED5CIVP7WTFbDh4ItYtI9yI91hrbPzAB2v7CP52WLAOcCZOfzN0IiSfsQpI4qXhuhLvL0hzvtCnnVe8a9SGFgkgta1hkc2SZ4amVK4drQwT+Yz0zNAHzaoLFVA5865iDrYaEHqDp6LcOMa6mTTcPiAE8SG/DJtF+PRWk9ovxtU8QGuM5RwkHW9j6GCtrYlV76hOV0g8ffhbXl9lWqYc92UNgkyddSbz10+avmCp+GySQBlJcdOHmN/X3VpVNROnbDWNAdrHCTEc1E47evI7KBJGt7CdBaTKpuH3yGJe6lTY0M8wa6W5iAQJyjzAEmxOq2sdUosILy2TPENBJE6nifup1vffzVc4z9WqhvYyA5xABIF9Ln82imsHtujUMNe2e/05qhtyBzHlgDIccwcIHkJzGe0fPtuV6kN8RgLslxFyRF/kNOiZ82oa8Wa6GEVb3P2yMTTJHBzhB1sbH1F1ZF2Z1+p1y6nLx9REVkCIiAiIgIiICIiAiIgIiIKp/1DwBrYOo0SDEgiZBBkEQqvsFgZg6TdTkgnrx/aOC6dXpBzSHCQeCgMZuuwty0jkF/KSXNuZtNxdc/lxb8bePcz9ULZjMj64aXNDocRa5BIJnWI4LUbs4U8bTqNuKrXB4mQHNLSHCOJAv37rf29sDEYRza5fTex/wDTyjMHS4SHExBuB9bqw092X4hjCagYWZSHtu8cwJEQRAvyVJjXxe6n1XNvYOnUJY4/hDo+KS1wjXTylysGxNhObhMPSpN8rWgvOYC5bePUkqYw25uHbUbVeX1HtBHncMpnWWtAB9VY2sAAAAAGgFgOy0x4uTlU15ffYqT9hVoPkaTwGZv3UPit0sRDixrcxaG3cLXbOtjoV0hFb+HKs8uo5O3c/Gl5e+m2dGw9sATf1iTPPLyvtt3VxcA+G0HiA9sRMDje3zXTUT+HKf5dOZVd1MVdrabYOUA52iBYO04eUHuVpVtzMa4nytAmwztjSCT7BdaRRfBmpnn1HJKe5+Oa3KykwWF8zefC/Ikeqy4jdTHSXspMLplsvZ+KC4dtV1ZfUnhzEXzarhtXcTabn5sjMsgj+o0ZfKAQI4fsCpTD7i4wNDXMZdz3OIeI8wboO4PuuuorXxZpPLqKHs7dOoy7mjNxvr111Uv/AKdUaIcJZlc11xMGFZUUTw5k4i+XVrimx9jU8O/KLEvIj9LXPLb9y32WXeTZ4r18NSNmS57iCZhrYDb85v2XSNp7q4es4PLSx4JIcxxbc6kj4T6hQ1TdQ0Xur+KanlgZwAWiZOXKIM6SVnfHZr9NJ5JZxV9psmgWFxyuc1pAykRIJA5WgevBTGygPDykWj1FlDt2TiMViDRpvpt8Muc4uzHMDYAADWCb8Os2u2yt1ywf1nB3/iXCbRBNjEWss/49Xi38kiv/APSfZxpis8kuzuMHoCYA4Rx7krpK1cDgKdFoZTaGtHC5+q2l1Ylk9ufV7X1ERXVEREBERAREQf/Z"></img>
</body>
</html>

The overflow property works on img but not on div. And the UA CSS setup can't be used to for the default clip behaviour in these cases. So I'm supportive of @fantasai's suggestion above: "we can instead add a new initial value to overflow (e.g. normal) that computes to either visible or clip depending on whether the element is actually replaced." And get the behaviour consistent across all replaced elements.

[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`?.

The full IRC log of that discussion

<emilio> fantasai: lots of discussion after the OP
<emilio> ... we decided to extend overflow application to replaced elements
<emilio> ... and make their overflow ink other than scrollable
<emilio> ... then decided that scrollable overflow values behaved as clip
<emilio> ... and host lang defines this
<emilio> ... issue is that replaced elements can or not be replaced depending on whether they load or not
<emilio> ... same for `content: url()`
<emilio> ... so you might get alt text clipped or not
<emilio> ... so proposed a new initial value
<emilio> ... but oriol pointed that that is unfortunate
<emilio> ... so proposal is to make the new value remain auto but return something else in gCS
<emilio> oriol: I think kushal's proposal to handle it with two properties looks nice
<emilio> ... new initial value or doing different things depending on whether the element is replaced or not seems like a workaround and it might not be worth it
<emilio> ... I have an additional proposal using three properties in the issue
<emilio> ... we'd re-add object-overflow
<emilio> ... I think by adding it these interactions / corner-cases can be explained by the third property
<emilio> ... I think only inconsistency would be svg
<emilio> ... which currently aren't clipped but are replaced
<emilio> ... but this can be a simple rule in the UA sheet
<emilio> dbaron: is the svg behavior consistent between svg-in-document and svg-as-image?
<emilio> fantasai: svg-as-image definitely clips by default
<emilio> dbaron: maybe svg and markup is a different case from images anyways
<emilio> fantasai: I think so, I think you might want to apply it to <svg> elements in the UA sheet
<emilio> dbaron: maybe object-overflow shouldn't apply to svg elements within the document
<emilio> astearns: so object-overflow was something that was introduced then removed?
<emilio> fantasai: yeah we tried to make overflow work instead, but I think there are some problems with that
<emilio> dbaron: I believe there's some connection to the view-transitions work here?
<emilio> ... Suspect that's why kushal was interested
<fantasai> emilio: Concern with making overflow just work
<ydaniv> embedded SVG has overflow hidden rule in the UA, and it can be overriden
<fantasai> emilio: ther'es other cases where it doesn't create a scrollable element, is the concern just backwards compat?
<emilio> fantasai: not just that
<emilio> ... the problem is that whether an element is replaced or not (and thus whether it should clip by default) depends on other stuff
<emilio> ... so we can't make it just a simple UA sheet rule etc
<emilio> ... and if you use CSS to turn something into a replaced element you'd get visible which might not be what authors expect
<fantasai> s/stuff/stuff that can't be selected against/
<fantasai> emilio: at least for everything but the 'content' case, I think it could be addressed with CSS?
<fantasai> emilio: we have internal pseudo-classes for images that are broken
<fantasai> emilio: so we could conditionally apply the new overflow value, clip vs visible, based on that pseudo element
<fantasai> emilio: still problematic for 'content' though
<fantasai> emilio: idk if that's a huge issue? not sure it's used a lot
<fantasai> emilio: might be able to get away with it
<fantasai> emilio: authors can set clip themselves
<fantasai> fantasai: yes, but it's weird if it doesn't clip!
<fantasai> emilio: you want img/svg/etc to have overflow:clip by default in the UA sheet
<fantasai> emilio: and ... then the weird case is content
<fantasai> emilio: but could make broken images be visible again using pseudos
<fantasai> emilio: also, overflow doesn't apply to inline boxes so they'd be visible
<fantasai> fantasai: not all images are 'display: inline'
<emilio> astearns: so emilio suggests that with the existing properties UA sheet could express it
<emilio> ... but there'd be no facility for replaced element fallback
<astearns> s/facility/author facility/
<emilio> ydaniv: People override overflow on SVG elements
<emilio> ... and it works
<emilio> fantasai: I think using a UA sheet might be complicated from an author's point
<emilio> ... and the other two other alternatives (new initial value or splitting into another property) would be easy to understand
<emilio> astearns: would it be easy to start with the magic initial value and add the new property if that's not sufficient?
<emilio> fantasai: we could though it'd be weird to have two different things doing the same thing
<emilio> q+
<emilio> oriol: there was also the problem that it's not just about whether overflow should clip but also what the initial clipping area is
<emilio> ... I don't recall how this model was addressing this problem
<emilio> ... But by adding a third property that'd be more reasonable
<astearns> ack emilio
<emilio> fantasai: agree
<fantasai> emilio: if we add a magic initial value for 'overflow' and 'overflow-clip-box' as well
<fantasai> emilio: but not expose it to content, make the resolved value (getComputedStyle) would be the used value
<fantasai> emilio: wouldn't that basically address the issue, without introducing new magic for authors?
<fantasai> emilio: if authors say 'overflow: visible', that just works
<fantasai> emilio: then authors don't need to worry about it, and I don't think it'd be harder to implement
<fantasai> emilio: maybe it's harder to understand
<fantasai> emilio: we don't need a good name for magic auto, because it's not exposed to authors
<fantasai> fantasai: we could just call it 'noral'
<fantasai> s/noral/normal/
<emilio> astearns: so the magic is that it's a value that authors don't use and never see because gCS lies
<emilio> fantasai: so to recap 3 options... Selectors in UA sheet, magic initial value that disappears in gCS, and separate properties
<emilio> ... I think either could work the questions is what's better
<emilio> astearns: kushal seemed fine with the magic value, did they express opinion on the extra property?
<emilio> ... Maybe go back to the issue but restrict to the magic value or extra property options?
<fantasai> emilio: I think the magic value would be nicer for authors
<fantasai> emilio: things just work as you specify stuff
<fantasai> emilio: but it may benefit from some experimentation
<astearns> ack fantasai
<emilio> fantasai: I think the major thing to consider is "do you as an author want to control overflow application independently for a single element independent on whether it ends up replaced or not"
<emilio> ... do I want to set overflow differently depending on whether or not it ends up being replaced
<emilio> ... let's say I do overflow: auto on an <object> but take the same layout space
<emilio> ... then the replaced element would get a different value either
<emilio> ... if we decide having the values in sync is fine then we can do a single property
<fantasai> ... if not, then we need separate values
<fantasai> emilio: why is overflow special compared to replaced/non-replaced? We could expose that via pseudo-classes
<fantasai> emilio: that also allows changing any other property
<fantasai> emilio: If we decide that use case is valuable, we have issues on file for exposing whether an image is broken or not etc.
<fantasai> astearns: My intuition matches Emilio's, wanting to apply different things depending on state isn't worth a separate property in this case
<fantasai> astearns: but only lightly in that camp, could go either way
<fantasai> astearns: So if people want to resolve on having a magic initial value and work that through, happy to do that, but maybe better to take it back to the issue
<emilio> astearns: if people want to resolve on magic initial value and work that through, but might be better to take it back to the issue on these specific questions
<emilio> fantasai: I'd be also fine with leaving it open but drafting the initial value in overflow-4
<emilio> ... and posting a comment on the issue
<emilio> astearns: would you volunteer to do that?
<emilio> fantasai: yes
<emilio> ACTION: fantasai to draft the magic value in overflow-4
<emilio> and leave the issue open and use it to drive future discussions

[astearns]

Summarizing the breakout discussion

We are considering two options:

A new initial value with some complex behavior
A new property

Fantasai will be drafting text to describe the new initial value, and we should continue discussing the pros and cons of these two options here for now.

[khushalsagar]

Apologies for not being there for the discussion, was OOO when this came up. I just caught up with the notes and +1 to the conclusion: "add a magic initial value". That is the easiest thing for authors to understand and also works well with how overflow is currently used with SVG. This could use a stab at implementation. In Blink, we don't know whether an element is replaced or not during the style cascade. It happens when building the layout tree. And Idk if there is any spot in the style cascade which would want the used value for overflow instead of the new magic value.

I'm assuming the same pattern will be taken up with overflow-clip-margin. Right now its default is padding-box but a new magic auto value here would result in a used value of content-box if it applies to a replaced element.

The point about authors wanting to specify a different value based on whether the element is replaced or not is a good catch. The proposal for a pseudo-class would have the same issue as above, we don't know this during the style cascade. I expect it won't be a concern for overflow since the style cascade can have the new magic value as the resolved value.

[khushalsagar]

Had a chat with @lilles about this today. He confirmed that its not possible to know whether an element is replaced or not during the style cascade. So the computed value for overflow will have to be normal. Used value will be either visible or clip. And to ensure the change is not observable to authors, resolved value will map to the used value.