[css-writing-modes][css-inline] synthesizing baseline tables for replaced elements

Section 4.3. Atomic Inline Baselines or the CSS Writing Modes Level 3 spec says,

"If an atomic inline (such as an inline-block, inline-table, or replaced inline element) is not capable of providing its own baseline information, then the UA synthesizes a baseline table thus:

alphabetic
The alphabetic baseline is assumed to be at the under margin edge.
central
The central baseline is assumed to be halfway between the under and over margin edges of the box.
"
This definition seems to have a number of problems for positioning an image that is intended as a glyph to be aligned with other glyphs on a line. Examples of uses of this capability include putting a new mathematical symbol in a text describing it and positioning an initial letter that that has a decorated background and is realized as an image or an SVG.

I know that the above "alphabetic" baseline position is historical which makes changing it to something more reasonable is not an option. It is however not very useful for replace elements that represent characters with descenders. These, of course, occur in Latin and Greek based fonts, and are even more common in a number of South and SouthEast Asian scripts.

It has been suggested that one can use margin adjustments to reposition the replaced element content relative to this base line. But the position of the margin is also used in the computation of the height of the line box. "The height of each inline-level box in the line box is calculated. For replaced elements, inline-block elements, and inline-table elements, this is the height of their margin box. ... The inline-level boxes are aligned vertically. ... The line box height is the distance between the uppermost box top and the lowermost box bottom." If the bottom margin is moved upward (made negative) to position an image of a character with a descender, then the height of this character is artificially shortened and the line box height calculation will be incorrectly calculated (it will be too short) and positioning this shorter box may lead to line collisions. Basically, margins are already used in line layout and trying to use them for another purpose will not work.

The above problem can be mitigated a bit by careful use of the replaced elements. If all the elements are 1EM high and they are positioned with other elements that are 1EM high, it is far less likely that the calculation of the line box height will be too short even when the replaced elements are positioned by adjusting the bottom margin.

It has also been suggested that using the bottom margin change would adjust all the baselines, correctly. Even for the two baselines currently specified, it is unlikely that this will work for lower case letters with descenders.

The  best solution to the problem of defining baselines for objects which do not naturally have them would be to define a property that allows a baseline table to be defined. One might, for example, have a property which takes a list of pairs in which the first items in the pair is the name of a baseline and the second is a percentage of the image height measured from the bottom. (Here it is assumed that the image is intended to define the EM for the glyph, but the reference height could also include border, padding and margins if that were more appropriate.) An example might be:
               Baseline-table: ideographic 0% alphabetic 20% middle 50% ...

One reason that a full baseline table is needed is that to handle initial letter sizing two points are needed. For Latin based scripts, these are the alphabetic baseline for alignment and cap-height for sizing (to the number of lines to cover). For other scripts, different baselines are used; for example, in Northern Indic scripts you would use the hanging baseline for alignment and the alphabetic baseline for sizing.

However, for a number of cases, a full baseline table is not necessary and is probably behind the capabilities of many users. For these cases, the margin adjustment is likely to give adequate results but is fragile at edge cases. Another approach would be to allow the user to specify, via an "alignment-point" property, the location of an alignment point along the "start" edge of the object and to specify, via "alignment-baseline", what baseline that alignment point is to be positioned at. Another way to do this would be to introduce a simple form of the "baseline-table" property that takes only on pair of values; for example, "baseline-table: alphabetic 20%".

Steve Z