- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 24 Jun 2015 12:22:09 -0700
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: "www-style@w3.org" <www-style@w3.org>
> On Jun 24, 2015, at 10:56 AM, fantasai <fantasai.lists@inkedblade.net> wrote: > >> On 06/24/2015 04:42 AM, Brad Kemper wrote: >> >>>>> 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: >>>> >>>> '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> > > We used to have box-suppress as a shorthand of display. > And then realized that's continuing exactly the problem > we have currently: conflating the display type with > whether the box displays. So we explicitly do not want > this property to be a longhand of the 'display' property. Yeah, I wasn't thinking about how it resets to initial when you don't include it in the shorthand. I still like display-box: none | show | hide. > >> 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 } > > I think you're working off of an old draft. We resolved to recombine > the properties back in September. Not sure how that happened. I guess I've had it in a tab of my browser since before that, or the url autocomplete dot something. > Look over the latest ED? I will. Is it 11 September 2014? That's what "Current Work" is linked to. > (Sorry, > we're just getting around to fixing up the spec so it can be > republished again.) > > ~fantasai >
Received on Wednesday, 24 June 2015 19:22:39 UTC