Re: [CSS21] Proposal for a replacement for section 17.2.1 (table anonymous objects)

On 7/20/10 10:16 PM, Tab Atkins Jr. wrote:
> I'm curious about both of these.  This affects only a small piece of
> absolute positioning.

Here's a non-exhaustive list of things the placeholder is used for in 
Gecko for absolutely positioned and fixed-positioned boxes (there are 
some other uses for floats, but we're not talking about those here):

1)  Making sure that the out-of-flow inherits style from the correct
     parent.
2)  Making sure the out-of-flow is destroyed when the thing that
     would have been its parent if it were in-flow is removed from the
     box model.
3)  Making sure that style changes on what would have been the parent
     if it were in-flow are propagated to the out-of-flow.
4)  Determining the auto position of the out-of-flow.
5)  Something about painting; I'm not an expert on that stuff.
6)  Something about pagination of absolutely positioned boxes.
     Again, not my area of expertise.

About the only part of absolute positioning not tied to placeholders is 
the sizing of absolutely positioned frames, and that's the easy part anyway.

You were apparently thinking only about #4?

The point is that if we remove placeholders we need to find other 
solutions to the other things on the list.  Which suggests that we 
shouldn't do that, but....

> Further, it seems that the actual change isn't
> in absposing at all, but purely in table-repair.  The abspos itself
> never sits in the table, after all - the only change is whether or not
> it leaves behind a placeholder cell.

The reason it does that is that there is an actual box that's actually a 
child of that cell in the box tree in Gecko.  That box is used for the 
things I list above.  It could probably be removed, with enough work. 
It could be a child of the table-row (or row-group, etc) directly.  That 
was the "some extensive and scary changes to table layout" alternative.

> (If I recall, though, the reason you opposed this change in the first
> place is that abspos elements always leave behind a placeholder in
> Gecko.

Yep.  At a first glance this may be true in webkit too (see the 
placeholder boxes skipped in various places in InlineFlowBox.cpp), but 
you'd know more than I would about that.

> I don't know enough of the underlying code to know precisely
> how this works, but why is it that the left-behind placeholder *must*
> then be treated as a cell in this situation?  Can it be treated as
> display:none?)

The placeholder is a box.  _It_ is not treated as a cell.  It just ends 
up with a cell around it just like any other box would.

> What possible security issues can result from an abspos element
> changing from "leaves behind a placeholder cell" to "doesn't leave
> behind a placeholder cell"?

That's the wrong question.  The correct question is "What security 
issues can arise from no longer having the invariant that all children 
of a table-row box are table-cell boxes?"  The most obvious is that 
table layout assumes this and other such invariants and casts abstract 
box pointers to concrete class pointers based on contextual information. 
  All instances of this would need to be found and fixed if the 
placeholder box remained but was allowed to be a direct child of table 
container boxes.

>> That's not acceptable to me, and I expect to file a formal objection to that
>> effect.  Again, this is an area where we _right_now_ have interop and you're
>> proposing throwing that away and chasing after theoretical purity while
>> introducing new sources of incompatibility.  Why do we want to do this?
>
> We don't have interop - browsers compute the static position differently today.

Do they?  Testcase, please?  There was fairly good interop on this when 
I last tested it...

> If it turns out that we can't do this, because changing
> implementations will be too hard or there is compat burden, I'll
> accept that.  The web platform is crufty.  But I want to push for
> doing this the right way if at all possible first.

We've accepted worse cruft than this in CSS 2.1 in the name of getting 
the damned thing done and actually out the door.  Again, I think trying 
to go for theoretical purity here is a waste of everyone's time and 
resources, and a distraction from the more important things on our 
plates (like actually dropping features that are not interoperably 
implemented, writing tests, writing spec text for the things that are 
totally underspecified, etc).

But then again, maybe I've just bought into this fiction that we want 
CSS2.1 to actually be done and ready to exit CR....

-Boris

Received on Wednesday, 21 July 2010 03:43:05 UTC