- From: Koji Ishii via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Sep 2016 10:34:27 +0000
- To: public-css-archive@w3.org
kojiishi has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-step-sizing] Feedback on Proposal == Copied from @fantasai's [e-mail on www-style](https://lists.w3.org/Archives/Public/www-style/2016May/0089.html) sent before we started using github for the tracking purpose. ----- 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 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/490 using your GitHub account
Received on Thursday, 15 September 2016 10:34:35 UTC