New line-height control: user interface shortcomings and inaccurate preview

[afercia]

Describe the bug

Splitting this out from #20775 (comment)

The new line-height control that is going to be introduced in WordPress 5.5 offers room for improvements, both in terms of usability of the user interface and in the accuracy of the line-height preview in the editor.

In its current state I'd define this new feature unpolished and unfinished. Not my intent to dismiss the work done here but it really feels like an incomplete, bit rushed, new feature that is going to be released a bit too early. In my opinion, it would need a few tweaks before it's really "ready" to be offered to users.

User interface shortcomings

1. Some themes use a default line-height with several decimal values. For example, Twenty Twenty uses 1.476 for the content paragraphs. The line-height control UI doesn't allow to set this value other than manually. The 0.1 step value for the number input type doesn't seem appropriate. I wonder whether a number input is appropriate in the first place but I can't think of of a better control off the top of my head.
2. There's no clear way to reset a custom line-height value. The Backspace key works but that's hardly discoverable. At the very least, there should be a "Reset" button like for other custom values inputs.
3. The placeholder value of 1.5 is highly confusing. At first sight, it seems the default value, while the actual value from the theme may be completely different. Not sure there's a reason to display the placeholder in the first place and I'd tend to think it should be removed. Noting that the font-size custom value doesn't use a placeholder, for good reasons.
4. Additionally, some browsers (at least macOS Chrome) honor the decimal separator setting set in the operating system. For me, the decimal separator is the comma. However, the placeholder value uses a hardcoded 1.5 with a dot. As a result:

• I see an initial value of 1.5

• as soon as I use the number input arrows to change the value, the decimal separator changes to a comma:

This is highly confusing and one more reason to remove the placeholder. 4. The `max-width: 60px;` on the number input seems an arbitrary value to me and definitely too small for values with several decimals.

Implementation considerations

1. At the very least, the line-height control should be paired with the font-size control and provide preset values in addition to the custom one. This would also encourage to use the preset values (CSS classes) instead of a custom value (inline style).
2. A line-height value makes truly sense only in relationship with the font-size is used for. Only themes are ultimately responsible for the content font-size.
3. When themes provide support for editor-font-sizes the should be required to pair a set of line-height values for each present font-size. Only this way, the line-height value makes sense because it's crafted on a specific font-size value. This would help consistency in the design and mitigate the "HTML soup" problem. Users can always set a custom value if they'r enot satisfied with the presets one.
4. When themes do not provide support for editor-font-sizes, the block editor should provide sets of preset line-height values for each defaults in the fontSizes array. Again, only this way line-height values can be well-crafted in relationships to the actual font-size value.

Inaccurate preview in the editor

This is actually very clear with Twenty Twenty and it's also related to some recent changes to the editor-styles-wrapper styles. I think (not 100% sure) they come from #21428

Regardless, as said above Twenty Twenty uses a line-height of 1.476 for the content paragraphs. Screenshot from the front end:

Twenty Twenty CSS related values for large screens:

html font-size:         62.5%   --> 10px
enty-content font-size: 2.1rem  --> 21px
paragraph font-size:    inherit --> 21px
paragraph line-height:  1.476   --> 30.996px

This is the preview in the block editor: the line height is clearly taller:

While Twenty Twenty correctly sets the editor style so that the paragraph line-height value is inherit:

.editor-styles-wrapper p {
    font-size: inherit;
    line-height: inherit;
	...

In the context of the editor, the inherited value comes from the editor CSS:

.editor-styles-wrapper {
    line-height: 1.8;
	...

Thus, the computed line-height value is 37.8px instead of 30.996px.

While it appears themes can set a line-height for the editor-styles-wrapper, it seems to me it won't have effect because of the order of the styles, unless themes use !important. So to recap:

• it appears not all the editor-styles-wrapper styles can be overridden because of the styles order, unless by using !important
• I'm not sure why the editor CSS sets 1.8 as line-height to start with. Seems an arbitrary value to me also considering the default font-size is 16px:
  • $editor-font-size: 16px;
  • $editor-line-height: 1.8;
  • which produces a computed value of 28.8px
  • it would be nice to have computed values without decimals
• regardless, styles provided by the editor for the content preview should be easily overridable: for me, the default styles come after in the source so it prevails over the style provided by the theme

Certainly Twenty Twenty could improve a bit its editor styles but the styles order seems a problem that should be fixed.