- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 27 Jun 2015 08:25:06 -0400
- To: "www-style@w3.org" <www-style@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>, Bo J Campbell <bcampbell@us.ibm.com>
We had some open issues on clarifying what, exactly, box-suppress: hide
(i.e. display-or-not: hide) does, e.g. wrt anonymous boxes, etc.
The intention of 'hide' is to handle dynamic showing/hiding effects. The
fact that 'display: none' tears down both the boxes and the animation
timer, and also removes the element from any counting scheme were noted
problems with the way 'display: none' works. Also, not tearing down the
box tree can allow some further optimizations in the layout engine.
With this in mind, I propose that:
a) Hiding does not affect box generation. This means that if I hide a
table-cell that caused the generation of a table-row box, that
table-row still exists (and is not hidden) in the box tree.
This means that showing/hiding the box does not impact box generation.
b) Wrt surrounding context, hiding is otherwise equivalent to absolute-
positioning the element into /dev/null: the element maintains its
position in the box tree, but does not take up any space, impact
next-sibling-to-prev-sibling relations, or trigger non-emptiness.
And it is not rendered, so no properties specifying layout or
rendering effects have any impact on anything. (You're free to do
useless layout calculations into a /dev/null-named abspos layer if
you want, though.)
c) Tables actually ignore the hidden box. So, for example, if I hide a
table row, the table lays out exactly as if I had discarded that box.
(Absposes inside tables but not inside table cells impact box
generation in weird ways.)
d) Hiding a box also hides it from speech rendering, unless otherwise
specified with the 'speak' property. (I.e. the 'auto' value computes
to 'none'.)
Thoughts?
~fantasai
Received on Saturday, 27 June 2015 12:39:36 UTC