Re: [css3] [css21] browser specific CSS

On 4/20/11 2:53 AM, Glenn Linderman wrote:
> It is not at all clear why the width of the containing block is the
> width of the viewport, when the width of the table is much smaller.

See http://www.w3.org/TR/CSS21/visudet.html#blockwidth

>> This is because shrink-wrap sizing is not actually defined in the
>> specification.
>
> I figured the answer would be something like this... something that is
> undefined.  I was hoping for it to be a bug, then there would be some
> chance it would get fixed someday.

Well, it being undefined might be a bug in the spec, yes, in that a 
future spec revision will define it.

> So without the ability to sniff the browser in CSS, I cannot attempt to
> compensate for the visible stupidities.  Without the float, it isn't
> even obvious that the scrollbar way over there on the right is even
> related to the table or should affect it.  With the float, some browsers
> look OK, and some do not.  But even if I could sniff the browser, CSS
> provides no way to define the containing block to be the width of the
> table + width of the scrollbar (no arithmetic, last I checked).

The problem is that "the width of the table" depends on the width of the 
block around the table.

What you really want is to set the block's width to the tables 
max-intrinsic width plus the scrollbar or something.

You can get partway there in Gecko by setting the table's width to 
-moz-max-content, which keeps the table's cells from wrapping but 
doesn't change the width of the float in your case, so you get a 
horizontal scrollbar.  That's not terribly desirable either.

>> Possible author solutions here are to use overlow-y:scroll or to
>> actually allow enough padding for the scrollbar, so it doesn't have to
>> eat into the content area.
>
> My understanding is that although scrollbars are positioned in the
> padding area, they are sized to be removed from the content

I'm not sure what you mean there.

> Specifically turning on overflow-y: scroll does work in the 4 browsers I mentioned, so that
> the float version of the table looks sensible... when overflow is
> needed.

Yes, that's the main drawback there.  I meant to mention that.

> Or am I missing some CSS feature to allow/specify multiple tables to have the
> same column widths?

You're not.

> Yes, that sort of cycle could happen theoretically, although I cannot
> imagine a case using this sort of tabular data where making the table
> wider (by the width of the removed scrollbar) would increase its
> height.

You have that backwards.  If the containing block assumes that it needs 
a scrollbar and lays out at a width that is actually wider than the 
table's intrinsic width and the table has a width that depends on its 
parent then this can cause the table's height to get _smaller_ (because 
it's being laid out wider).  And at that smaller height it does not need 
a scrollbar.  So you relayout assuming you don't need a scrollbar, but 
at that smaller width you get a bigger height which does need a scrollbar.

> It seems a sad state of affairs that something as common as a table
> requiring that much complexity to implement.  Granted VisiCalc, which
> ran in 32KB RAM, implemented scrolling tables, but the column
> widths/heights were specified, and the scrollbar was always present, so
> that is a simpler case.

Indeed; that's a case you have working right this second across browsers 
using "overflow: scroll"!

> It does seem like once all the data is
> available, though, that the column widths/heights can be calculated

Those depend, in general, on the width of the table's containing block. 
  The _intrinsic_ widths can be calculated, but those may not be the 
widths actually used during layout.

This significantly complicates things, sadly.

 > Computers are thousands of times
> faster, and have thousands of times as much memory, and we have lots of
> new standards, and we can't even control the display of a table in a
> browser

Sure you can.  You just might have to be more explicit than you'd like 
to be.  ;)

I do think it would be good to have a solution for this use case, but 
note that Gecko's old solution suffered from a lot of the problems we've 
talked about here (e.g. there was nowhere to really put the scrollbar on 
the row group, so it covered up some of the table's data).  So that 
solution is not what we want here.

-Boris

Received on Wednesday, 20 April 2011 07:15:45 UTC