- From: L. David Baron <dbaron@dbaron.org>
- Date: Mon, 9 Jul 2012 15:41:05 -0700
- To: www-style@w3.org
On Monday 2012-07-09 18:27 -0400, Boris Zbarsky wrote: > On 7/9/12 6:14 PM, Simon Sapin wrote: > >I did not though of these because, in my implementation, "treated as if > >it had 'display: none'" just means removing/dropping a box object. I > >never keep around a box with the used value set to 'none'. > > Sure; the point is that the computed value doesn't tell you there > will be a box. > > >Anyway, back to the original topic: it is unclear to me whether such > >boxes should affect counters. I probably have bugs in WeasyPrint such as > >a box that can increment a counter before being "removed" in a later step. > > Yeah, all the spec says is: > > An element that is not displayed ('display' set to 'none') cannot > increment or reset a counter. > > (CSS2.1 section 12.4.3). That's not much to go on.... > > I believe in Gecko such elements don't affect counters (because we > never create such boxes to start with, but even if we did counter > numbering has to deal with dynamic removals in a non-print context, > so removing the boxes would renumber the counters). It's actually possible that HTML5 says something on the topic, at least for the hiding mechanisms that are part of HTML or SVG (rather than those that are part of CSS), though I wouldn't know where to find it. This problem is part of the quadratic explosion of cases described in http://dbaron.org/cdi-req/#mixing-elements . I still think we could use a general solution to that problem. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂
Received on Monday, 9 July 2012 22:41:29 UTC