Re: [css-display] Unofficial draft of a Display spec ready for consumption

On Sun, Oct 21, 2012 at 12:15 PM, Tab Atkins Jr. <> wrote:
> On Sat, Oct 20, 2012 at 2:55 PM, Andrew Fedoniouk
> <> wrote:
>> 'display-box'  either 'normal' or 'none'
>> sounds misleading for inline elements. They have no box to hide or to
>> show normally.
> Inline elements generate boxes.

So it should be plural then, display-boxes or so.

But display:none does not just mean not generating boxes.
It is also about margin collapsing for example.

>> We already have 'visibility' property so why do we need more?
>> We just need to add new value like visibility:excluded to define
>> display:none effect.
> Possible, sure, but display:none is already part of the 'display'
> property, so we have to handle it in the longhands *somehow*.  Plus,
> this is very familiar to authors.  Third, display:contents is clearly
> related to display:none, but not clearly related to visibility.
> Finally, visibility is already well-established as just being a visual
> effect - it still causes things to generate boxes, while display:none
> does not, so 'visibility' isn't a great fit for the functionality.

For the purpose of all layout calculations this can be used:

bool is_display_none() {
    return display == display_none || visibility == visibility_exclude;
inside the UAs implementation. Not a big deal really.

And yet visibility:collapse; is in principle similar to visibility:exclude;
No surprises for developers here.

>> And it is good to hear that you finally started to speak about
>> "layout mode" (layout method, layout manager, etc. in classic UI sense).
> We've used the term "layout mode" for a long time.  My blog post with
> the sketch of this is 2 1/2 years old, and I've been complaining about
> the issue for longer than that.  Finally, Bert wrote up the first
> version of this ('display-model' and 'display-role') in Template
> Layout even before I came into the group.

OK, let's extend "layout mode" to the "layout manager".
If to use this term then CSS layouts can be modeled as these:

1. At any given moment of time the element has one and
    only one layout manager installed/assigned:

For CSS2.1 the list of such layout managers looks like this:
- text, - text-rtl - container of glyph and inline boxes;
- blocks, container of blocks only replaced vertically (+ floats),
  if the element contains inlines among blocks then anonymous
  paragraph is created to contain them.
- table, special kind of container, that is about table-sections/rows/cells.

2. CSS3 adds or is going to add these:

- multi-column layout.
- flex(horizontal), flex(vertical), flex(horizontal-wrap), flex(vertical-wrap)
- grid, probably.
- text-ttb, blocks-rtl, TTB-RTL writing systems.
- regions (?)

Again all these values are mutually exclusive by nature - so only
one type of LM at any time.

Ideally it has to be one CSS property that defines/triggers
layout manager to be used on an element.
Otherwise it is not clear what this means for example:

#ugly-container {
  display: flex;

To avoid inconsistency it should be written as either this:

#flex-container {
  display: block;
  flow: flex row; /* or some such */

or this:

#columns-container {
  display: block;
  flow: multi-column;

>> But I am not sure I understand how your split will be backward compatible.
>> Something tells me that it is not.
> I don't understand.  The 'display' property explicitly handles all of
> the legacy values appropriately.  There's nothing else to be
> compatible with.

How should CSS2.1 only UA render this:

span {
   display-inside: block;
   display-outside: inline-level;


Andrew Fedoniouk.

Received on Monday, 22 October 2012 01:57:37 UTC