[css-writing-modes] Question about implementability of the "different writing-mode value than its containing block" section of the spec

https://drafts.csswg.org/css-writing-modes-3/#block-flow says (not 
directly linkable):

   If a box has a different writing-mode value than its containing block:

     If the box has a specified display of inline, its display computes
       to inline-block. [CSS21]
     If the box is a block container, then it establishes a new block
       formatting context.
     More generally, if its specified inner display type is flow,
       then its computed inner display type becomes flow-root.
       [CSS-DISPLAY-3]

I have several concerns about this language:

1)  Determining the containing block requires knowing the computed 
values of various properties.  Requiring knowledge of the containing 
block to determine computed display means that UAs can't cleanly 
separate a style computation pass from other things.  This is likely to 
be quite difficult to implement in practice, though also in practice it 
might be hard to observe because most if not all of the things that make 
the containing block not match the thing you inherit style from fall 
afoul of concern #2.

2)  This requirement directly contradicts the requirements laid out in 
<https://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo> or equivalent at 
<https://drafts.csswg.org/css-display-3/#transformations>. 
Specifically, consider this testcase:

   <div style="position: relative; writing-mode: horizontal-tb">
     <div style="writing-mode: vertical-rl">
       <span style="writing-mode: vertical-rl; position: 
absolute">Text</span>
     </div>
   </div>

What is the computed display value of the "span"?  Is it "inline-block" 
or "block"?  The writing-modes spec says "inline-block"; the display 
spec says "block".  Nothing reconciles the disagreement.  In practice, 
looks like at least Chrome and Firefox compute to "block" in this 
situation; I haven't tested other UAs in ways that I consider reliable. 
I haven't tested whether hypothetical box determination here uses 
"inline" or "inline-block" as the display type; that obviously needs to 
be defined too.

In practice, what Gecko seems to implement here is to start at the thing 
you inherit style from (some handwaving about ::first-line here), and 
walk up the inheritance chain to the first thing with display not equal 
to "contents".  Then if the writing mode doesn't match _that_ set 
display to "inline-block".  And this happens before blockification 
triggered by float/position.  I haven't checked what we do for the 
hypothetical box.

If this is in fact black-box equivalent to what the spec is trying to 
define, it might be worth rephrasing it in ways that don't break the 
layering of property value computation, so we don't accidentally make it 
_not_ black-box equivalent and not very implementable.  If it's not 
black-box equivalent, I'd like to see what a testcase to distinguish the 
two options looks like and see what UAs do with that testcase.

-Boris

P.S. Obviously there's an issue here when a run-in has different 
writing-mode than the block it runs into.  The display and writing-mode 
specs don't consider this case.  I recommend it be resolved by removing 
run-ins.  ;)

P.P.S.  Does the writing-modes spec really have no way to file issues 
other than the mailing list?  Certainly the header claims so.  :(

Received on Monday, 13 March 2017 21:23:51 UTC