[css-line-grid] inline grid / character grid

We've often discussed how in CJK layout (excluding Korean when it uses inter-word spaces), every single character should be aligned on a regular pattern, and that we would need something like a line grid in both dimensions to make it work.

In the block axis, we already have the line-grid spec, which covers the needs adequately.

In the inline axis, we need something. But it turns out that "every character needs to line up" isn't quite true, and in most cases, the reality is actually less demanding. In traditional CJK typesetting, everything does indeed need to line up, which is made easier by having every character actually be the same size at the font level. But in modern Japanese typesetting, within that integer-multiple-of-an-em-box line, justification is typically used. If the text is purely made of monospaced full width characters, things will indeed line up, but if there are latin letters, or digits, or whatever that's not em-box sized in the line, the extra space should be distributed and the characters are not expected to fit the line gird.

Just being adjust the line boundaries would therefore let us solve:
* The simple case where all the characters are Chinese characters (or identically sized characters) and the font has the same metric for all of them.
* the modern Japanese use-case (also found in mainland china as well I believe) in the general case, regardless of the font(s) and of the character mix.

This is not to say that the other variants and use cases aren't worth solving, but they can all be addressed with additional constrains on top of the basic control of the line length, so I think we should address them at level 2.

So here's the proposal for level 1

We can either set this up as new pair of properties in parallel to line-snap and line-grid, or as extra values to these existing properties. As I think this is unlikely that one would want independent grips for the inline and block axis, I think we're fine rolling it up into the existing properties, but I'm ok with the other way as well if people thing it's needed.

So the syntax would either be

line-grid: match-parent | create  /* same as today */
line-snap: none |  baseline | contain  /* same as today */
inline-grid: match-parent | create
inline-snap: none | line-edges

or

line-grid: match-parent | create /* same as today */
line-snap: none | [ [ baseline | contain] || line-edges ]

Regardless of the syntax, in terms of behavior (only discussing the inline direction):

* '(in)line-snap: create': The box creates, a series of lines orthogonal to the inline axis, separated by 1em + letter-spacing. The position of the grid lines depend on the text-align property. If 'text-align' is 'left', 'right', start, or end, a grid line should be anchored at the corresponding edge of the content box, and other lines placed based on it. if text-align is   justify all, the line grid should be anchored at the start edge. If text-align is justify, the anchor is determined by text-align-last. If text-align is center, the line grid should be placed so that the distance from the left edge of the content box and the first line grid to its right is equal to the distance from the right edge of the content box and the first grid line to its left.

* '(in)line-snap: match-parent': the box reuses the (in)line grid of its parent if they're in the same writing mode, or does the same as create otherwise.

* '(in)line-snap: line-edges': The start edge of each line box, if it does not fall exactly on a grid line, is moved to the closest gird line towards the end side, unless that would cause it to move closer to the end edge than a single step on the (in)line grid. Then, the end edge of each line box, if it does not fall exactly on a gird line, is moved to the closest grid line to wards the start, unless that would cause it to move closer to the end edge than a single step on the (in)line grid. If text-align computes to right, the order is reversed, and the right edge is adjusted first.
Note: the ordering of doing start then end makes no difference except when the line boxes are so short that there isn't enough room for even a single aligned em box, in which case this order prioritizes preserving the line alignment.

Received on Saturday, 30 January 2016 22:31:29 UTC