Re: [css3-writing-modes] recent edits

John Daggett wrote:
> 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.


This is since writing-mode currently establishes a block formatting 
context. All of CSS2.1 that has any dealing with floats has a abstract 
aspect with vertical-lr and horizontal-bt.

Using horizontal-bt as an example (just to make sense of what we face 
with vertical-lr). Any rule concerning float and left must always be 
treated as both physical and logical left. Any rule concerning float 
and right must always be treated as both physical and logical right. 
Any reference to top and bottom (of the float, not the box in lives 
in) has to be reversed to keep both the physical and logical 
relationship to left and right values. Take some rules for 9.5.1. 
Changes between top and bottom values are shown *bold* and abstraction 
between physical and logical are _underlined_.

  Most of Rule 2.

   # If the current box is left-floating, and there are any
   # left-floating boxes generated by elements earlier in the
   # source document, then for each such earlier box, either the
   # left outer edge of the current box must be to the right of
   # the right outer edge of the earlier box, or its top must
   # be lower than the bottom of the earlier box.


  This must be interpreted as.

   | If the current box is left-floating, and there are any
   | left-floating boxes generated by elements earlier in the
   | source document, then for each such earlier box, either the
   | left outer edge of the current box must be to the right of
   | the right outer edge of the earlier box, or its *bottom* must
   | be *higher* than the *top* of the earlier box.


Part of Rule 4.

   # A floating box's outer top may not be higher than the
   # top of its containing block.


  This must be interpreted as.

   | A floating box's outer *bottom* may not be *lower* than the
   | _bottom_ of its containing block.



  Rule 5.

   # The outer top of a floating box may not be higher than
   # the outer top of any block or floated box generated
   # by an element earlier in the source document.



This get a bit twisted with the over (side) for the 'block' and bottom 
for the 'floated box'.

   | The outer *bottom* of a floating box may not be *lower* than
   | the outer _over/bottom_ of any block or floated box generated
   | by an element earlier in the source document.


> 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


That would work much better if some of those block were floating but 
as the spec stands now, this can not happen. There are two 
consequences of a BFC.

1. The border box of a BFC can not overlap floats in the same BFC.
2. The margin box of a float must be fully contained by nearest 
ancestor that establishes a BFC.


>>> 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.


Imagine them as two sets of train lines crisscrossing

              horizontal-bt

                L      R

            L   L   L  L/R  L

vertical-lr    L   +   R   vertical-lr

            R  L/R  R   R   R

                L       R

             horizontal-tb

>  L
>>> 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?


I got really confused when the first column of logical sides/edges was 
added. About 5 days of playing writing-mode and physical vs logical 
and your day to day experience becomes disorientated. My list message 
form this period is testament to that topsy turvy sensation.



[snip]
>> 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".


There need to be direction mapping for overflow. Overflow hidden is 
mapped to before and start where overflow visible is mapped to after 
and end.


>> 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.)


This is true fantasai but floats go upwards in vertical-rl or in other 
words, we should be thinking sinks and sinking instead of floats and 
floating. ;-)



-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo

Received on Friday, 12 November 2010 18:05:47 UTC