Re: [csswg-drafts] [css-rhythm-1] Avoiding accidental double spacing

The CSS Working Group just discussed Avoiding accidental double spacing.

<details><summary>The full IRC log of that discussion</summary>

```
<astearns> topic: Avoiding accidental double spacing
<astearns> github issue: https://github.com/w3c/csswg-drafts/issues/938
<astearns> github topic: https://github.com/w3c/csswg-drafts/issues/938
<rachelandrew> florian: this is about avoiding accidental double spacing, this might happen if an author sets line height step to 1.3 em, and the default font using line-height normal turns out bigger than 1.3 em
<rachelandrew> in another font the line-height might be calculated at double height
<rachelandrew> the previous proposal was to make the height deterministic
<rachelandrew> but koji pointed out that line-height normal is useful as it avoids overlap with long ascenders and descenders
<rachelandrew> florian: has a proposal for this
<rachelandrew> when you have something with a tall line-height you want it to be double, when it inherits this is a feature
<rachelandrew> when you set it, you never want to accidentally make the line-height step smaller than the natural line-eheight
<rachelandrew> soemtimes you want to do it on purpose
<rachelandrew> proposing to add a safe /unsafe keyword pair defaulting to safe
<rachelandrew> current behaviour is the unsafe one
<rachelandrew> dbaron: I understand but think it is a problem
<rachelandrew> the check is whether the line-height step is smaller than th eline-height and if so make the step bigger
<rachelandrew> the 2 pieces I am concerned about, 1 is that normal is a computed value of line-height
<rachelandrew> having that go back and influence line height step doesn't seem as if it will work
<rachelandrew> we do sometimes have font metrics influence computed values
<rachelandrew> florian: you need ot take th eline-height unit value as the lh unit depends on it
<rachelandrew> dbaron: so maybe that is ok, the other thing is that if you use text for more than one font we claim you end up creating a box of the size of the. line-height around both sets
<rachelandrew> creating a height that is larger than the line-height
<rachelandrew> fantasai: thats a general problem
<rachelandrew> dbaron: to the whiteboard
<rachelandrew> florian: does this change what line-height normal means
<fantasai>  dbaron draws a Chinese character and a Latin letter
<rachelandrew> dbaron: demonstrates lining up characters on the whiteboard
<fantasai> dbaron: suppose these come from different fonts
<fantasai> dbaron draws the ascent and descent on the chinese character
<fantasai> dbaron then draws the ascent and descent on the Latin letter, which is a little bit lower
<rachelandrew> florian: which is the primary font and which is the fallback
<rachelandrew> dbaron: it shouldn't matter as per the spec
<rachelandrew> fantasai: I think there is a conflict in the spec
<rachelandrew> dbaron: the number line-height is 1.26 font size 16px, so we want a 20 pixel box round each of these
<rachelandrew> dbaron demonstrates where the line-height boxes are around the two characters
<fantasai> (dbaron is using a numeric line height in place of normal, because normal could result in varying line heights; didn't want to deal with the complexity yet)
<rachelandrew> dbaron: end up with a line box height bigger than the line-height
<fantasai> dbaron notes that because the ascent plus descent plus half-leading of each adds up to 20px, but they are offset by 1px, the total line height is 21px
<fantasai> fantasai says the CSS2.1 spec says two contradictory things, one of which is that
<rachelandrew> florian: in this case if you started with a line-height step of 30 pixels you wouldn't get double spacing
<rachelandrew> dbaron: the designer might have fonts that have the same box and others have different boxes and get the double spacing
<fantasai> https://github.com/w3c/csswg-drafts/issues/391
<rachelandrew> florian: for it to fail that way you need multiple fonts falling back to each other
<rachelandrew> fantasai: I think this point is really important, it is a critical flaw in how it works
<rachelandrew> when you have boxes of the same height, the CSS2.1 spec says 2 different thinks
<rachelandrew> you get that result and also get 20 pixels out of that
<rachelandrew> so we need to fix that
<rachelandrew> in order for line-height-step to be at all robust and not flaky we need to fix it
<rachelandrew> myles: Gecko and spec agree with dbaron's example, WebKit would calculate the height and add spacing to either side to make it equal
<fantasai> (The spec says two contradictory things, and supports both Gecko and WebKit's interpretations depending on which sentence you read in the paragraph describing this)
<dbaron> I don't think that's actually what Gecko does
<dbaron> dbaron: oh, yeah, that is what the spec says -- add the half-leading after unioning the character heights
<rachelandrew> astearn: this is one crucial instance, but initially you were talking about making step sizing in the safe mode that would increase itself if it encountered a large line-height
<rachelandrew> florian: where you have set your step size accidentally smaller than the computed value of line-height
<rachelandrew> fantasai: can we resolve on fixing this?
<fantasai> https://github.com/w3c/csswg-drafts/issues/391
<rachelandrew> koji: how do you compute line-height normal to pixels
<rachelandrew> <general disagreement about the spec>
<rachelandrew> dbaron: it's more like a number than any other kind of value but it does a thing based on the font
<rachelandrew> myles_: it is based on the default font
<dbaron> Here's the thing I drew on the whiteboard: https://lists.w3.org/Archives/Public/www-archive/2017Apr/att-0006/IMG_20170420_102101.jpg
<dbaron> (although as myles__ pointed out, I was wrong)
<astearns> the point I wanted to make that you use step sizing to create vertical rhythm. Creating a 'safe' version that avoids double spacing and breaks the rhythm is counterproductive
<rachelandrew> florian: is there a definition for the used value of line-height, if you have normal and know the font
<rachelandrew> fantasai: at computed time the lh unit needs to map to an actual value
<dbaron> dbaron: I think you get it from the first available font
<rachelandrew> florian: the value of the line-height property does it change based on content on the line?
<rachelandrew> does that property vary per line?
<rachelandrew> myles_: no properties do not vary per line
<rachelandrew> florian: you can't change the primary font per line
<rachelandrew> dbaron: I think florian is talking about multiple lines splitting the same element
<rachelandrew> the computed value of line-height normal is normal
<rachelandrew> so if you are asking what lh does, when you have line-height normal use the first available font in the font list
<rachelandrew> florian: not only is the value normal, but the value of line-height 1.2 is 1.2
<rachelandrew> dbaron: let's file a spec issue
<rachelandrew> florian: what makes this impossible
<rachelandrew> dbaron: spec needs to say how to compute to an abs length, probably using the primary font
<rachelandrew> florian: do you need to do layout to figure out the pixel value of line-height?
<rachelandrew> dbaron: for the lh unit or for layout?
<rachelandrew> florian: not talking about the line box
<rachelandrew> what does the UA pick the number based on?
<rachelandrew> fantasai: I think you assume this gets computed by a number and used as that number for layout calcs, used as a length to figure out the leading
<rachelandrew> that conversion happens per font in the text
<rachelandrew> myles_: webkit does this
<rachelandrew> fantasai: if you don't have a value for the entire run, how can you work out the line-height for a single value
<dbaron> ok, filed https://github.com/w3c/csswg-drafts/issues/1253 on css-values-4
<rachelandrew> myles_: (answering q) we do a bunch of stuff for the width then we calculate heights and place vertically
<rachelandrew> fantasai: for each char you find ascent and descent, get a value, if it is not the line-height increase or decrease on both sides to get the line-height
<rachelandrew> dbaron: do you then use the normal?
<rachelandrew> dbaron: use line-height normal, a single element on the line, font fallback is happening in the line, fonts have different etrics for line-height normal and ascent and descent
<rachelandrew> ... you take the ascent and descent, where do you get the number for normal
<rachelandrew> myles_: we don't
<rachelandrew> dbaron: Gecko includes the external leading
<rachelandrew> florian: how is this not a violation of 2.1?
<rachelandrew> koji: this sentence contradicts other parts of the spec
<rachelandrew> dbaron: that sentence was written in the olden days
<fantasai> s/we don't/we don't; we take that value with no extra leading/
<rachelandrew> dbaron: it assumes defaulting to what the font says
<dbaron> https://drafts.csswg.org/css2/visudet.html#inline-non-replaced
<rachelandrew> koji: describes content box height
<rachelandrew> fantasai: the content box height has no effect on layout
<rachelandrew> dbaron: it matters re leading around it
<rachelandrew> fantasai: but this section is not related to line-height normal
<rachelandrew> dbaron: it can change the size of things, because the leading changes the content height, the middle of where the content height is does matter to layout
<rachelandrew> astearn: we're not really addressing the rhythm issue here, though we found bugs in other specs
<rachelandrew> florian: do we have an issue to define the line-height unit based on primary font
<rachelandrew> dbaron: pasted such an issue earlier
<rachelandrew> florian: the issue I proposed is to define the same way
<rachelandrew> koji: this is based on font metrics of the primary font in safe mode
<rachelandrew> florian: when it inherits, is specified. It doesn't depend on the font
<rachelandrew> astearns: you set your vertical rhythm for body text but the heading is bigger what happens
<rachelandrew> florian: the line step height will double to keep the rhythm
<rachelandrew> gets the unsafe value from the pixel
<rachelandrew> not magic, doing this based on a keyword, unsafe is current behaviour. safe will cause the bigger line-height behaviour
<rachelandrew> koji: does this change based on inheriting?
<rachelandrew> florian: no magic with inheriting
<dbaron> ok, filed https://github.com/w3c/csswg-drafts/issues/1254 on line-height:normal definition in CSS 2.1
<rachelandrew> florian: how well this works depends on how we fix 2.1, it doesn't make things worse
<rachelandrew> koji: I don't see it saves much, maybe some cases people think it is better
<rachelandrew> fantasai: keyword on line height setp to us line-height
<rachelandrew> astearns: that would make double spacing more likely
<rachelandrew> florian: you don't want to be exactly the line-height, needs to be just a bit more
<rachelandrew> astearns: step sizing could be a percentage of line-height
<rachelandrew> florian: either line-height is a number and works, or it isn't
<rachelandrew> if you want to set your step smaller than the line-height, set it explicitly with unsafe then it will not get adjusted up
<dbaron> Koji: on web, due to small screen real estate, people set grid to fraction (half) of the desired line height
<dbaron> astearns: that happens in print as well
<rachelandrew> koji: I understand some cases it helps, given complexity vs benefit
<rachelandrew> florian: it is very frustrating when people won't use a browser if it breaks, the outcome of not dealing with this could cause problems with different sized fonts, in one browser double heights might happen based on default sizing
<rachelandrew> fantasai: having a layout system that breaks badly when fonts get substtuted is bad
<rachelandrew> double spacing is bad
<rachelandrew> dbaron: authors should not have to write a number in their CSS that has to be right based on the font the user has
<rachelandrew> florian: the feature currently requires users pick a value
<rachelandrew> dbaron: the dev currently has to write line-height 3 or 20 pixels, Chrome might switch to double spacing based on one value, Firefox might pick another value, a subtle difference means you get double spacing in one browser and not another
<rachelandrew> dbaron: Gecko has had to reduce line-height they compute for webcompat issues
<rachelandrew> fantasai: we don't want more of these situations
<rachelandrew> astearns: should we come up with a way of making step sizing safer, we haven't come up with a resolution on that
```
</details>


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

Received on Thursday, 20 April 2017 01:55:28 UTC