W3C home > Mailing lists > Public > www-style@w3.org > April 2010

Re: Splitting 'display'

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 16 Apr 2010 12:23:18 -0700
Message-ID: <g2ydd0fbad1004161223y115fb67u5338577ff84fc4c3@mail.gmail.com>
To: www-style list <www-style@w3.org>
It's probably good to explain why I did this.  There are two reasons.

First, as I stated in the actual text, our conflation of the inside
and outside values has gotten somewhat ridiculous.  At the very least,
any new display value has to be duplicated as a block and inline
version.  This doesn't cover all useful cases, though.  For example,
it's impossible to make a list-item act like a table, or a table-cell
to format its children as a flexbox.  Splitting them apart makes this
all work simply, like its supposed to.

Second, this makes it much easier to segregate appropriate features
into particular contexts.  The 'static' and 'text' values for
display-inside are the "traditional" layout modes in CSS, and are
meant for laying out a document, not a webpage or an application.
Some features, like float, only really make sense when used in a
document context.  Now, we can cleanly say that "float" only has an
effect when its parent has "static" or "text" display-inline.  Same
with multicol - we don't have to worry about trying to define that
multicol doesn't make any sense on a display:table element, for
example.  Multicol can say it, once, and be done with it.  Then,
future layout modes don't have to worry about protecting themselves
against unintended interactions.

This makes sensibly speccing flexbox easier, as I can define the
values as new display-inside values, and automatically get (a)
protection from weird consequences of things being specified that only
make sense in "static" and "text", or "table"/"table-inside", etc, and
(b) automatic combination of flexbox in all sensible types of boxes
(like list-item, table-cell, etc) without interfering with their role
in their parent's layout algorithm.

This'll help out Template Layout, too.

Received on Friday, 16 April 2010 19:24:11 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:45 UTC