- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Mon, 13 Mar 2017 17:23:18 -0400
- To: www-style list <www-style@w3.org>
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