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

On Tue, Jul 20, 2010 at 6:39 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 7/20/10 8:27 PM, Tab Atkins Jr. wrote:
>>
>> (1) All implementations will have to change slightly, to avoid
>> generating a "placeholder cell" when a run of abspos/fixpos elements
>> have a "tabular container" parent.
>>
>> This isn't as bad as it sounds, though - I believe all implementations
>> have to change already to implement fantasai's original algorithm, as
>> they all interpret the ambiguous text in the current spec in different
>> ways.
>
> A few comments here, just so we're all on the same page:
>
> 1)  This is not a slight change, at least for Gecko.  It requires either a
> complete rewrite of the way absolute positioning is done or some extensive
> and scary (in the "exploitable security bug" sense) changes to table layout.
>  I can't speak to other implementors, obviously, but I don't expect us to
> change this behavior anytime soon.  I also still think that changing it
> would have enough web compat risk given existing interop that it may not be
> able to be changed at all.

I'm curious about both of these.  This affects only a small piece of
absolute positioning.  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.

(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.  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?)

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"?

> 2)  Currently shipped gecko matches my proposed algorithm (after a complete
> revamp of this code and earlier discussion on this list). Insofar as
> fantasai's algorithm matched mine, we would not in fact have to make any
> changes.
>
>> (2) Determining the static position of abspos/fixpos elements with a
>> "tabular container" parent is explicitly undefined in CSS2.1, to be
>> fixed up later in CSS3.
>
> 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.

We want the change because it doesn't make sense today, and it will
make even less sense in the future when other layout modes treat
abspos elements in the correct and sane way, which is completely
ignoring them.

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.

~TJ

Received on Wednesday, 21 July 2010 02:17:51 UTC