I did a quick review of Section 1 of the CSS Inline Specification some time ago, but as it is on the agenda for this F2F, I took a better look recently.
The things that immediately strike me are:
There is no explicit way to set the alignment point for an object, especially a non-textual object, that is being aligned. This was the role of the “alignment-point” property in the prior proposal. This allows a relevant alignment point
to be defined for a image that contains a glyph. Without this replaced elements are always aligned to their bottom margin edge. The “length” value of the “baseline-shift” longhand may help here, but the “percentage”values do not because they are relative to
line-height which makes them useless for accurate postioning. If there is an “alignment-point” property (to be able to set it explicitly relative to the object being align (not relative to its parent)), then an “auto” value would mean set the alignment point
to the position of the baseline to which you are aligning (in the object being aligned). A length or percentage value would set the alignment point relative to the bottom (content are, padding, margin?) of the object. In both cases, the alignment would be
to place the alignment point at the position of the “alignment-baseline” in the parent.
This spec seems to be missing the “inherit” value of the 2.1 “vertical-align” property
In CSS 2.1 the syntax is
“baseline | sub | super | top | text-top | middle | bottom | text-bottom | <percentage> | <length> | inherit”
In the Inline Module the syntax (expanding the two “longhands”) is
“[<length> | <percentage> | sub | super]
|| [baseline | text-bottom | alphabetic | middle | central | mathematical | text-top |bottom | center | top]”
This new syntax allows the specification of both a baseline alignment and the specification of a shift. I presume, but the spec is not clear about this, that the baseline alignment is done first and the shift is done subsequent to that
alignment. The spec should make this clear.
Why are “percentage” values of “baseline-shift” relative to the line height? It would seem that font-size would be more relevant. Font size is what is used to scale the baseline pos
With respect to Issue 3. It is clear that these alignments are not baseline alignments, but they were historically part of “vertical-align”. It would seem to make sense for these three values (and an additional “auto” value) to be the
values of a third shorthand, “subtree-alignment”. The “auto” value would be the default and would mean use the “alignment-baseline” value. In this case the syntax would become
“[[<length> | <percentage> | sub | super]
|| [baseline | text-bottom | alphabetic | middle | central | mathematical | text-top]]
&& [bottom | center | top]”
This, however, would remove applying a “baseline-shift” to a “center”ed sub-tree. Is that something that is needed? Currently, shifts cannot be applied
to sub-trees that are top or bottom positioned.
This section needs to define how the Line Box is content area is calculated if this module is to replace CSS2.1. Specifically it needs to show how “top” and
“bottom” positioned sub-trees interact in determining the height of the Line Box.
This section also needs to specify how the baseline positions in the parent, the scaled baseline table, are calculated using “font-size” (of the parent) and the baseline table associated with the dominant baseline. These are the points
to which the child alignment point can be aligned.
XSL-FO has a “use-script” value for “alignment-baseline” to provide a better version of “auto” making the default alignment baseline be script based. This may be a future version feature due to the difficulty of specifying what default
baseline each script should use but it could be useful for authors.