W3C home > Mailing lists > Public > www-style@w3.org > May 2014

Re: [SVG2][css-inline] vertical-align, baseline-shift, alignment-baseline, dominant-baseline

From: John Daggett <jdaggett@mozilla.com>
Date: Tue, 20 May 2014 18:02:43 -0700 (PDT)
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-svg <www-svg@w3.org>, www-style@w3.org, Cameron McCormack <cmccormack@mozilla.com>, Dirk Schulze <dschulze@adobe.com>
Message-ID: <197812399.34383.1400634163806.JavaMail.zimbra@mozilla.com>
fantasai wrote:

> Action plan for getting these specced across CSS and SVG:
> 
> A. Work on definitions in SVG2 by
>      1. Adding vertical-align
>      2. Defining vertical-align as a shorthand of baseline-shift
>         and alignment-baseline
>      3. Being clear that dominant-baseline is not a longhand of
>         vertical-align.
> B. Synchronize CSS Inline Layout with SVG2 in this respect.
> 
> #2 is because vertical-align and baseline-shift specify the same
> thing, so one needs to be a shorthand of the other in order to
> avoid conflicts. (XSL:FO defined vertical-align as the shorthand.)
> 
> #3 is because dominant-baseline is set based on the content of
> the element, whereas alignment-baseline, baseline-shift, and
> vertical-align are about the relationship of the element to its
> parent.

I don't think these baseline properties, 'dominant-baseline',
'alignment-baseline' and 'baseline-shift' are needed in CSS. They exist
in SVG [1], [2], in XSL-FO [3] and in the old CSS3 Line Layout draft [4]
but I don't that by itself is sufficient justification for moving them
into a CSS on a REC track. As currently spec'ed in these various places
I think they are overdesigned and, to a large degree, solutions in
search of a problem.

It's not at all clear they are necessary and the use cases sited in
various specs seem related to mechanical typographic controls, like
using baseline shift to simulate subscripts and superscripts. Modern
fonts provide better ways of doing this particular use case and, in
general, we should shy away from providing lots of mechanical
typographic controls because they don't work well across different font
combinations.

The dominant baseline in a run of text should be inferred from the
language attribute of the element, the script of the text content and
the writing mode (horizontal or vertical). Authors shouldn't need to
specify an *additional* property to have this set properly.

For doing multi-script layout (e.g. Latin text within runs of Arabic)
proper font choice is really the best way to do line layout.  Assuring
that these lines are laid out properly across implementations should be
the goal here, not adding more properties to jiggle things manually with
random fonts that were not designed with multiple script usage in mind.

Just as a reminder, here's what the properties we're talking about look like:

‘dominant-baseline’
    Value:  	auto | use-script | no-change | reset-size |
                ideographic |alphabetic | hanging | mathematical |
                central | middle | text-after-edge | text-before-edge

‘alignment-baseline’
    Value:  	auto | baseline | before-edge | text-before-edge |
                middle | central | after-edge | text-after-edge |
                ideographic | alphabetic | hanging | mathematical

‘baseline-shift’
    Value:  	baseline | sub | super | <percentage> | <length>

Regards,

John Daggett
Mozilla Japan

[1] SVG 1.1 baseline properties
http://www.w3.org/TR/SVG11/text.html#BaselineAlignmentProperties

[2] SVG2 baseline properties
http://www.w3.org/TR/SVG2/text.html#BaselineAlignmentProperties

[3] XSL-FO area alignment properties
http://www.w3.org/TR/xsl/#area-alignment

[4] Baseline properties from old draft of CSS3 Line Layout spec
http://dev.w3.org/csswg/css-inline/#baseline
Received on Wednesday, 21 May 2014 01:03:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:27 UTC