[whatwg] [css-display] CSS Display Review

(I'm guessing you don't mind if I forward your comments to the ML.
Feel free to scold me for presumptuousness if not. ;)

CCing WHATWG for comments on HTML interaction (or any other comments
they may have); follow-ups to www-style@w3.org.

On 08/29/2016 06:52 PM, Boris Zbarsky wrote:
> On 8/2/16 7:38 PM, fantasai wrote:
>> First one is 'display: contents':
>
> This one is mostly a question for Mats.  That said, I think this
> feature adds a huge amount of complexity, and I expect that some
> of its interactions with HTML are not very clearly specced.  For
> example, what should this do:
>
>   <fieldset>
>     <div style="display:contents">
>       <legend>legend</legend>
>     </div>
>   </fieldset>
>
> and what about:
>
>   <details>
>     <div style="display:contents">
>       <summary>details</summary>
>       Text.
>     </div>
>   </details>
>
> Note that in Gecko the answer is different for those two cases,
> more or less by accident.  Again, it's not clear to me that
> either behavior is right or wrong per spec; the HTML spec basically
> assumes there is no such thing as "display:contents" so its phrasing
>is ambiguous in the presence of "display: contents", iirc.
>
> If we _do_ want to ship this spec, we need to work with the HTML
> editors to sort out these issues.

The HTML spec talks about child elements specifically, not about child
boxes. Furthermore its entire spec, except where explicitly noted, is
operating on the element tree. Therefore afaict, CSS properties--such
as 'display' and its values, whatever they are--should not affect
element relationships.

I've added some clarifying text to this effect. I expect it's not
controversial, but CCing HTML folks in case. :)

> It's also not 100% clear to me how display:contents interacts with
> table anonymous pseudos and whatnot.  It might be good to make that
>more explicit (e.g. point out that the replacement in the tree
> described for display:contents happens before any box generation and
> box tree fixups or something).

Since anonymous box generation takes a box tree and fixes it up,
and these elements don't generate a box in the box tree, they
presumably don't have an effect on the anonymous box generation. :)
Added a note to clarify.

>> Second one is the 'hide' value of the currently-named 'box-suppress':
>>   https://drafts.csswg.org/css-display/#valdef-box-suppress-hide
>>
>>   If you think this is not particularly useful or urgent, I'll defer it.
>
> This seems pretty underspecified. [...]
>
> I do think it's useful to have this, but whether anyone ends up using
> it, I have no idea.
>
>> If you think it's interesting and useful, please let me know your
>> thoughts on the proposed resolutions to the open issue:
>>   https://lists.w3.org/Archives/Public/www-style/2015Jun/0346.html
>
> OK, this answers some of my questions above.  It sounds like hiding a
> cell _does_ rearrange which columns other cells are in, yes? What
> about other interesting layout models (grid, flex, etc)?  What are the
> interactions with those?

Since I'm proposing to define it in terms of abspos, the interaction
would be as defined for abspos in those modes. Grid and flex, specifically,
do not respond at all to containing abspos boxes.

>> Third one is the effect of out-of-flow elements on run-in sequencing:
>>   https://drafts.csswg.org/css-display/#run-in-sequence
>
> I strongly believe we should not do run-in at all.  It's an insane
> amount of complexity for a super-edge-case feature, as far as I can
> tell.  Of course I've said this for years and it doesn't seem to affect
> what the CSSWG is up to....

There remains a demand for the feature, and since we have a *relatively*
sane model for it atm, it's been specced for implementer consideration.
So far my plan is to spec it insofar as I am able, since it is a feature
that's wanted and drop it from the spec if at any point it becomes a burden.

> On the particular question of out-of-flow elements, I have no opinion,
> because I haven't really put in the time to consider the implementability
> of the various options.  And given my take on the overall feature I don't
> think putting in that time would be a good use of my time, sorry.  :(

Heh, okay.

>> Lastly if you have thoughts on implementability of any options in the
>> discussion of the interaction of run-in and ::first-letter, let me know.
>>   https://lists.w3.org/Archives/Public/www-style/2015Feb/0330.html
>
> I think anything involving run-in sucks so much to implement and has
> such low payoff that it should simply not be done. Again, it's not clear
> to me which of the options here sucks _more_ to implement, but they both
> suck a lot.

Alright. If you have no opinion, then probably the best idea is to leave
it undefined until someone tries to implement it...

>> P.S. Fwiw, there are two other open issues, one on syntax:
>>   https://github.com/w3c/csswg-drafts/issues/343
>
> No strong opinions.

OK

>> And one that is, afaict, a vocabulary issue but may affect something
>> (and probably only dbaron knows):
>>   https://lists.w3.org/Archives/Public/www-style/2015Aug/0332.html
>
> Looks like a plain bug in CSS2 to me, but I don't have it all paged
> in well enough to say more...

So far no one I've asked has any idea about this issue, so I'll just
raise it in the WG tomorrow.

~fantasai

Received on Monday, 19 September 2016 22:54:12 UTC