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

On Fri, Oct 19, 2012 at 3:40 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> Hey all!  I've been complaining for some time about the fact that
> 'display' unnecessarily conflates "layout mode" with "role in parent's
> layout mode".  I've had mini-rants about this in Lists and Flexbox,
> and on the list a lot of times.  Further, authors have given
> consistent feedback over the years that indicates the conflation of
> 'display:none' with the other values is confusing or hard to work with
> - in particular, they'd like to be able to toggle "none"-ness without
> disturbing the original 'display' value, or having to manually
> remember what the old value was.
>
> As such, I've written up a first draft of a proposal to split
> 'display' into sub-properties:
> <http://dev.w3.org/csswg/css-display-3/>.  (It currently has the ED
> styling, but as I've indicated in the Status section, it's technically
> an Unofficial Draft until the WG approves it.)
>
> There's some prior art for this draft.  Old revisions of the Template
> Layout draft included 'display-model' and 'display-role' properties,
> which were cognates to 'display-inside' and 'display-outside' in my
> draft.  Over two years ago I authored a blog post
> <http://www.xanthir.com/blog/b45F0> exploring the idea.
>
> This draft actually introduces very little new functionality.  The
> most important innovation is just that several independent concepts
> that were previously wrapped together in 'display' are now separated,
> so they can be independently toggled/cascaded.  In particular, an
> element's layout mode is determined by 'display-inside', while the
> element's role in its ancestor's display mode is determined by
> 'display-outside'.  The "display:none" functionality is handled by the
> 'display-box' property, while the generation of ::marker
> pseudo-elements is controlled by 'display-extras'.  (Both of these
> latter property names are pretty sucky.  Feel free to bikeshed them.)
>

I like the direction this is going. Mainly, I like that this spec minimizes
potential combinatorial explosion of possibilities that browser vendors
need to support. I think if we make this too complicated, getting
interoperability is going to be a painful decade long process and will be
difficult for web developers to wrap their heads around.

In that vein, I don't really see the benefit of display-extras. Can we just
make list-item it a display-outside value? It'll still have some special
behavior that other display-outside types can't reproduce, but that seems
OK to me. For example, I don't see a use-case that requires being able to
have inline list-items. You can't do that today, right?


> The only fundamentally new pieces of functionality are:
>
> 1. Any type of element can generate a ::marker pseudo. ::marker is
> exactly like ::before, except that it has some special positioning and
> content rules in Lists, so this is nothing particularly special.  It
> just falls out of the model more-or-less by accident.
> 2. You can toggle between "display-box: normal;" and "display-box:
> none;" without affecting the element's layout mode or role.
> 3. 'display-box' has a new value, "contents", which has been requested
> and talked about in the past - it suppresses the element's own box
> generation, but not that of its children - in other words, for layout
> purposes it acts as if the element was replaced by its children.  This
> is useful for layout modes, like Flexbox, that privilege children over
> arbitrary descendants, because sometimes you need a wrapper element
> (for script or cascade purposes), but still want the children of the
> wrapper to interact with the non-wrapper elements around them.  It's
> also useful for Web Components, for similar reasons - many things are
> vastly simplified by making the shadow root a wrapper element, but the
> extra element can make layout harder.
>
> Thoughts?  Would the WG be okay with taking this on as a work item?
> It should be low-maintenance and pretty quick to advance, because I'm
> not trying to do very much with it.  In particular, I'm *not* wanting
> to mix any block-layout-related stuff into this draft - that should be
> done in an explicit Block Layout spec (Anton, your calling!).  That
> said, there's the potential for a little more work going on in this
> spec.  I have issues called out inline for additional things we could
> usefully put into the draft.
>
> ~TJ
>
>