Re: [css-step-sizing] Feedback on Proposal

Apologies for I missed this when posted, until Alan kindly pointed out this
to me.

I've copied to github issue[1]. I don't think I can work on this before
TPAC, but I would not want to loose tracking of this great feedback.

[1] https://github.com/w3c/csswg-drafts/issues/490

2016-05-10 15:31 GMT+09:00 fantasai <fantasai.lists@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
>
>