Re: [css-display] feedback on box-suppress

>> On Jun 20, 2015, at 3:09 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
>> 
>>> On 02/18/2015 06:04 PM, Tab Atkins Jr. wrote:
>>>> On Sun, Feb 1, 2015 at 3:29 PM, Mats Palmgren <mats@mozilla.com> wrote:
>>>> On 09/27/2014 07:31 PM, fantasai wrote:
>>>> We have a couple of key issues open that we would particularly like
>>>> feedback on:
>>>> 
>>>>    A. Naming of the box-hiding-and-showing property. Please send us
>>>>    suggestions for improvement! (Or comments on what you like about
>>>>    the current name. We're pretty unsure atm, but want it to be
>>>>    easily understandable.)
>>>>    http://www.w3.org/TR/css-display-3/#box-suppress
>>> 
>>> 
>>> 'box-suppress: hide' has multiple issues noted in the spec[1] so I wonder
>>> if it would be better to move it to the next level of the spec?
>>> 'box-suppress: show | discard' OTOH is straightforward to implement and
>>> is something that authors have been asking for for a long time.
>>> 
>>> My 2 cents on the naming: 'box-suppress: discard' sounds like a double
>>> negation and I find it hard to understand what it does Sent from my iPad
>>> the words. I would prefer a positive term instead, like
>>> 'box-construction: normal | none' or 'box-features: all | none'.
>>> ('none' is to associate it with 'display: none' to make it easy to
>>> remember what it does).
>> 
>> 'box-construction: normal | none' is a better name than the current, I
>> think.  fantasai, opinions?
> 
> I don't think it's as user-friendly as the current list of keywords.
>  show | discard | hide
> is pretty explicit about the differences among the keywords, whereas
> normal | none really isn't self-evident at all.
> 
> All in favor of a better property name, though!
> (I don't have any good suggestions.)

A) How about: 
    display-box: none | show | hide

This has the advantage of giving authors something very similar to what they are used to: 'display-box:none' is an easy to remember alternative to the familiar 'display:none'. And it is saying that there is no display of the box, which is easy to understand. 

Having it start with 'display-' also makes it seem more like it belongs in the family of 'display-*' properties. And it fits well with the second half of my proposal, for the shorthand:

   display: [<display-outside> [<display-inside> [<display-box> <display-list>?]?]?] | <legacy-values>

B) If the order was enforced, as above, then we wouldn't have to remember which one used 'block | inline' and which one was supposed to include '-level' too. You could just write 'display: inline block none', and it would do the same as a 'display:none' that didn't forget that it was originally 'display:inline-block'. Easy peasy. 

And, once again, it would be easy on authors to just start writing 'display: inline block' instead of 'display: inline-block'. And 'display:block' and 'display:inline' wouldn't change at all from the legacy version, even though they would technically be shorthands now.

C) Do we really need display-list as a separate property? Can't we just say that this:
    x { display: list-item }

...is equivalent to this:
    x { display: block }
    x::marker { display: inline }

Thus, having a display of not 'none' on the ::marker would make it a list item. Bam. Now it gets 'disc' as the initial 'list-style-type' and a bullet as the marker content. This seems simpler me, and easier to mentally track what's going on, and how 'display: list-item' interacts with ::marker.

Received on Wednesday, 24 June 2015 08:43:16 UTC