W3C home > Mailing lists > Public > www-style@w3.org > May 2016

[css-step-sizing] Feedback on Proposal

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 9 May 2016 23:31:44 -0700
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <57318050.6070100@inkedblade.net>
So.... Overall I think using a step-sizing function to solve many
of these line-grid alignment issues is a useful and good approach.
However, I am not so convinced that the approach in the spec is
quite the right way to do it.

In particular, talking with Dave Cramer, it seems that having a
height-affecting step sizing function is important, since in many
cases baseline alignment within a differently-sized typeset block
is not what is important, but resuming the grid after the block
is important.

So it would need a block-size-step property as well. The goal is
that the margin-box size of the element is an integer multiple of
the step size. Within the box, if it is using a different font
size, it is better for the leading to be optimized for readability
within the block.

   For example, within a blockquote that has a slightly smaller
   font size, the leading should stay proportional to the font.

   For another example, a heading often needs plenty of margin
   to be set apart from the surrounding text. But if it wraps onto
   multiple lines, these should be set tightly because the type
   size is so big.

The proposal in the css-step-sizing spec does not handle this ;
but a block equivalent of its inline-size-step feature would be
able to do this.

The the other concern is that there are a number of parameters
that are needed for rounding to the nearest step:

   * What is the the step size? (included in proposal)
   * Is the extra space added to the padding or the margin? (missing)
   * Is the extra space added to the top/bottom/both? (missing)
   * Are we rounding up or down or the nearest size?

Possibly some of these can be deferred to the next level when we
get to the implementation stage. However, we should design the
feature to work with all of these together. Which means designing
all of these right now (marking the ones that are not critical
at-risk) so that we make sure we have a plan for adding them in
the future, and our design right now can be extended appropriately.

So, e.g. defining all four properties as:
   inline/block-adjust-step:   <length>
   inline/block-adjust-align:  center | start | end
   inline/block-adjust-insert: margin | padding
   inline/block-adjust-round:  up | down | nearest
with shorthand
   inline/block-adjust: <step> || <align> || <insert> || <round>

We can mark align/insert/round at-risk, and only allow <step>
values in the shorthand; but this way we know we have designed
the feature to solve the full problem.

-----------------------------------------------------------------

Related to this, to make these things work easily, we should add
line-height units, so I support the proposal to add

   lh - unit equivalent to computed 'line-height';
   rlh - unit equivalent to root 'line-height'

to Values and Units 4.

~fantasai
Received on Tuesday, 10 May 2016 06:34:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:03 UTC