- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 May 2021 23:20:16 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `css-overflow] [css2?] Baseline of an inline-block with overflow:clip.`, and agreed to the following: * `RESOLVED: Specify option 1; match FF current behavior` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: css-overflow] [css2?] Baseline of an inline-block with overflow:clip.<br> <dael> Github: https://github.com/w3c/csswg-drafts/issues/6212<br> <dael> fantasai: 4 proposal in the issue afaict. 1) same as visiable even if baseline of clipped text<br> <dael> fantasai: 2. treat like overflow hidden and synth baseline regardless of what's inside<br> <dael> fantasai: 3. use whatever visible text is there. If clipped or below clipping point stop at clipping point<br> <dael> fantasai: 4 is same but instead of clamp to clipping area we clamp to border area b/c that's how hidden behaves<br> <dael> iank_: I think it's margin edge<br> <dael> iank_: Unique thing here is inline box us by default last baseline. Not like first for flex/grid. overflow:hidden if you didn't do end margin you'd get a funny box<br> <dael> iank_: Question is which. We treat like overflow hidden<br> <dael> iank_: [missed]<br> <fantasai> s/hidden/hidden, Firefox treats as visible/<br> <dael> iank_: Basically, chrome went way of overflow:hidden for that reason and adhereing to css 3. FF went for overflow:visible behavior. Merits to both. Slightly prefer ours a little b/c if you have a lot of content and overflow:clip you'd have things way off in linebox<br> <dael> fantasai: So long as there's visible content makes sense to align to that visible content. One of the intentions is to not trigger a bunch of layout. Line of content and extra room for floating stuff which you clipped. Want to keep alignment<br> <dael> fantasai: Clamp to padding edge might make sense b/c else aligning to something can't see. overflow:clip to clip anything outside, if there's content visible want to align to that<br> <dael> iank_: This is also somewhat an issue for last-baseline<br> <dael> fantasai: Also first-baseline<br> <dael> iank_: Yes, rare case, but yes<br> <dael> fantasai: Makes sense for last and first baseline to be consistent. First we want to align to first-baseline when it's visible<br> <dael> astearns: If we clamp to clip area or margin edge...if clip area doesn't that give you layout changes based on clipping?<br> <dael> fantasai: We wanted to avoid it but idea you're aligning to something invisible we also want to avoid. Which to avoid more? clamping to visible makes sense<br> <dael> astearns: Thinking of animated where revealing and aligning to what you can't see if waht you want<br> <dael> fantasai: But in that case usually won't get clipped. Usually overflowing content you want clipped or not overflow<br> <dael> fantasai: Dynamic visibility you probably don't want to reveal content overflow<br> <dael> astearns: So option 4 calc same as visible but clamp to margin edge?<br> <dael> fantasai: Yeah. Margin edge is a little weird. Border edge makes more sense. Had an issue about margin or border earlier. PDF raster and browsers are inconsistent.<br> <dael> fantasai: I would clamp to the clip edge which is padding edge<br> <dael> iank_: Any other opinions? I'm weak on my opinion<br> <dael> florian: A little opinion. If we manage to get behavior that's really author friendly let's do that. If we're kind of author friendly but not really it's not worth another slightly different variant. If we can land exactly what you want you don't have to debug but elsewise concerned about subtlties<br> <dael> iank_: Discovered on FF issue tracker thinking FF was wrong. One data point a webdev expected Chrome behavior. But that's only one data point<br> <dael> fantasai: Pretty strong first baseline we should align to if visible, even if clip. Makes sense for last to follow that logic. If and where we clamp is more debatable<br> <smfr> q+<br> <dael> iank_: Prefer not the clampping behavior. Just pick the baseline, even if not visible or pick an edge<br> <astearns> ack smfr<br> <dael> iank_: One thing is people see overflow:clip as a dropin for overflow:hidden. THere's a weak argumenet to align to overflow:hidder<br> <dael> smfr: Prefer a behavior such that baseline alignment is same as if inline block had clippath inset: 000<br> <dael> fantasai: That's FF?<br> <dael> smfr: That's clip to the box<br> <dael> iank_: Why?<br> <dael> smfr: In terms of layout and rendering I consider overflow:clip as similar to clippath. Doesn't have effects, but it's a clip where I don't expect layout implications<br> <dael> fantasai: Fine with that<br> <dael> Rossen_: I wanted to pull back on smfr comment and get clearer picture in terms of behavior he would see in the attached example from emilio. Would that be, smfr , closer to FF or chromium?<br> <dael> smfr: Didn't examine. People said it's more like FF<br> <dael> Rossen_: Which has layout implications<br> <dael> iank_: Which does not<br> <dael> Rossen_: I was on an older FF<br> <dael> astearns: Suggest we resolve to spec option 1, FF behavior, since we have people in favor and iank_ only with weak objection. See if we can take that to the bug reporter and see if it makes sense to them<br> <dael> astearns: Can also talk to PDF reactor about if clampling behavior is required or they could move to non-clamp<br> <dael> astearns: Prop: Specify option 1; match FF current behavior<br> <dael> astearns: Objections?<br> <dael> RESOLVED: Specify option 1; match FF current behavior<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6212#issuecomment-833109975 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 May 2021 23:20:24 UTC