Re: CSS Rhythmic Sizing

[Forwarding for the archives]


-------- Forwarded Message --------
Subject: Re: CSS Rhythmic Sizing
Date: Sat, 6 Jan 2018 00:25:05 +0330
From: fantasai
To: Jan Nicklas, Koji Ishii

On 01/05/2018 07:39 PM, Jan Nicklas wrote:
 > Hi Koji, hi Elika,
 >
 > I was considering to hand in a new CSS proposal but came across your idea which is similar to my 
idea.
 > For the last ten years I worked on several huge projects for different customers and one problem 
occurred over and over again.
 >
 > In our designs we tend to use a "visual border" of a text row to measure distances to the next 
box/image/text block.
 > This visual border is the top of the capital letter M and the bottom of the capital letter M. (M 
works for most fonts).
 > Designs with this methodology can be found almost everywhere on store fronts signs, tv-ads, 
newspapers, magazines, traffic
 > signs, etc.
 >
 > Unfortunately similar designs are really hard to achieve in todays browsers because of the way 
line-height is implemented.
 > Right now setting a line-height to e.g. 20px will reserve a box of 20px height and will 
vertically center the text inside it
 > (as long as it does not wrap).
 >
 > My idea is to split up line-height into 2 values: line-height-top and line-height-bottom (similar 
to overflow which was split
 > into overflow-x and overflow-y).
 > So it would still be possible to keep the current behaviour by just setting line-height:20px but 
it would also allow to have a
 > more granular control e.g. setting line-height-top: 5px and line-height-bottom: 15px
 >
 > Do you believe this an improvement worth to propose and would you like it to be added to your 
proposal or as a separate one?

Hi Jan!
I think your problem is trying to solve quite a different problem; I'm not
entirely sure what it is because I'm not seeing the connection between
paragraph 2 and paragraph 4. :) But here's a few things we're working on,
that might help:

   * A cap height unit is being introduced in css-values-4. This is
     effectively the height of the M--you can use it as a length
     unit the same way you can use em/rem/ch today.
       ED at https://drafts.csswg.org/css-values-4/#cap
       WD upcoming at https://www.w3.org/TR/css-values-4/ probably
       sometime later this month

   * Tightening the definitions of how inline boxes are laid out
     within a line so we have a consistent model across browsers for
     how to calculate the line height. (It will still vary due to
     available font metrics, but not due to varying interpretations
     of CSS2.1.) This will go into errata to CSS2.1 and into the
     css-inline module.

   * Adopting something like David Baron's line-box-contain property
     so that the height of the line and the position of the baseline
     within it can be enforced as a function of the first available
     font, and not of whatever other contents might appear on the line.
       http://www.w3.org/TR/2001/WD-css3-box-20010726/#the-line-box-contain
     This will turn up likely in the css-inline specification, but the
     design work on this feature is in the very early stages so I can't
     say for sure what it would look like or where/when it'll be in a
     CSS draft.

   * Adding controls for half-leading at the start/end of a block:
       https://lists.w3.org/Archives/Public/www-style/2016May/0090.html
     This isn't actively being worked on, but might be picked up, if it
     becomes important.

It's unlikely that we'll add the ability to control the offset of the
baseline explicitly, since the correct value for such a property would
vary depending on what fonts happen to be available. But we would like
to solve the ultimate goals of an author who would want such a feature--
which is typically to align things based on the metrics of the fonts
actually in use--we just want to make the browser do the relevant math!

Let me know if these proposal seem to be going in the direction of
solving your problem. Also if you can maybe explain better what you are
trying to do, I can try to respond with something more helpful. :)

~fantasai

Received on Tuesday, 23 October 2018 11:06:14 UTC