- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jul 2019 17:02:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Limits on text-underline-offset to preserve semantic meaning`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Limits on text-underline-offset to preserve semantic meaning<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4059<br> <dael> jensimmons: txt-underline-offset lets authors move up and down, speaking in latin. negative is up, positive is down, 0 is baseline.<br> <florian> q+<br> <dael> jensimmons: impl is in Safari and they clamped it to avoid turning underline into strikethrough. In Safari clamp was at any negative number and what happens is it disappears. Impl in FF behind a flag. When I've been looking at this last image is best. I think legitimate use cases to let it rise up. Do we want to have any kind of clamp? Maybe want to prevent use as strikethrough and have a mid-line clamp. Or we say no clamp, we'll trust authors.<br> <jensimmons> https://codepen.io/jensimmons/pen/wLrjGG?editors=1100<br> <dael> jensimmons: You can style strikethroughs, though you can't move upa nd down.<br> <dael> jensimmons: Codepen in irc if people want to look at this<br> <AmeliaBR> q+<br> <myles> q+<br> <Rossen_> ack florian<br> <dauwhe> q+<br> <dael> florian: I agree with jensimmons Use cases seem legit and I wouldn't want to block. If we want generous clamping or no clamp is different. All jensimmons cases have different color on underline. If it's same color could be different.<br> <dael> fantasai: We have a shorthand that lets you set both.<br> <bradk> +1 no clamping at all<br> <dael> Rossen_: Making properties depend on each other is not great.<br> <Rossen_> ack AmeliaBR<br> <fantasai> +1 to Rossen<br> <dael> AmeliaBR: I agree these are neat effects. Important to recognize different text decor have different semantic meanings. strikethrough is different then underline.<br> <bradk> Underlines are behind the text and strikethroughs are in front of the text right?<br> <jensimmons> AmeliaBR that's why I explained how strikethroughs can be styled.<br> <astearns> bradk: yes<br> <dael> AmeliaBR: Don't want to encourage wrong text decoration because one has a lot of flexibility in rendering and the other doesn't. There will always be rendering in less complete css impl. And the basic is on the a11y tree where it's this is an underline or a strikethrough<br> <dael> AmeliaBR: As far as outcomes for clamping, I don't nec. mean need to clamp<br> <jensimmons> bradk — yes. Underlines are behind. Strikethroughs are in front.<br> <bradk> Text decorations are not semantic<br> <dael> AmeliaBR: We want to encourage people to use correct text decor. If a visual effect is past the point where it really is an underline it shouldn't be represented by an underline. If the visual effect is a strikeout it should be using one. If facilities for a strikeout modification aren't as good as an underline might be a problem.<br> <dauwhe> q?<br> <dael> myles: Suggesting add same controls on strikethrough?<br> <dael> AmeliaBR: Might be nec.<br> <bkardell_> q+<br> <Rossen_> ack myles<br> <dael> myles: Thanks for all these examples jensimmons. I think you've shown where we draw the boundry is not the right place. It is important to distinguish between the 2. I think UA should be allowed to place limits. Perhaps ours are not best<br> <jensimmons> q+<br> <dael> myles: Would be bad if in one browser look struck through and other looks em. I would prefer a should try and distinguish between strike through text and underlined text. Once those limits are agreed can spec<br> <Rossen_> ack dauwhe<br> <dael> Rossen_: We're not hearing dauwhe<br> <Rossen_> ack dbaron<br> <dauwhe> q-<br> <Rossen_> dauwhe: can you perhaps summarize over IRC at least?<br> <dael> dbaron: I was on queue to suggest that given problems we may want text strikethrough offeset sooner. jensimmons said in introduction that 0 was relative to baseline rather than initial position. If going to add strike through and maybe overline offset might have different conclusions of 0<br> <bradk> +1 Offset overline and strike-though offsetting.<br> <dael> fantasai: 0 depends on text underline position porperty. It defaults to alphabetic-ish. If we get specific offset we snap to alphabetic offsel so you ahve something stable. If you chose a different position that becomes origin of offset<br> <dael> dbaron: Okay. Given concern...seems likely authors will use underlines for things not underlines if we give them more controls then strike through and overline. Esp strike through. I rec. it's a lot of properties but it's work thinking through.<br> <dael> myles: We've heard plenty of authors asking for underline control. I know of 0 for strike through and overline.<br> <bradk> Why not text-decoration-offset?<br> <bkardell_> q-<br> <jensimmons> q<br> <dael> Rossen_: Because they can do it with underline. Only partly kidding. We don't want to give something where they use underline all the time<br> <dael> dbaron: Poss want single property to move all<br> <dael> fantasai: I don't think so. If you have 2 or 3 might not want up by same amount<br> <astearns> I'm a bit worried about hacks to get around clamping - adding a blank line to the beginning, then giving an underline a large offset to move it to the next line below gets you back into the 'looks like strikethrough' case<br> <dael> dbaron: But 2 or 3 is rare so not clear worth another property<br> <fantasai> dbaron, text-undelrine-offset inherits<br> <fantasai> dbaron, so that you can set it once and forget about it<br> <Rossen_> adk jensimmons<br> <Rossen_> ack jensimmons<br> <fantasai> dbaron, so making it apply to all the lines wouldn't be very usable<br> <dael> jensimmons: I agree with dbaron we should think about strike through and overline to mitigate abuse of underlines. Maybe they haven't asked for but lots of things with typographic get lumped in one giant bucket.<br> <astearns> +1 to interop - I don't see a big need to allow UA inconsistency here<br> <fantasai> +1 to astearns and jensimmons<br> <bkardell_> q+<br> <dael> jensimmons: Also think we shoudl have interop. I don't want too lose for browsers because could be painful for authors. If in one browser underline looks great and an untested browser the underline disappears is dangerous. I think disappearing is bad. Maybe have it not move so if you say -10 it clamps and doesn't move.<br> <dael> jensimmons: I would be fine with a clamp if it's a magical mid-line. Maybe at x height?<br> <bradk> +1 to dbaron and jensimmons<br> <Rossen_> q?<br> <AmeliaBR> +100 to clamping (if it is used) being clamping the offset, not making the underline disappear<br> <dael> jensimmons: Some of the things in the issues like check for color contrast could get really complex and over engineered and hard to impl. I want to keep simple and make it possible to impl. I'm not a browser engineer maybe it's easy.<br> <dael> myles: One other point is if underlines can go arbitrarily far you might have to scroll down 5 pages to get the underline. So if you invalidate one piece of content you have to redraw whole page.<br> <dael> jensimmons: Makes sense to have a clamp to the line box.<br> <dael> dbaron: I think underlines are visual but not scrollable overflow<br> <dael> myles: Yes, but if page is 3 viewports tall might be at bottom<br> <dael> Rossen_: Yeah, I'm with dbaron .<br> <dbaron> s/visual/ink/<br> <dael> Rossen_: Are we considering underlines that are visually...missing th term but the ones that break underline when something else is around. Or is this jsut solid line segments<br> <Rossen_> q?<br> <dael> myles: Skipping in our impl only considers text the underline is on. It won't skip next line of paragraph<br> <Rossen_> Zakim, close queue<br> <Zakim> ok, Rossen_, the speaker queue is closed<br> <Rossen_> ack fantasai<br> <Rossen_> dauwhe, can you talk yet?<br> <dael> fantasai: I wanted to agree with jensimmons. Making argument about if underline should allowed to be ihgher because we thinks so, don't want that clamp. Reasonable distance of text clamp makes sense. Needs to be able to leak outside line box, but not by lots. Maybe text *1.5<br> <jensimmons> +1 for allowing past the line box — yeah, maybe can't be two lines boxes away or something<br> <dael> fantasai: I think jensimmons case of using central baseline is fine.<br> <jensimmons> right now, btw, Safari allows any distance down — will go very far. There's not a clamp yet<br> <dael> myles: For small text it's hard to get underline, like 5pm text, hard to get it in the linebox. Has to have case outside line box. Some general same clamping is important. Prob not where our impl does it today.<br> <dael> Rossen_: bkardell_ you're next<br> <dael> bkardell_: My questions are big so will ask in another forum<br> <dael> Rossen_: I don't think we'll resolve. Meta idea of if we want any kind of clamping.<br> <fantasai> myles, I'd use the greater of the line box boundary or slightly outside the descent (e.g. 0.25em past descent or 0.5em past descent)<br> <dael> Rossen_: I rememebr last time we discussed we resolved to continue work. Without specific number or formula can we resolve we want some kind of clamping for underline offset? THat way we know we have a direction and won't have half group say no clamping.<br> <tantek> could it be clamped to the linebox?<br> <dael> fantasai: I think need to decide if clamping to enforce underline-ness or if we're looking for reasonable distance of text<br> <fantasai> tantek, no, because line box can be smaller than the text<br> <dael> Rossen_: Both require clamping.<br> <tantek> to resolve the "underline down to page 5" problem<br> <fantasai> tantek, see my comment to myles above<br> <tantek> fantasai is there some box that contains the text?<br> <dael> Rossen_: In favor of continuing discussion. Can we resolve we want some clamping as part of underline offset either to enforce semantic meaning of underline or to keep it within visual distance<br> <dael> bkardell_: I heard different things talking about semantics. I don't know that someone can explain what they mean in a minute. the semantics seem wishy-washy<br> <florian> I want clamping for one, not the other, so I'm not sure what to do about a resolution to clamp for either...<br> <dael> fantasai: We all agree clamping withing reasonable distance of text is something UA can do<br> <dauwhe> https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-510145258<br> <dael> AmeliaBR: If we allow visual effects, we allow them. I don't see a reason to clamp in either direction.<br> <tantek> I'm (a little) worried about the effect on printing, e.g. do text decorations count as part of widows and orphans computations?<br> <astearns> box-shadow not clamping is a good argument against not clamping here<br> <dael> Rossen_: Let's continue that in the issue.<br> <bradk> -/+ 1em clamp<br> <dael> fantasai: Can we resolve on being able to clamp within range of text?<br> <dael> Rossen_: That's what I was pushing for.<br> <dbaron> I'd note *normal* underlines often extend outside the font's bounding box at the bottom<br> <bkardell_> I'm fine with that much<br> <dael> fantasai: Just resolving a clamp to keep line in reasonable range of the text<br> <tantek> would prefer more discussion before a resolution on this - that seems too wishy washy<br> <dbaron> (especially if they're wavy, etc.)<br> <dael> AmeliaBR: I have an objection. I don't see that as a strong argument. Paint can be all over page from box shadow.<br> <tantek> defer resolution please<br> <dael> jensimmons: It's after the hour, I think need to do another time.<br> <dael> Rossen_: We'll do that next week.<br> <dael> Rossen_: Thank you everyone, we'll continue next week.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-510145887 using your GitHub account
Received on Wednesday, 10 July 2019 17:02:50 UTC