Re: [css-display] Next steps

I've read the spec, and have a few comments. Please excuse anything that
may come off as naive or misinformed, this is my first time commenting on
an ED:

Issue 1:  Do we need special bits about some of the interactions with
> display-inside? For example, howdisplay:inline-level block; works? Or does
> that fall out of what exists, and the definitions of Block Layout in 2.1?
> (...or a new Block Layout spec, explaining all the 2.1 stuff more sanely?)


IMO, defining exactly how these mechanisms work seems outside the scope of
the spec. That is, this spec simply defines properties that specify
behaviors defined in Block Layout.

 Issue 2: Is fantasai's proposal for a run-in model sane enough to include
> in this spec?


I would imagine, similar to issue 1, that defining the run-in model and its
respective behavior is orthogonal to this spec. I could be missing
something here.

Issue 3: This property [display-extras] is probably dumb, and at the very
> least has a dumb name. Better names? If I define more one-off weird
> box-generation details like this, should I merge them into a single
> "extras" property like this, or just have them all be separate properties?


Is there a reason that display-extras:list-item can't be better expressed
as display-inside:list-item? What I mean is, display:list-item already
magically expands to: block-level block list-item., and
display:inline-list-item already magically expands to display:inline-level
block list-item, with nothing expanding to any other display-inside value
other than block.

 Issue 4: The general rule for new layout modes seems to be that they're
> block-level by default. However, this conflicts with the default value of
> display-outside, which is inline-level. What's the best way to address
> this? Simplest answer is to just expand this list of special values as we
> go along. Another possibility is to magic up the expansion in a different
> way, so that if the value is just a display-inside keyword, display-outside
> defaults to block-level. If the latter is chosen, we could remove several
> more of the special expansions below (all the ones that are identical to a
> display-inside value).


I'd prefer to magic up the expansion, less chance for errata with another
list of special values to maintain. Also, in the informative list of magic
expansions. I think we should specify what display:none expands to, given
all the other values present in the list. It's exclusion is peculiar.

 Issue 5: Is there a need for a value [for the box property] that
> suppresses box generation for layout purposes, but still generates them for
> the purposes of animations/counters/etc.?


Seems like YAGNI to me, but I tend to be myopic. Is there an existing use
case for this?

Issue 6: [box:]contents currently only has an effect on box generation and
> layout. Other things that care about the document tree are unaffected, like
> counter scopes. Is this what we want?


 I think so. Upon my first reading and colloquial understanding of the
"display" property, box generation and layout is all that display should
effect.

 Issue 7: Is box a good name? What about show? Other suggestions?


I prefer "layout", although we can paint the shed any color you'd like ;-)

Errata:
1. The spec makes references to a display-box property. Those are probably
a carryover for an earlier version of the draft. They should be removed.





On Wed, Sep 4, 2013 at 12:07 AM, François REMY <
francois.remy.dev@outlook.com> wrote:

> One thing is sure, you're on the good place to make comments ;-)
>
> I think what you can do to help is to give one or more precise use case,
> and what you want to achieve. This is probably how you can best guide the
> editors.
>
>
>
>
>
> ± -----Message d'origine-----
> ± De : Mike Sherov [mailto:mike.sherov@gmail.com]
> ± Envoyé : mardi 3 septembre 2013 19:20
> ± À : www-style@w3.org
> ± Objet : [css-display] Next steps
> ±
> ± Considering we recently removed getDefaultComputedStyle() from CSSOM
> ± because CSS Display Level 3 addresses the use case of "what is the
> correct
> ± display value for .show()?", I'm interested in helping get this Editor's
> Draft to
> ± the next status and ready for implementation. 2
> ± questions:
> ±
> ± 1. What can I do to help?
> ± 2. What is the correct forum for providing feedback on the draft? This
> ML?
> ±
> ± Mike Sherov
> ± Chief Technologist
> ± SNAP Interactive, Inc. | Ticker: STVI
> ± http://snap-interactive.com | http://ayi.com
>
>


-- 
Mike Sherov
Chief Technologist
SNAP Interactive, Inc. | Ticker: STVI
http://snap-interactive.com | http://ayi.com