Re: Counter mechanism on boxes or elements?

On 2/22/10 9:17 AM, Tab Atkins Jr. wrote:
> Personally, I think anonymous box generation is effectively an
> implementation detail that authors shouldn't have to worry about.

They're also an ease-of-specification device, not just an implementation 
detail.  The behavior needs to be as if the anonymous boxes were there, 
for the ones the spec describes (and as if they were not there for 
onesthe spec does not describe)

Which means you need to understand the anonymous box stuff as an author 
to understand how your markup will render, and you need to understand it 
as an engine developer to know what output you need to produce.  That's 
as far as it goes.

> such as when you have an inline with a block sibling and block parent.

For example, in this case Gecko does NOT generate any anonymous boxes 
internally (though we're considering changing that).  But the behavior 
still matches, I believe, what the spec calls for here.

On the other hand, Gecko does generate anonymous boxes in cases in which 
the specification doesn't talk about them (for example, if a block is a 
child of an inline, it generates an anonymous block around that inner 
block as a sibling of the two boxes that it generates for the inline). 
Since no such box is described by the spec, the behavior needs to be as 
if that box were not there (which is thankfully not that hard).

-Boris

Received on Monday, 22 February 2010 15:58:01 UTC