W3C home > Mailing lists > Public > www-style@w3.org > May 2010

Re: [CSSWG] Minutes and Resolutions 2010-04-21

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 7 May 2010 14:18:02 -0700
Message-ID: <x2zdd0fbad1005071418qcb16c620m69d177ca6e663000@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On Fri, Apr 23, 2010 at 10:52 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 4/22/10 11:29 AM, fantasai wrote:
>>
>> Tab: AFAICT, it looks great
>> fantasai: There's a related issue of handling abspos elements
>> fantasai: Boris's original proposal had abspos elements leave behind
>> a "placeholder", which would then affect the anonymous
>> table box generation
>> fantasai: From an implementator's perspective, I can see why. In Gecko
>> each out-of-flow has a placeholder left behind so that we
>> can calculate its static position
>> fantasai: But from an authoring perspective, it doesn't make any sense
>> for the abspos to leave anything behind
>> fantasai: The out-of-flow should just disappear from its original
>> position
>> Tab agrees that it should not affect layout where it used to be (but
>> is no longer)
>
>> fantasai: it's easy to say that the abspos elements don't affect box
>> generation in their former location, but it's harder to
>> stay then what the static position is
>> ACTION: Tab write a proposal
>
> At risk of sounding repetitive, I should note that the behavior I described
> is not just the Gecko behavior but also the Webkit, Presto, and IE8
> standards mode behavior.
>
> So while we can write a proposal, that proposal would ipso facto be at risk,
> right?  Are people ok with that?

Yes, I'm okay with that.  The current behavior is definitely wrong
from an authoring perspective, so I want to at least put in the effort
to get it right, even if practicality means that we end up having to
go with current behavior.

Just to demonstrate the current behavior, I've created an example page
at http://lists.w3.org/Archives/Public/www-archive/2010May/att-0001/test.html.
 (Only FF and IE can even render these correctly, though - both Chrome
and Opera screw up on the pre cases.  Chrome doesn't group the two
rows together into a single table, and Opera wraps every run of
whitespace in an anonymous table-cell.)

In an ideal world, the abspos "bar" cell would *not* create a
table-cell in the table it comes from, so that, for example, in the
top-left case the second row would have "baz" below "bar" (rather than
an "empty" space below bar, where an anonymous empty table-cell sits).

~TJ
Received on Friday, 7 May 2010 21:18:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:27 GMT