Re: [CSS21][css3-content] counters and table-column / table-column-group

On Thu, May 19, 2011 at 10:04:33PM -0700, "Gérard Talbot" wrote:

> > I append the document I've used for testing,
> > which is also available at
> > http://bowman.infotech.monash.edu.au/~pmoulder/html-tests/counter-suppression.html
> 
> It has validation errors

I was considering mentioning that: it has ol and then the children of
the ol aren't li elements.  The reason I did things that way was to try
to avoid UAs' varying approaches to the interaction between HTML ol/li
elements and display:list-item elements.  (This interaction is left
undefined in CSS 2.1.  The css3-lists working draft gives a proposal
for how this should work, but most UAs hadn't adopted the proposal
last time I tested, and their behaviour varies considerably.)
It may well be possible to write a version that does validate without
introducing extra variation, I didn't try.

> > img:before { content: "[before]"; counter-increment: c 100; }
> > .c100:before { content: "[before]"; counter-increment: c 100; }
> 
> "[before]" in this test is not a good string; "FAIL" would be definitely
> better.
> 
> .c100 in this test is not a good class identifier.

I wrote the document to determine UA behaviour for some things that I
didn't think were clearly specified in CSS 2.1 rather than for
immediate inclusion in a test suite.  (And until the matters are
clearly specified, it would be invalid if included in a test suite.)

Concerning displaying the :before content, I don't believe that it is
in fact a failure, with respect to CSS 2.1 at least.

 From an author's point of view, I think that list item markers and
"Note:"-like decorations shouldn't depend on whether the associated
element is a textual element or a replaced element.

I would guess that the behaviour of Konqueror and its descendants and
Gecko comes from interpreting the word "content" in conform.html's
definition of Replaced Element as including generated content, which
would sound reasonable without considering the rest of that page; but
when I look at the nearby definitions of "content" and then "element",
and when I consider that the old copy of Opera (a UA associated with
CSS co-creator Hĺkon Lie) that I tested does display the :before
content, and the authoring considerations I give above, I think this
was a misinterpretation.  Rather, I think it was just trying to say
that the source element descendants of a replaced element are part of
how the replaced element is defined and aren't subject to this CSS
specification.

A later version of CSS 2.1 added an informative note that "This
specification does not fully define the interaction of :before and
:after with replaced elements", and the current css3-content working
draft says outright that the :before and :after content mustn't be
displayed (but doesn't directly mention the list marker case).  I don't
know the reason for these developments.

> > <p>table-column-group: should suppress 100 and 10000, leaving 1101018.</p>

> If we strictly apply what CSS 2.1 states, then counter c should not be
> incremented with 10 (table-column-group), then with 100 (child of a
> table-column-group), then with 1000 (table-column) and then with 10000
> (child of a table-column),  leaving 1100008.

As I wrote in my previous message (the body of the message that Gérard
is quoting here), I don't think that CSS 2.1 clearly states what value
the counter should end up with.

(But yes, "should" in that sentence in the test document was too
strong.)

pjrm.

Received on Friday, 20 May 2011 07:31:06 UTC