(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-st...@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
