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

On Fri, May 7, 2010 at 7:26 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/7/10 5:18 PM, Tab Atkins Jr. wrote:
>>
>> 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.
>
> Is this really a good use of time, though?  Is this more important than
> other parts of CSS2.1 that need spec and implementation work and are at risk
> (run-in, the rest of the anonymous table stuff, etc)?

The effort of changing the spec to match my expectation is here is
very little.  Certainly other stuff needs attention, but changing
abspos elements from "leave a placeholder" to "don't leave a
placeholder" is pretty small in terms of the table-cell creation algo.


>> 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).
>
> Would it, though?  Whose ideal world?  Right now every single UA I've tested
> that implements this stuff at all has the other behavior.  Do we have any
> data on whether websites depend on that?  Do we have any data on what author
> expectations are?

My ideal world.  ^_^  I don't have any data on if anyone depends on
the current behavior.  If any substantive fraction did, that would be
enough to kick this out and leave us with the currently-specced
behavior.

In terms of author expectations, the expectations of this author are
that an abspos element leaves the same trace behind it as a
display:none element, since that's how it appears to work in every
other context.


> Would you expect the same behavior for floats as for abs-pos?  Why or why
> not?

Without looking at how the property is actually treated in that
context in browsers, I'd expect the float property to have no effect
in a table layout context, just as it has no effect in a flexbox
context.  Floating is only defined in normal flow.

Some quick testing shows that instead, setting float appears to make
the element ignore its display:table-cell value, and thus get itself
wrapped in an anonymous table-cell.  Is that what actually happens in
the layout engine?


> Just to be clear, changing the behavior in Gecko will involve either major
> changes to table layout or major changes to the way out-of-flows are handled
> (or both).  I really don't see that being a priority in the sort of
> timeframe I would assume CSS2.1 is aiming at, given the market reality of
> interoperability with all other implementations.

I acknowledge that it may not be a realistic change, given the current
interop.  But it's one that leads to a more intuitive model, and I'd
like to pursue the possibility at least somewhat.

~TJ

Received on Sunday, 9 May 2010 07:28:33 UTC