Re: [css3-writing-modes] recent edits

fantasai wrote:

> > * Section 7 still contains wording that implies vague things about the "logicalness" of width/height.
> > In 7.1:
>
> >> The height properties (‘height’, ‘min-height’, and ‘max-height’)
> >> refer to the physical height, and the width properties (‘width’,
> >> ‘min-width’, and ‘max-width’) refer to the physical width. However,
> >> the rules used to calculate the height and width are logical: the
> >> height calculation rules in [CSS21] are used for the logical height
> >> (which could be either the physical height or physical width).
> >> Likewise the width calculation rules in [CSS21] are used for the
> >> logical width.
> >>
> >> As a corollary, percentages on the margin and padding properties,
> >> which are calculated with respect to the containing block width
> >> regardless of their dimension, are calculated with respect to the
> >> logical width of the containing block.
>
> This section is explaining how the CSS2.1 box model applies to vertical
> writing modes. If you feel there is insufficient detail on how this
> works ("vague things"), please explain exactly what information you
> feel is missing. But it has nothing to do with the logicalness of any
> properties.

It's vague because it doesn't define which height/width calculations
you're referring to and how precisely it affects them.  The box model
and visual formatting model calculations defined in CSS 2.1 are fairly
involved and writing-mode adds lots of interesting ripples because an
element and its containing block are no longer always in the same
writing mode.

I'm not just being a persnickety bugger here, I played around with this
today and I see lots of inconsistency in height calculations across
existing implementations.  It's hard to explain what the correct
behavior should be given the current wording in the spec.

Here's the example I was playing with, it sets up two rows of four
blocks each with variations in writing-mode within each block:

http://people.mozilla.org/~jdaggett/tests/verticalmargins.html

Renderings in three implementations:

  Webkit trunk/OSX screenshot:
  http://people.mozilla.org/~jdaggett/tests/webkit-vertical-margins.png
  
  IE8/XP screenshot:
  http://people.mozilla.org/~jdaggett/tests/ie8-vertical-margins.png
  
  IE9beta/Win7 screenshot:
  http://people.mozilla.org/~jdaggett/tests/ie9-vertical-margins.png
  
> > I'm not entirely clear what 7.2.2 implies about existing properties
> > that have directional dependencies.  So 'left' and 'right' for
> > text-align will effectively map to start and end?  Would it be better
> > to add explicit 'start' and 'end' values?  Ditto for float/clear.  I
> > also think vertical-align needs to be flushed out more explicitly.
> 
> Please read the Line Orientation section:
>  
> http://dev.w3.org/cvsweb/~checkout~/csswg/css3-writing-modes/Overview.html?rev=1.40&content-type=text/html;%20charset=iso-8859-1#line-orientation
> It defines the terms "line right", "line left", "over", and "under".
> The line right and line left directions are not equivalent to start
> and end.

That section includes wording like this:

>   The line right and line left directions are calculated with respect
>   to the writing mode of the element and used to interpret the ‘left’
>   and ‘right’ values of the following properties:
> 
>     * the ‘text-align’ property [CSS21]

Ok, then I think you should just say that the values of 'left' and
'right' for the text-align property are defined to mean line left and
line right, with links to where those terms are defined.  The term "used
to interpret" doesn't really say that.

> > Sections 7.2.3 and 7.2.4 seem like they should be removed for now.
> 
> I strongly disagree that 7.2.3 should be removed. The mapping of
> CSS2.1's layout rules and property definitions to the appropriate
> behavior in vertical layout depends on this mapping (which is
> defined in earlier sections). Removing this summary table, which
> make it easier to see the effect of those definitions in different
> writing modes, seems like an absurd request.

It's not absurd, you're defining *lots* of terms without clearly defining
the behavior implied.  How is an author/implementor intended to use this
table?  Why is defining length and measure useful for example?  Seems like
you've already defined other terms in sections 2 and 5, so why the need
for this here?  At first glance, it seems like you're remapping CSS
*properties* when you're really simply defining what different terms
mean for different writing modes. 

> As for 7.2.4, I don't understand why you think it should be removed.
> Distinguishing between the physical behavior of box-shadow offsets vs.
> the logical behavior of the 'vertical-align' property seems like a
> useful thing to be pointing out.

Why only those properties and not all other properties that do not vary
with writing-mode?  I think you can just omit these and include a
statement like "writing-mode only affects properties explicitly listed
here, other properties are unaffected".  The spec right now is in
between, describing some properties that are affected, some that are not
and leaving others unmentioned.

I also noticed today that the wording in Section 4.1 also seems like
it's leftover from previous versions of the spec that defined logical
versions of margin, padding, and border:

> 4.1. Box Layout in Vertical Writing Modes
> 
> CSS box layout in vertical writing modes is analogous to layout in the
> horizontal writing modes, following the principles outlined below:
> 
>     * Calculations that refer to the width use height instead, and vice
>       versa. See Logical vs Physical Dimensions.
>     * Calculations that refer to the ‘*-left’ and ‘*-right’ box
>       properties (border, margin, padding, outline) use ‘*-top’ and
>       ‘*-bottom’ instead, and vice versa. In right-to-left block flow
>       ‘*-right’ is analogous to top-to-bottom's ‘*-top’; in left-to-right
>       block flow ‘*-left’ is analogous to top-to-bottom's ‘*-top’. See
>       Logical Directions for a fuller discussion of direction-mapping.
>     * Layout effects that depend on the ‘direction’ property to choose
>       between left and right (e.g. overflow, overconstraint resolution,
>       the initial value for ‘text-align’, table column ordering) are
>       abstracted to the start and end sides and mapped appropriately. 

The first and third points repeat wording that is included in other
sections. The second point no longer applies, without logical
margin/padding/border properties, there is no "direction mapping".

> For features such as text alignment, floating, and list marker
> positioning, that primarily reference the left or right sides of the
> line box or its longitudinal parallels and therefore have no top or
> bottom equivalent, the line left and line right sides are used as the
> reference for the left and right sides respectively. (See Line-Relative
> Directions.)
> 
> Likewise for features such as underlining, overlining, and baseline
> alignment (the unfortunately-named ‘vertical-align’), that primarily
> reference the top or bottom sides of the linebox or its transversal
> parallels and therefore have no left or right equivalent, the over and
> under sides are used as the reference for the top and bottom sides
> respectively.

Again, I think you should omit this and include a fuller description
with specifics in section 7.2.2.  For example, precisely how
vertical-align properties work for vertical writing modes.

Regards,

John Daggett

Received on Friday, 12 November 2010 09:05:46 UTC