[css-display] Refactoring 'display', got a crazy idea

So, per a WG resolution from a while ago, I'm refactoring the Display
module to drop 'display-inside/outside' and instead just extend
'display' to handle the things it allowed. While doing so, I realized
my previous spec text was papering over an awkward hole, and I could
fix that hole while solving a long-standing request at the same time.

Ignoring some of the weirder exceptions, the new grammar model is
basically [block-level | inline-level] || [table | flex | grid |
ruby].  You specify what your layout model is, and how you react to
the formatting context your ancestor establishes.  However, the
Block/Inline Layout terms didn't really fit into this.  If we say that
"block" is a layout model, then clearly a display:block maps to
"block-level block", and display:inline-block maps to "inline-level
block".  But how to handle display:inline?  If we make "inline" a
layout model as well, then "display:inline" maps to "inline-level
inline", but then what does "block-level inline" mean?  In the old
spec I papered over this; I had an "auto" layout model, which acted
like "display:inline" or "display:block" based on whether it was
block-level or inline-level (so "block-level auto" and "block-level
block" were identical).

I had an inspiration last night, though, and checked it by fantasai
this morning, who thinks it makes sense.  Here's the details:

We define two layout-model keywords: "flow" and "flow-root".  (Terms
shamelessly stolen from the Box Module.)  The legacy display values
map as:

* inline => inline-level flow
* block => block-level flow
* inline-block => inline-level flow-root
* ??? => block-level flow-root

The idea is that "flow-root" is the term that actually invokes a block
formatting context.  Elements with "flow" instead layout within a
shared BFC.  Thus, "block-level flow" is like display:block, but
automatically invokes a BFC.  Doing this without hacks like 'overflow'
has been a long-standing request, and it nicely fills this hole in the
grammar space.

We wouldn't need to change any terminology.  A "block" box would still
mean what it does today; it would just be defined as "a block-level
flow or flow-root box", etc.

This terminology also means I no longer have a clash of inside and
outside terms, so I can drop the "-level" part of the outside terms,
making the whole thing less verbose.  We'd then have "inline flow",
"block flow", "inline flow-root" and "block flow-root".  *This* then
leads to the defaulting rules being simpler - "display:inline" and
"display:block" are no longer legacy keywords that get mapped to a new
value pair, they're just normal keywords; an omitted "inside" value
would default to "flow".  The whole thing ends up being way more
elegant with this change.

Thoughts?

~TJ

Received on Thursday, 7 May 2015 17:16:06 UTC