Re: Counter mechanism on boxes or elements?

On Mon, Feb 22, 2010 at 3:05 AM, Robert Stam <robert@tallcomponents.com> wrote:
> Dear all,
>
> I have a question regarding Microsoft IE8 test ‘chapter_12\content-021.xht’
> (see below for the [stripped] test):
>
> Elements with display:none or pseudo-elements with content:normal/none (i.e.
> elements for which no boxes are rendered), have no impact on the value of
> counters (counter-reset and counter-increment are ignored). Therefore, it
> seems logical to implement the counter mechanism in the boxes instead of the
> document elements. In this test, due to the generation of an anonymous block
> box, an issue arises.
>
> The :before pseudo element (on div1) generates an inline box that is wrapped
> inside an anonymous block box (because the inner div is a block box). The
> scope of the counter 'test' starts at the inline box. The inner div is a
> sibling of the anonymous block box and is therefore not in the scope of the
> first counter 'test'. The result of the second generated content should
> therefore be 0 instead of 0.0.
>
> If we follow the specification literally, the :before pseudo element
> generates an element as the first child of div1, starting the scope of
> counter 'test'. The inner div element is the next sibling of the pseudo
> element and therefore *in* the scope. From this perspective, the test is
> correct.
>
> If we add “div { display:inline; }”, no anonymous block box is generated and
> the test renders as specified.
>
> Btw, FireFox 3.6, Opera 10.10 en IE8 render 0.0, Chrome 4.0 renders 0.
>
> Question: In the current CSS specification, does the counter mechanism apply
> to the elements/document tree or to the boxes/render tree?
>
> Regarding the fact that elements for which no boxes are generated have no
> effect on counter values, it seems logical to define the counter mechanism
> on the boxes/render tree instead of the document elements. In general, we
> think it would be a good idea to add a remark to the specification to
> clarify the situation above.

Personally, I think anonymous box generation is effectively an
implementation detail that authors shouldn't have to worry about.  I'm
pretty sure that *no one* I know that isn't directly involved in CSS
standards work would know that anonymous boxes are sometimes
generated, such as when you have an inline with a block sibling and
block parent.  Having the behavior of counters vary based on this sort
of detail would cause significant confusion when it occurred, and, I
believe, would make us hesitate to add new types of anonymous box
generation to specs, for fear of disrupting sites that currently
depend on a particular behavior.

My only concern with basing it solely on document tree is that it may
interfere with content-movement properties that exist now or are
planned in the future, such as moving all footnotes from the content
to the bottom of a page.  One would like to scope the counter to each
footnote container, which exists only in the box tree.  This also
doesn't seem like it would be sensical when dealing directly with
things that only exist in the box tree, like the ::before pseudoelem
in the given example.

It feels, then, like this is attempting to solve the wrong problem.
Anonymous auto-generated boxes are causing the issue, so let's solve
it by addressing anonymous auto-generated boxes.  We should specify
that they are transparent for the purpose of counters; that is, they
act as if they did not exist, and instead their descendants were there
in their place.  That would make the current specification correct -
for the purpose of counters, ::before is *guaranteed* to be a direct
child of its superior parent, even if a display mismatch actually
causes an anonymous block to be generated between them.

Does anyone think that we need to reify this concept so it can be
easily and consistently used elsewhere?

~TJ

Received on Monday, 22 February 2010 14:18:41 UTC