- 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