New default `line-height` for paragraphs? Everything?

[frivoal]

https://github.com/mozdevs/cssremedy/blob/7a41665f3168a9719a404f9693a6caa30b2b502d/remedy.css#L56

line-height: normal is a bit tight, so I understand wanting to set it to something larger (like 1.5) for readability. At the same time, line-height: normal derives its size from information in the font file, but a number doesn't do that. Being dependent on the font sounds like a feature worth keeping to me. That makes me wonder if we should get a way to do something like font-size: calc(normal * 1.2);…

[jensimmons]

Does this work on today's web? Doesn't look like it. https://codepen.io/jensimmons/pen/BMdadx

Maybe this is something for the CSSWG to consider. But there's nothing to add to this project now, since there's no running code to write. Is there?

It's a good idea. Transfer this issue to http://github.com/w3c/csswg-drafts/issues/ ?

[jensimmons]

I wrote

p {
  line-height: 1.5; 
}

But should this be for everything (besides headlines)? How is the default working out most of the time?

[scottkellum]

My take is a designer should be opinionated about this value and almost always change it themselves. I would kinda like default behavior to inherit everywhere just to keep things consistent in the cascade.

This value depends so much on font size, width, line length, font family, etc it’s hard to define a single best value. Because all these variables change across screen sizes, fluid typesetting is necessary to get optimum results. There are a few techniques for fluid typesetting but (I say this even as an author of a technique) without a w3c standard for fluid typesetting it’s hard to add that to a set of defaults like this.

[jensimmons]

If I'm imagining things right, it sounds like you are arguing @scottkellum against doing something like * {line-height: 1.4} because that would screw up a developer's ability to easily create the line-height they want.

We could say p {line-height: 1.4}. It is easy enough for a developer to override, if they are in fact paying attention to typography. But maybe you are arguing, Scott, that we don't bother.

I've been working a lot recently in un-styled example code, and the default UA stylesheet creates such ugly, unreadable long-form content (by 2019 standards of type on the web). But perhaps there's no need to reset line-height, even just for paragraphs. I am thinking that way about font-family. Sure, the default is terrible. But why change it. Every project will set a font-family. If we do so, developers just have to override what we've done....

I might change my mind about font-family. Certainly a big part of the success of Bootstrap and company is the fact the default typography looks far better than UA styles. And people love having that shortcut. But this isn't a framework. This is a 'reset'.

As for fluid typography, I don't want to try and put such things in this project. I agree, there are a few different ways to do it, and even is disagreement about whether or not it's needed. We could make one set of choices, and just make it harder for everyone who wants to do something else.

[scottkellum]

* {
  line-height: inherit;
}
:root {
  line-height: 1.4;
}

Something like this would be where I might start. But I’m also curious as to how far you want these styles to go? I personally like to start with no styles, not even a reset. Or a reset/normalize might be a place to start as in I will modify it instead of overriding it later in the cascade. I’m probably not the target audience for this project but I’m finding it super interesting to follow. Lots of projects go far in styling things like Bootstrap and some are a lot more conservative. I’m curious where the line is with CSS Remedy.

[frivoal]

