Re: [csswg-drafts] [css-text-decor] text-decoration level 4 clarification on text-underline-offset positive/negative lengths (#4021)

The CSS Working Group just discussed `text-decoration level 4 clarification on text-underline-offset positive/negative lengths`, and agreed to the following:

* `RESOLVED: Update the spec so positive offsets are outward from the text`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: text-decoration level 4 clarification on text-underline-offset positive/negative lengths<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4021<br>
&lt;dael> dbaron: The commentor is a Mozilla intern implementing<br>
&lt;dael> Rossen_: Can you represent?<br>
&lt;dael> dbaron: Maybe emilio<br>
&lt;dael> fantasai: There's a text-underline-offset prop that takes a leg to adjust underline position. Postive is inward and negative is out. Negative goes down on an underline. Safari impl opposite.<br>
&lt;dael> fantasai: Does something different.<br>
&lt;dael> fantasai: Prop is positive values move outwards. Down for horz text<br>
&lt;dael> fantasai: Seems fine to me. I don't understand what Safari is doing<br>
&lt;dael> dbaron: Sounds like which direction things move it.<br>
&lt;dael> dbaron: Apparently Safari treats negative as 0<br>
&lt;dael> fantasai: Okay<br>
&lt;dael> fantasai: I don't have a strong opinion. I'm fine if positive moves outward<br>
&lt;dael> AmeliaBR: As someone with no experience I'd expect positive and negative to map up/down consistent between under and overline. Or I'd expect positive to be father from text.  Large values meaning closer to text for over and under seems weird<br>
&lt;florian> agree with AmeliaBR<br>
&lt;dael> myles: Couple things. First I want to say when I impl this was an oversight not trying to twart spec. We have a clamp b/c worried about content spec underline and do offset that looks like strikethrough but a browser without it looks like underline and that changes meaning. We did it can't be closer than baseline.<br>
&lt;dael> myles: Wanted to do other direction too but never got around to impl that<br>
&lt;dael> myles: AS far as positive and negative directions I believe they're just flipped. That's and oversight, I'm sorry. Happy to switch. But the person opened the issue said match Safari. I don't have a preference here<br>
&lt;fantasai> myles, given Amelia's logic, I think it might have been a good thing you misinterpreted the spec :)<br>
&lt;dael> jensimmons: On question on if positive moves away from text rather than closer with margin and padding there's a cowpath in author minds where if there's a border and you add postive it moves away and negative is closer.<br>
&lt;dael> jensimmons: Instinct is Safari way makes more sense to author minds<br>
&lt;dael> fantasai: prop: Change the spec. I think there has been good arguments.<br>
&lt;dael> fantasai: Arguments against changing to match Safari?<br>
&lt;dael> Rossen_: None against. Is what myles desc for clamping in spec? That is good behavior to me and maybe to spec. That values can't go beyond baseline in negative direction? Maybe something like baseline+ascent in positive?<br>
&lt;dael> Rossen_: Prevents underlines being used as strikethrough<br>
&lt;dael> fantasai: Seperate issue so let's address separately. Good point, let's close this.<br>
&lt;AmeliaBR> Agree these are separate issues. But +1 for a second resolution to support clamping the used values to avoid under/overline looking like strikethrough<br>
&lt;dael> fantasai: Prop is update the spec fo positive offsets are outward from the text<br>
&lt;dael> Rossen_: sgtm<br>
&lt;dael> Rossen_: Obj?<br>
&lt;AmeliaBR> s/fo/so/<br>
&lt;dael> RESOLVED: Update the spec so positive offsets are outward from the text<br>
&lt;jensimmons> Thanks myles for "doing it backwards" so this would come up and we could make it better!<br>
&lt;dael> fantasai: Thanks to myles for making a mistake, we have abetter spec<br>
&lt;dael> fantasai: Second, I understand logic for having clamping. Happy to add spec text, but need to think about reasonable limits. ascent on upper is too high.<br>
&lt;dael> Rossen_: Yep. Let's open as sep issue and figure out limits<br>
&lt;dael> myles: You want me to open?<br>
&lt;dael> Rossen_: Please<br>
&lt;dael> Rossen_: Anything else on this?<br>
&lt;dael> jensimmons: Preventing using it as a strikethrough I'd love to see clear interop and clear spec. That's exactly what authors will try and do and if they're able in one and get annoyed if they can't in another. I vote interop on that whatever it is.<br>
&lt;dael> myles: I'm interested in this. You think there should be interop in all browser try and prevent or don't? Or in specific algo for limits?<br>
&lt;dael> jensimmons: Need to think more about what diff in limits might be. If it's minor and technical I think doesn't matter. If you can have a cool background for some text with underline in one browser or not another that's a problem.<br>
&lt;dael> Rossen_: I think there's consensus we want interop. Let's take this coversation to the new issue and let's get to something that can be impl by all<br>
&lt;dael> fantasai: Want to point out jensimmons comments made me think it's worth nothing underline is under text not on top. Won't be same as strike through.<br>
&lt;dael> Rossen_: If same color it will be<br>
&lt;dael> fantasai: Could be reasons you want a thick baseline that you shift up.<br>
&lt;fantasai> s/baseline/underline/<br>
&lt;dael> Rossen_: This is why we need a new issue. This is not a 4 minute discussion<br>
&lt;fantasai> s/nothing/noting/<br>
</details>


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

Received on Wednesday, 26 June 2019 16:40:10 UTC