- From: Simon Sapin <simon.sapin@kozea.fr>
- Date: Sun, 17 Jun 2012 19:59:41 +0200
- To: Anton Prowse <prowse@moonhenge.net>
- CC: CSS 3 W3C Group <www-style@w3.org>
Le 17/06/2012 12:37, Anton Prowse a écrit : > I'm not sure what it means to apply 'counter-increment' and > 'counter-reset' to a box, since they're not formatting controls in the > typical sense and their functionality is scoped only in terms of the > document tree. (In particular, a table caption is always in the scope > of those properties when they're set on a box with display:table.) What > would be the difference if you "applied" them to the table box in your > implementation? Of course, if an implementation relied on converting > that scoping mechanism into one which acted on the box tree then I > understand why it would be necessary to apply the properties to the > wrapper box... but that would be an implementation detail, surely. Scoping counters on boxes rather than elements makes sense because of: http://dev.w3.org/csswg/css3-lists/#counters-without-boxes Then it depends on an implementation details: whether counter values are resolved before or after table wrappers are created. Currently WeasyPrint does it before (so having counter properties in the list has no effect.) But that may change in the future: resolve during the layout so that elements can use page counters, and page-margin boxes non-page counters. The use case I had in mind was something like this: table { counter-increment: table-num } table:before { content: "Table n° " counter(table-num); display: table-caption } /* Still increment: */ table.nocaption:before { display: none } > For me, a simple guiding principle is that the principal box [roughly: > the outermost one] of the table "structure" is the wrapper box, and so > properties which influence the relationship between the structure and > the world around it should apply to the wrapper box. Other properties, > when non-inherited, should typically apply to the table box, since > caption boxes can styled independently. This principle sounds good. > To be honest though, I'm not sure that there's really any golden rule > here. The reason that the (non-inherited) 'border' property applies to > the table box and not to the table wrapper box, for example, is merely > because that's what matches the most common typographic need. Yes, these are principle, not rules. (Though I’m not sure of the precise English word.) Principles only help to decide for each individual property. Anyway, I’m not sure any of this is really important for interop. My main point in this thread is that implementations may need to extends the list to be consistent with themselves. (If only with CSS3 properties.) Regards, -- Simon Sapin
Received on Sunday, 17 June 2012 18:00:12 UTC