691628 - absolute/fixed-position tables ignore top/bottom CSS for calculating height

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect)

Description

[Jim Porter (:squib)]

Attachment: Testcase

Apologies for the somewhat-convoluted bug title; attached is a test case that, under 7.0, makes a table that spans the height of the viewport. Under 10.0, the table sits at the top taking up the minimum space, as though "bottom: 0;" weren't declared. If you use a block element instead of a table, the element fills the height as expected.

My guess is that this is fallout from bug 10209, though I'm only basing that on the fact that it was checked in around when I saw this issue.

Comment 1

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111003 Firefox/10.0a1 SeaMonkey/2.7a1 ID:20111003003001

I confirm the bug in this build of SeaMonkey. Since it's a Core bug, I assume that -firefox in the status-* flags actually means Gecko (including Thunderbird and SeaMonkey).

Comment 2

[(no longer active)]

Yes, this could be a fallout from bug 10209 or one of its friends.  The question is, what is the desired behavior here?  WebKit and IE seem to agree with the new Gecko behavior.  Opera does not.  Does anybody know what the right thing to do is here?

Also, if this is the undesired behavior, does anybody know where in the mess which we call table height calculation code I should look?  ;-)

Also, kudos to Jim for filing one of the most useful regression bugs that I've ever seen!  Jim, have you seen this regression on real websites?  I'm worried that this might be among the horrible hacks that people use for vertical center positioning.  (Although that would not work on WebKit and IE...)  :(

Comment 3

[Boris Zbarsky [:bzbarsky]]

Hmm.  IE agrees with WebKit here?  Interesting....

Taking CSS 2.1 10.6.4 at face value, the used value of "height" here should end up being the height of the containing block.

But 17.5.3 sort of flat-out contradicts that for tables specifically:

  The height of a table is given by the 'height' property for the 'table' or
  'inline-table' element. A value of 'auto' means that the height is the sum of the row
  heights plus any cell spacing or borders. Any other value is treated as a minimum
  height.

This must be talking about computed height ("auto" in the attached testcase), not used height, since the latter can never be auto.

This probably needs to be escalated to www-style.  :(

Comment 4

[Jim Porter (:squib)]

(In reply to Ehsan Akhgari [:ehsan] from comment #2)
> Also, kudos to Jim for filing one of the most useful regression bugs that
> I've ever seen!

Thanks! :)

> Jim, have you seen this regression on real websites?  I'm
> worried that this might be among the horrible hacks that people use for
> vertical center positioning.  (Although that would not work on WebKit and
> IE...)  :(

I haven't seen this on the web; it's actually just some hacky CSS I was using for a Thunderbird extension[1] that I'll be merging into Thunderbird proper one of these days. Given that it doesn't work in Webkit/IE, I doubt many people are using this particular method on the web, though it's possible that other extensions use it. On my end, I can probably use one of the many other vertical-centering hacks to get what I want. I might even find one that's not quite as ugly!

[1] https://addons.mozilla.org/en-US/firefox/addon/mail-summaries/

Comment 5

[(no longer active)]

(In reply to Boris Zbarsky (:bz) from comment #3)
> Hmm.  IE agrees with WebKit here?  Interesting....
> 
> Taking CSS 2.1 10.6.4 at face value, the used value of "height" here should
> end up being the height of the containing block.
> 
> But 17.5.3 sort of flat-out contradicts that for tables specifically:
> 
>   The height of a table is given by the 'height' property for the 'table' or
>   'inline-table' element. A value of 'auto' means that the height is the sum
> of the row
>   heights plus any cell spacing or borders. Any other value is treated as a
> minimum
>   height.
> 
> This must be talking about computed height ("auto" in the attached
> testcase), not used height, since the latter can never be auto.
> 
> This probably needs to be escalated to www-style.  :(

Posted about this to www-style.

Comment 6

[(no longer active)]

(In reply to Jim Porter (:squib) from comment #4)
> > Jim, have you seen this regression on real websites?  I'm
> > worried that this might be among the horrible hacks that people use for
> > vertical center positioning.  (Although that would not work on WebKit and
> > IE...)  :(
> 
> I haven't seen this on the web; it's actually just some hacky CSS I was
> using for a Thunderbird extension[1] that I'll be merging into Thunderbird
> proper one of these days. Given that it doesn't work in Webkit/IE, I doubt
> many people are using this particular method on the web, though it's
> possible that other extensions use it. On my end, I can probably use one of
> the many other vertical-centering hacks to get what I want. I might even
> find one that's not quite as ugly!
> 
> [1] https://addons.mozilla.org/en-US/firefox/addon/mail-summaries/

Whatever happens here, I suggest that you should not rely on this layout.  :-)

Comment 7

[Alex Keybl [:akeybl]]

[Triage Comment]
We've decided not to track this since we don't know of any regressions on the web right now.

Comment 9

[Boris Zbarsky [:bzbarsky]]

It looks like Opera now does what Gecko used to do and what WebKit and Trident do.

Ehsan, I assume you're not actively working on this, right?

Comment 10

[(no longer active)]

(In reply to Boris Zbarsky (:bz) from comment #9)
> Ehsan, I assume you're not actively working on this, right?

Not right now.  :-)

Comment 11

[(no longer active)]

(In reply to Boris Zbarsky (:bz) from comment #9)
> It looks like Opera now does what Gecko used to do and what WebKit and
> Trident do.

Hmm, what version of Opera did you test this on?  Opera Next still renders the box to be as high as the viewport.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> Opera Next still renders the box to be as high as the viewport.

Yes, precisely.  As do Gecko 9 and WebKit, but not Gecko 10.

Comment 13

[(mostly gone) XtC4UaLL [:xtc4uall]]

Gecko, Trident and Blink/WebKit render attachment 564421 [details] equally now -> INVALID?

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think "If the height of the containing block is not specified explicitly" in CSS 2.1 is intended to mean that the 'height' property of the containing block's element is 'auto'. In which case all browsers are behaving correctly here.