- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Oct 2018 15:13:11 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Text decoration`. <details><summary>The full IRC log of that discussion</summary> <gregwhitworth> Topic: Text decoration<br> <Rossen> github: https://github.com/w3c/csswg-drafts/issues/3118<br> <gregwhitworth> myles: we have two properties<br> <gregwhitworth> myles: text-underline-offset and text-underline-position<br> <gregwhitworth> myles: reads out values for each<br> <gregwhitworth> myles: question is, both of these properties<br> <gregwhitworth> myles: the problem is only in horizontal WM<br> <gregwhitworth> myles: both of these describe the vertical position of the underline<br> <gregwhitworth> myles: the spec does describe some situations on how they play together<br> <gregwhitworth> myles: what happens if they collide?<br> <gregwhitworth> myles: there are two possible ways to solve this problem, is rules and also to join them into one property and avoid the bad issues at the syntax scenario<br> <gregwhitworth> myles: I prefer the latter as it's intentional and mechnaical<br> <gregwhitworth> fantasai: I guess, I'm not sure which one is the better option<br> <gregwhitworth> fantasai: the reason they were seperated was due to position may be dependant on the language where as the offset may be author messing with it<br> <gregwhitworth> fantasai: that means any time you want to make an adjustment you'd need to provide the offset change and which side the line is on<br> <gregwhitworth> fantasai: that is mostly important in vertical text where the line matters<br> <gregwhitworth> drott: I think we still need both values, even if you combine them<br> <gregwhitworth> drott: under auto | we still ahve to define rules when you combine them<br> <gregwhitworth> myles: thinking of them as one as a position and as offset isn't valuable because having an offset from auto isn't useful because every UA has a different auto<br> <gregwhitworth> myles: the pixel from the baseline to the underline is different<br> <gregwhitworth> myles: we're in agreement here<br> <gregwhitworth> myles: I do have a proposed sytax for this issue<br> <gregwhitworth> fantasai: in the case of the conflict, over and from-font there are three ways<br> <gregwhitworth> fantasai: treat from-font as 0, auto, or to take the distance from the alph baseline and compute that to a pixel<br> <gregwhitworth> myles: you metnioned three of them<br> <gregwhitworth> myles: two of them, pick a winter<br> <gregwhitworth> myles: third is typgographically bad - because it's defined to not be applied anywhere else<br> <gregwhitworth> fantasai: before we add another keyword<br> <gregwhitworth> fantasai: there are whole lot of complications with underlines<br> <gregwhitworth> fantasai: when you have inline elements that have different font sizes the position of the underline gets complicated<br> <gregwhitworth> fantasai: if they're aligned alphabetically you're at least setting them from the same offset<br> <gregwhitworth> fantasai: but if they're aligned along the central baseline you don't want the line crossing through the chars<br> <gregwhitworth> fantasai: if you use under, you need to go below the largest descender and those calculations aren't tightly defined in L3 and we need to think about it for L4<br> <gregwhitworth> fantasai: I want us to be thinking about it<br> <gregwhitworth> myles: are you referring to the decorator box<br> <gregwhitworth> fantasai: not sure which one is that, but you don't want to cross through text - the UA should be taking the descendants into account<br> <gregwhitworth> myles: ok<br> <gregwhitworth> fantasai: not sure where that brings us on this topic<br> <gregwhitworth> drott: can you sketch out your syntax proposal<br> <myles_> https://github.com/w3c/csswg-drafts/issues/3118#issuecomment-421827968<br> <gregwhitworth> myles: I can link to it<br> <gregwhitworth> fantasai: easiest for combining is auto from-font | length<br> <gregwhitworth> koji: how you set position of underline<br> <gregwhitworth> myles_: no opinion - defer to fantasai<br> <gregwhitworth> fantasai: the offset measure in the block axis, so it works fine for vertical text<br> <gregwhitworth> fantasai: if the line is on the ascender side it goes away from the alphabetical baseline based on the value<br> <gregwhitworth> drott: do we agree that the from-font should not be used for vertical text?<br> <gregwhitworth> fantasai: I don't see why not?<br> <gregwhitworth> drott: so we do want to use it as well?<br> <gregwhitworth> drott: the second point here is a bit inconsistent because we had from-font only for offset value and here it's for a base align<br> <fantasai> auto | from-font | [ under || [ left | right ] || <length> ]<br> <gregwhitworth> drott: here it's changing baseline left is equivelent to position before<br> <gregwhitworth> fantasai: actually I think there is something we can do<br> <gregwhitworth> fantasai: move font-font to the other<br> <gregwhitworth> myles_: so it will clobber the other<br> <gregwhitworth> myles_: would it be added?<br> <gregwhitworth> fantasai: from-font + a length?<br> <gregwhitworth> fantasai: you get the offset and then it's added to the length<br> <gregwhitworth> fantasai: I want it shifted down more<br> <gregwhitworth> myles_: so would auto mean 0?<br> <gregwhitworth> fantasai: auto currently means what the UA does?<br> <gregwhitworth> myles_: the property that takes the length<br> <gregwhitworth> fantasai: I'm not sure if the offset for left and right is 0<br> <gregwhitworth> fantasai: if the UA does not hide the metrics of top or bottom, left or right<br> <gregwhitworth> myles_: underlines are exactly on the bottom of the descenders<br> <gregwhitworth> koji: what about when the issue is on the baseline?<br> <gregwhitworth> fantasai: you're right we would have to do that<br> <gregwhitworth> fantasai: the underline might be 0, but the alphabetic baseline there would be an offset that is UA defined<br> <gregwhitworth> fantasai: auto means the UA gets to define what is appropriate<br> <gregwhitworth> myles_: You said they add<br> <gregwhitworth> fantasai: we can't have an offset of 0, it needs to be exactly on the baseline or the author has very little control<br> <gregwhitworth> fantasai: the offset needs to be absolute<br> <gregwhitworth> fantasai: underline position is something that folks will primarily use in CJK<br> <gregwhitworth> myles_: so if both are auto it will look good, but if you set it to 0 it jumps up<br> <gregwhitworth> fantasai: yes<br> <gregwhitworth> Rossen: so what do we resolve on<br> <myles_> auto | [ [ under | from-font] || [ left | right ] ]<br> <gregwhitworth> myles_: the grammar of text-underline-position turns into this^<br> <myles_> auto | <length><br> <gregwhitworth> myles_: the grammar of text-underline-offset is this^<br> <gregwhitworth> koji: yep<br> <gregwhitworth> fantasai: yeah I think that's right<br> <gregwhitworth> drott: and the behavior if the value is from-font and then a length with offset they are added?<br> <gregwhitworth> fantasai: yes<br> <gregwhitworth> myles_: so if position is auto or from-font then they add<br> <gregwhitworth> fantasai: no they always add, but it resolves to the alphabetic baseline<br> <gregwhitworth> Rossen: Any objections?<br> <fantasai> auto resolves to the alphabetic baseline if the offset is not auto<br> <gregwhitworth> Resolved: ^<br> <gregwhitworth> myles_: this is text-decoration-width<br> <mstange> scribenick: mstange<br> <gregwhitworth> myles_: shows presentation<br> <mstange> scribenick: gregwitworth<br> <mstange> scribenick: gregwhitworth<br> <gregwhitworth> myles_: we wanted to be consistent with other things, I propose text-decoration-thickness<br> <gregwhitworth> Resolved: text-decoration-width is now text-decoration-thickness<br> <fantasai> s/things,/things, but the purpose of consistency is easy of learning, and people are clearly confused, so/<br> <fantasai> dauwhe, you around? wondering if we should be looping back to some of the css-inline issues<br> <mstange> scribenick: mstange<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3118#issuecomment-432288810 using your GitHub account
Received on Tuesday, 23 October 2018 15:13:12 UTC