Re: CSS Rhythmic Sizing

[ Forwarding for the archives ]


-------- Forwarded Message --------
Subject:  Re: CSS Rhythmic Sizing
Date:  Mon, 08 Jan 2018 14:03:18 +0000
From:  Jan Nicklas <jan.nicklas@namics.com>
To:  fantasai <fantasai@inkedblade.net>


Hey fantasai

thank you so much for your fast response.
It's good to know that you are already working hard to address these requirements.

If I understand https://lists.w3.org/Archives/Public/www-style/2016May/0090.html correctly then this 
might be exactly what I would love to see in a future version of css.

Maybe you can take a look at the following examples and let me know if this would be handled by 
leading or a similar approach.
One of the most obvious cases is aligning an image and a headline:

s aligning an image and a headline

image-headline.jpg

The case is the same for aligning text to boxes

stage-helv.jpg


Example_1.jpg
Another example is aligning the visual line of headlines inside a box or a button:

TextInBox.jpg

Right now most frontend engineers adjust the margin or padding of the surrounding container to get 
this desired design however this leads to a padding of e.g. 17px for an actual distance of 20px.
Unfortunately this 17px value has to be adapted if the text font size is changed - may it be because 
of a smaller headline or a media-query controlled font size.
This leads to many many different paddings and margins with very strange values.
Mistakes can't be seen on first glance and a lot of hard to maintainable css is written.

The solution is quite easy - just move the visual line correction right to the headline as it allows 
us to keep consistent margins and paddings.
These margins and paddings values (e.g. 20px) would match the visual distance.

So for one project we tried exactly that using a sass mixin which calculated negativ margins 
depending on the font, the font-size and the line-height:

NegativeMargins.jpg

We were quire happy with that approach however we also ran into many collapsing margin issues and 
kept looking around for even better solutions.

Mark Dalgleish worked on something very similar. He moves the original bounding box (left) with 
translate-y a little bit to the bottom (right):

https://codepen.io/euveng/pen/zwPyJa

Basekick.jpg


SnapLineheight.jpg
He explains it here: https://github.com/markdalgleish/basekick#the-problem

/"The key offender when it comes to deviating from vertical rhythm is the difference in what 
'baseline' means in different disciplines. We only have what CSS gives us, which does not align with 
what is in the designers rule book./
/In the design world the baseline runs along the bottom of the lower case letters, not the bottom of 
the descender. There is no way to compute the height of a descender from CSS, let alone across 
different fonts."/

Unfortunately using transform translateY on every text element creates several issues too. E.g the 
additional z-layer which is created.

So I thought maybe a new CSS property could support us to build solutions without transform or 
vertical negative margins.
That lead to the idea of line-height-top and line-height-bottom.

But I really like your idea even more of letting the browser calculate the snap point instead of 
having many magic numbers all over the css.
Imho the goal would be to let the browser calculate the following bounding box:

em-square.png
This will allow creators to solve the following cases more efficiently and help a lot with design 
reviews:

final.jpg


final.jpg
The snap points would be the top and bottom of the cpaital M:


CSS_Rhythmic_Sizing.jpg


Would *leading: never* allow that?
Is there anything I can do to support this topic?


Thanks a lot for your time and many greetings
Jan

On Fri, 5 Jan 2018 at 21:55 fantasai <fantasai@inkedblade.net <mailto:fantasai@inkedblade.net>> wrote:

    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



-- 

Jan Nicklas.
Senior Frontend Engineer.


--

*E-Business. Seit 1995.****Namics.*


Namics AG, Bederstrasse 1, CH-8002 Zürich
Direkt +41 44 228 67 77
jan.nicklas@namics.com <mailto:jan.nicklas@namics.com>

@jantimon <https://twitter.com/jantimon>


namics.com 
<http://www.namics.com/?utm_source=Mailfooter&utm_medium=Mail&utm_term=&utm_content=Website&utm_campaign=Mailfooter>, 
blog.namics.com 
<http://blog.namics.com/?utm_source=Mailfooter&utm_medium=Mail&utm_term=&utm_content=Blog.Namics&utm_campaign=Mailfooter>, 
twitter.com/namics <http://twitter.com/namics>


--