`* { line-height: inherit; }

line-height is inheretied, so there's no need to force it manually.

calc(normal * 1.2) Does this work on today's web?

No, that's what I meant. This may be something to propose.

---

The thing is, we're not looking for a good value for a particular web page (1.5 may be a good value), but for a good default value, which must then work everywhere. normal takes font metrics into account, so it does. 1.5 does not, and I think that makes it a poor default.

To take everybody's favorite degenerate case as an example, if your font is zapfino, 1.5 leads to collisions. normal doesn't.

So I agree with @scottkellum that designers ought to set a value that works well for their design. But when they have not, I think normal (or some future calc base multiplier of normal) is the only thing that works reliably always.

[scottkellum]

In normalizing form inputs I’ve set line height, font size, and font family to inherit because they don’t by default. But I guess forms are a whole different can of worms.

[sandren]

In print design, the leading of headlines is typically around 1.25, body copy around 1.5, and captions somewhere in between. Because web typography has matured so much, I think that if browser defaults were first being established today, they would likely adopt these principles.

So I feel that setting something like the following would be very much in line with the spirit of this project:

h1, h2, h3, h4, h5, h6 { line-height: 1.25; }

caption, figcaption, label, legend { line-height: 1.375; }

p { line-height: 1.5; }

[eallenOP]

I've been working a lot recently in un-styled example code, and the default UA stylesheet creates such ugly, unreadable long-form content (by 2019 standards of type on the web). But perhaps there's no need to reset line-height, even just for paragraphs. I am thinking that way about font-family. Sure, the default is terrible. But why change it. Every project will set a font-family. If we do so, developers just have to override what we've done....

I might change my mind about font-family. Certainly a big part of the success of Bootstrap and company is the fact the default typography looks far better than UA styles. And people love having that shortcut. But this isn't a framework. This is a 'reset'.

Interesting! Other comments in other issues (yes I've been lurking, sorry) specifically say this is not a reset. (Love this project by the way, whether it's a reset or not.)

Since I read this comment I have been trying to work out why UA styles have always defaulted to serif, and usually newspaper-style serif. MS Word gave that up in 2007.

Does this need a new issue?

[meyerweb]

In print design, the leading of headlines is typically around 1.25, body copy around 1.5, and captions somewhere in between. Because web typography has matured so much, I think that if browser defaults were first being established today, they would likely adopt these principles.

So I feel that setting something like the following would be very much in line with the spirit of this project:

h1, h2, h3, h4, h5, h6 { line-height: 1.25; }

caption, figcaption, label, legend { line-height: 1.375; }

p { line-height: 1.5; }

I like this approach. It’s rather like browsers setting different margins for various heading sizes, and the kind of thing I feel like a reference stylesheet for HTML5 would do if it were written today.

[frivoal]

I like changing the line height depending on what kind of elements we're talking about, but I don't like ignoring what's coming from the font files. If we could combine normal with a multiplier inside a calc() expression, that'd be great, but we cannot, so I'd be very concerned about introducing a fixed ratio by default.

Taller-than-typical fonts are not just about fantasy fonts like Zapfino and the like. Various languages have taller-than-english default fonts, and that is automatically accounted for when using line-height:normal. It wouldn't be if we hardcode it to a number.

For instance, look at this bit of Javanese. The black text has line-height:normal, the red one has line-height:1.25. This is not just a bit tight, we have actual glyph collisions between one line and the next. I don't think that's acceptable.

https://jsbin.com/mixicakite

If we still think different height on different elements is a good idea (I think it is), I think we should lobby for allowing normal with a multiplier inside a calc() expression.

[tylersticka]

The previous example is really interesting, and an issue I wasn't aware of before. I appreciate it!

I'll admit that I have some misgivings about calc(normal) being treated as a dependency for these readability improvements, but I'm having trouble articulating why.

[tigt]

Should the increased-readability line-height for <p> be applied at the root? There are a fair few elements that appear in long-form body text that would enjoy the inheritance:

• <ul>, <ol>, and their <li>s
• <dl>, <dt>, and <dd>
• <blockquote>
• <address> (especially with its recent redefinition)
• <aside>s used for notes and warnings, like on MDN
• <div>s, even if a conscientious developer would know a better element to use ;)

[frivoal]

I think it would be really regrettable if css-remedy chose (as is currently implemennted by PR #51) to prioritize slightly nicer typography for languages written in the Latin alphabet over working in all languages. Fixed line heights will break web pages.

In addition to the Javanese example from earlier, here's a new example in Persian using a nastaliq font: the text above the <hr> uses line-height: normal, the one below uses the same line-height values as css-remedy. I've colored the ::first-line to make collisions more obvious.

Let's keep the web worldwide.

[mirisuzanne]

@frivoal Are you suggesting that developers should never set explicit line-height, or that it should be considered carefully case-by-case? If we're talking about the latter: that's the entire goal of having some remedies (including this one) live in a separate reminders.css file. We imagined that file as a place for remedies that might be useful, but should not be universally applied.

That might not be a perfect solution, and I'd love to hear your thoughts - because I imagine this will come up regularly. How do we balance a default that is truly world-wide, with reminders to consider other issues carefully? If we do this right, I hope we can help people understand the choice they are making when they move from normal to 1.4. I've created #58 to discuss what other approaches we could take.

[frivoal]

I am suggesting it should be carefully set case by case, and for a default, normal is (currently) the only safe value.

I wish CSS was better at simultaneously being safe while giving good typography. There are efforts to fix that, but it hasn't happened yet.

CSS Remedy sets CSS properties or values to what they would be if the CSSWG were creating the CSS today, from scratch, and didn't have to worry about backwards compatibility.

That's not the same as trying to compensate for the problems CSS hasn't fixed yet.

I would generally stay away from remedies that can be useful to some, but can blow up and give broken layouts to others, especially when you need to do extensive testing in numerous languages / devices to even notice that something broke.

[jensimmons]

@frivoal Are you suggesting that developers should never set explicit line-height, or that it should be considered carefully case-by-case?

I think what's he's saying is that while normal is unsatisfying, it's the best we've got given the fact different scripts (languages) need different amounts of space. Setting a number (like 1.5) might be a great idea for most Latin-script typesetting, but it's going to be bad for other scripts.

If we had a time machine, maybe we could have constructed this differently. Perhaps the font files themselves could provide better info to make normal work better more of the time.... but, well, we can't change the past.

I would generally stay away from remedies that can be useful to some, but can blow up and give broken layouts to others, especially when you need to do extensive testing in numerous languages / devices to even notice that something broke.

I regret that this is true, but I agree. We can't just put line-height: 1.5; into Remedy.css, even though I want to (and did at first).

I see two options at this point.

A) Put things like line-height: 1.5; into reminders.css with a note that it's a good idea for certain scripts. ("If you are typesetting these languages.... we recommend this....")

B) Use :lang(language-code) selectors to write script-specific suggestions. Or is there a better selector? It's not really about the language. It's about the alphabet / the script.

For either option, I would prefer (once we have a complete project) that we don't basis things towards English / Latin-script languages. (By providing a lot of help for one script while ignoring others.) It'd be great to get a bunch of Japanese-specific suggestions in here. A lot of CJK suggestions. Etc.

The original web was biassed towards European languages, because colonialism. We can do better in 2019. We just have to put in the effort. Also, it'll be really cool. I'd love @frivoal if you could help by providing a lot of CSS for Japanese typography, for instance. @huijing maybe you can help with Chinese typesetting.... our suggestions could go into either remedy.css (on by default) or reminders.css (off by default). We could get some vertical typography in here (in reminders).