Re: [csswg-drafts] [css-images-4][css-overflow-3] How do `object-overflow` and `object-view-box` interact with `overflow` and `overflow-clip-margin`? (#7144)

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

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7144#issuecomment-1431657225 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 15 February 2023 16:38:46 UTC