- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Apr 2022 23:48:54 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-images-4][css-overflow-3] How do object-overflow and object-view-box interact with overflow and overflow-clip-margin?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/7144<br> <dael> khushal: supporting css overflow and overflow clip<br> <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<br> <dael> khushal: svg clips to content box and we don't support properties that make it scrollable<br> <dael> khushal: discussion on issue toward supporting overflow for all replaced elements sim to SVG. All values supported except those that make it scrollable<br> <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<br> <florian> q+<br> <smfr> q+<br> <florian> q- later<br> <dael> khushal: Want to mention that we brought up this question with overflow for replaced elements and talked about adding object-overflow to permit<br> <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<br> <astearns> ack smfr<br> <dael> smfr: Sounds like in prop that you're allowing author to set overflow:visible on replaced element. Is that true?<br> <dael> khushal: If a website had overflow:visible today and defaulted to clip, it would now apply and cause visible<br> <dael> smfr: Seems like could be compat issue<br> <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<br> <dael> smfr: 2nd question is UA applys overflow:hidden. Does that allow scripts to progmattically scroll?<br> <dael> khushal: that's a way replaced have behaved differently. Script won't be able to<br> <dael> smfr: Sound UA stylesheet use overflow:clip?<br> <dael> khushal: Yes, you're right<br> <dael> smfr: Thought I saw issue on iframes. IS this proposed for that?<br> <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<br> <dael> smfr: When a replaced element has overflow b/c overflow:visible, ink or layout?<br> <dael> khushal: ink overflow<br> <dael> smfr: Different to overflow on normal element, irght?<br> <dael> khushal: Right. Had discussed for object overflow that overflow for replaced should be considered ink<br> <dael> smfr: I think b/c list of issues I'm not a big fan, but want to hear others<br> <astearns> ack florian<br> <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<br> <iank_> is it enough to support just overflow:clip & overflow:visible ?<br> <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.<br> <smfr> what about overflow-x & overflow-y?<br> <dael> khushal: It should say clip. Anything that defines scroll maps to clip for replaced elements<br> <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<br> <dael> khushal: later. All overflow:clip for replaced elements<br> <dael> astearns: So they only get clip and visible<br> <dael> khushal: Right. Either clipped or visible<br> <dael> astearns: q on IRC about overflow-x and -y. If we set -x are things visible in -y?<br> <dael> khushal: I think it's reasonable for overflow clip and visible to be different in x or y direction<br> <dael> khushal: I'm interp if you set overflow-x:clip and -y:visible it will clip in x and not y<br> <iank_> I think part of the question is if you do overflow-y: scroll for example<br> <dael> florian: Yeah, Id on't see why different for this<br> <dael> smfr: Yeah, sounds okay<br> <dael> astearns: Other questions or concerns?<br> <dael> iank_: I think part or a question that needs to be answers if you set overflow-y:scroll what happens<br> <chrishtr> q+<br> <dael> iank_: There's various fixup today<br> <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<br> <astearns> ack chrishtr<br> <dael> chrishtr: 3rd alternative could be ignore values other than visible and clip. Can set but don't do anything. Compute to visible<br> <dael> chrishtr: May be less confusing than apply some behavior but not all. It would clip but not scroll and might not know why<br> <dael> astearns: Use counter suggested for overfow:isible. If we want that need a use counter for all the other values on replaced elements<br> <dael> chrishtr: Then alternative is we could go with new css property to avoid the concerns. Does seem behaviors are similar to svg<br> <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<br> <dael> chrishtr: Good point. coerce hidden and scroll to visible then it's only sites with overflow clip<br> <dael> smfr: Isn't compat issue overflow:visible?<br> <dael> vmpstr: Right, it's the other side<br> <iank_> my bad sorry.<br> <dael> smfr: And object:fit would leak pixels<br> <dael> khushal: I think it's something like object:position that would leak<br> <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<br> <dael> khushal: right. If dev used overflow:visible and object-fit:cover they would get slipping now but overflow visible would start after this<br> <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<br> <dael> florian: Suggest to me we don't need to change style computation ass<br> <dael> s/ass/pass<br> <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<br> <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<br> <dael> florian: Need use counter. If it's a lot it's a deal breaker but if it's rare maybe not a problem<br> <dael> smfr: Do we know if reset stylesheets set overflow:visible<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to bring up Tab's point about content-edge vs padding-edge<br> <dael> iank_: I don't think it's common. Might be wrong<br> <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?<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/7188<br> <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<br> <heycam> wonder if it would be difficult to make the use counter check for overflow:visible only if there's ink overflow<br> <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<br> <dael> fantasai: Okay<br> <florian> that makes sense to me<br> <dael> astearns: [reads IRC from heycam]<br> <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<br> <dael> heycam: Just looking to see if can skip manual step to check influence<br> <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?<br> <dael> smfr: Need use counter data b/c would be compat. If use counter data is okay I'm okay with it<br> <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<br> <dael> chrishtr: So accept pending use counter?<br> <dael> astearns: Resolution is collect data and wait to resolve until it's anayzed<br> <dael> fantasai: With a bias toward accepting if use counter says it's okay<br> <dael> chrishtr: I think reasonable in my opinion to accept change and if use counter says otherwise we revert<br> <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<br> <dael> astearns: As far as accept change for now and revert I do like having spect ext as opposed to a summary<br> <dael> chrishtr: I would point out failure is showing more ink overflow which is not that bad<br> <dael> astearns: But could obscure content. Making things unreadbale that used to be readable is something we have to avoid<br> <smfr> q+<br> <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<br> <dael> florian: I think use counters are in engine so could get behind corporate firewalls, but wouldn't get offweb like epub.<br> <fantasai> s/overlay genera/overly-general selectors/<br> <dael> iank_: not necessarily. Depends on if org has opted into metrics collection. Orgs typically do opt out<br> <fantasai> s/image suddenly/img element suddenly/<br> <astearns> ack smfr<br> <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<br> <fantasai> +1 to iank, unlikely to find this problem on intranets if open web doesn't show the problem<br> <dael> smfr: I think might be first time we allow contents to overlap border. Makes me wonder if we spec the paint order<br> <dael> fantasai: Same as other elements<br> <dael> smfr: So paint on top of borders?<br> <dael> khushal: Was going to add sg allows overflow today and I think they draw on top of border<br> <dael> smfr: Okay<br> <dael> iank_: So replaced elements paint in content phase?<br> <dael> astearns: We have spec a content phase in painting?<br> <fantasai> CSS2 appendix Z<br> <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.<br> <fantasai> s/Z/E/<br> <fantasai> https://www.w3.org/TR/2011/REC-CSS2-20110607/zindex.html#q23.0<br> <fantasai> The painting order of border vs replaced content is already defined<br> <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?<br> <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<br> <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<br> <dael> astearns: So adding the path of using overflow on replaced elements in a draft<br> <dael> fantasai: Add and mark as tentative pending data with a link to the issue<br> <dael> astearns: Remove object overflow or put an issue on that?<br> <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<br> <dael> astearns: Obj to Add this path forward to the spec with a note linking back to this issue<br> <dael> RESOLVED: Add this path forward to the spec with a note linking back to this issue<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-1090933632 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 April 2022 23:48:56 UTC