- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Mar 2019 17:01:39 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `#3749`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: #3749<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3749<br> <dael> dbaron: Isn't this talking about value for GCS which is another term?<br> <dael> florian: Resolved value, you're right<br> <dael> florian: This is raised by chromium b/c cssom spec says resolved value is used value and they were trying to find a way to return number of pixels but line-height:normal doesn't resolve into a single height<br> <AmeliaBR> s/#3749/The resolved value of "line-height"/<br> <dael> florian: line-height has 2 sets of values. All values other than normal resolve to a single height, normal resolves in different value per text run. You ask for gCS for element, not for text run so we can't retunr<br> <dael> dbaron: Chromium returns normal as a keyword?<br> <dael> florian: Yes<br> <dael> nigel: Reviewed this and was confused by spec with resolved value b/c line-height just takes you to css2 line ehight and doesn't way what resolved value is for line-height. Doens't seem spec says what it should be<br> <dael> florian: Kind of does depending on how you read it. For line-height it's in the sublist where it says resolved value is used value. It's unclear for line-height:normal that can be returned<br> <dael> nigel: I think you're expalining how to read the sublists. THat prob needs reformatting. Thank you<br> <dael> florian: line-height:normal can only be preserved as normal if we want something meaningful<br> <dael> nigel: You want to move line-height to computed value category?<br> <dael> florian: Not necessarily. There is another subgrouping of values for line-height: length and % are turned into absolute values at computed but numbers are numbers and computed. At used numbers become lengths. Do same thing but inherit differently<br> <dael> florian: Normal, regardless of computed or used time can't become a single number.<br> <dael> AmeliaBR: Are you asking us to say normal exists at used value time or are you asking to create a special cat to figure out resolve value for line-height being normal if computed value is normal?<br> <dael> florian: I think difference between those 2 is editorial b/c used can't be observed unless we say gCS returns it. In terms of what' observable it's same. I don't care how we phrase, just don't turn normal into a number<br> <dael> nigel: Happy to have a unitless number for line-height converted to a used value?<br> <dael> florian: Unitless stay as unitless at computed. At used value I suppose it's cat. that way b/c web compat requires it. That's usually why prop whose resolved is mapped to used value instead of computed mapping. I'm not trying to change values other than normal, want to avoid normal being cast to a length when it can't be<br> <dael> florian: Who is CSSOM editor?<br> <dael> florian: Emilio<br> <dael> Rossen_: Right<br> <dael> Rossen_: You can make a PR and emilio can merge<br> <dael> florian: Happy with a resolution we keep normal and work with emilio on phrasing<br> <dael> nigel: You talked about what is returned when it's normal. Do we have data on UAs for unitless numbers?<br> <dael> florian: I have not looked. I assumed spec wasn't wrong, but can look separately.<br> <dael> AmeliaBR: Working on a test case. Chrome does what florian is asking for<br> <dael> myles: We're talking about return on gCS?<br> <dael> florian: Yes<br> <dael> myles: That's scary, line-height has been around forever<br> <dael> florian: Changing spec to match chrome<br> <dael> myles: FF and webkit return pixel value<br> <dael> florian: Can you define what value you return?<br> <dael> myles: THis issue has a snippit of code that desc how we compute<br> <dael> florian: [looks at it]<br> <dael> florian: I'm not terrified about web compat given chrome does it already<br> <AmeliaBR> Test case: https://codepen.io/AmeliaBR/pen/bZmgqJ?editors=1011<br> <dael> myles: otoh FF and webkit don't return keyword<br> <dael> florian: You think this is kind of code websites could have specialized on to deal with browser difference?<br> <dael> Rossen_: I think the assertion made was line-ehight has been there forever and many sites depend on it. Predicting what will be broken or not is difficult. I agree Chrome market shre prob dictates some behavior on desktop, but not sure on mobile<br> <dael> florian: I wouldn't say chrome dictates behavior, but chrome doing it this way is strong evidence that doing it this was doesn't break the web<br> <dael> florian: And length value you would return doens't match layout so why return that?<br> <dael> fantasai: Also computed value is the normal keyword. We use used value where there's a compat reason to do so<br> <dael> myles: I won't object but we wouldn't be able to make this change w/o more research into how this would break<br> <dael> Rossen_: Can always defer to next week if you want to get some time and come back to use myles<br> <dael> florian: I guess...the question is what's alternative? Spec being wrong is bad. Chrome returning a length that's unrelated to actually used length seems weird<br> <dael> AmeliaBR: Is it really wrong? It's based on font of element. THe text spans inside might have different fonts but doesn't the parent element have a line height even if it's not used for anything?<br> <dael> florian: From the code snippit I don't know which font metrics we're talking about<br> <dael> myles: Primary<br> <dael> florian: Which metric of that font?<br> <dael> myles: Ascent+descent+line gap<br> <fantasai> AmeliaBR, the line height for normal is calculated per fragment, not per element<br> <dael> florian: I'm not good enough at fonts to phase this, but I believe in the past we discussed there isn't a single ascent or descent and the one we use aren't always the same<br> <dael> myles: FOr a particular font there are different values, but every browser picks one and uses it throughout. At least for the browsers I know<br> <dael> florian: You return line height of the strut?<br> <dael> florian: strut is the css2.1 term for the thing that keeps the line height fromcollaping to 0<br> <dael> myles: Sounds right to me<br> <dael> fantasai: line height used is calc per fragment of element so it's not nec the line height from first avail font. Can also include fallback<br> <dael> myles: Correct, also includes things like child elements<br> <dael> fantasai: THat's about height on line-box. THere's difference between line-box and fragment we're looking at. For an element when calc line-height which is what's used when calc height of linebox in most cases it's definite nmber, but varies by fragment with normal<br> <dael> fantasai: THe position of that length on the line is used in combination with other elements on the line to get the line box. We're trying to calc the line-height value that factors into line box calc and that varies by fragment if you have normal. You can't get that answer w/o doing layout<br> <dael> florian: I guess this boils down to that number from webkit isn't entirely meaningless, but if we're saying this is the used value it actually isn't<br> <dael> fantasai: Example: have line-height:normal and all text is using second font in list that's what would set the line height, but you'd returnt he first font. Given the intention of gCS is reach the computed value and we don't have a web compat reason to not it seems to me returning normal makes a lot of sense.<br> <dbaron> I think there's value in allowing the discussion to proceed a little further in the issue before bringing it to the call; might be more likely to take less than 20 minutes.<br> <dael> Rossen_: We're at the top of the hour. I don't want to force a resolution. What's captured is compelling enough for WK and FF team to noodle on this for a week and we'll put it in next week's agenda.<br> <dael> florian: Sounds reasonable.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3749#issuecomment-474932155 using your GitHub account
Received on Wednesday, 20 March 2019 17:01:46 UTC