Re: [css3] [css21] browser specific CSS

On 4/20/2011 12:15 AM, Boris Zbarsky wrote:
> 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

Thanks.  Reading through there again after my last message I did find 
the case that makes the full width get inherited from the parent, when 
it is not done as a float.  What is confusing, though, is that doesn't 
happen for the table, so it is hard to start at the box model in section 
8, get referred to section 10 for the width calculation, and think that 
after reading that you actually know all the rules.  There is no 
explicit reference to the fact that there is a separate set of rules for 
table-layout (section 17.5.2) which are different than the rules in 
section 10, although there are a few mentions of the _algorithm_ of 
section 17.5.2 in the prose text of section 10... but without a specific 
section reference, when reading section 10, it is very easy to think 
that these rules apply to everything, when in fact they do not.

It would be nice if section 8, when referring to section 10, also 
referred to section 17.5.2.  And it would be nice if section 10 
explicitly mentioned section 17.5.2 since it explicitly refers to the 
algorithm defined there.


>>> 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.

Well, I meant a bug in the code.  Of course, an "undefined" in the spec 
helps make the spec less useful that it could be, and make a greater 
need for browser and version sniffing to compensate for such omission by 
learning and leveraging the actual behavior of actual browsers.

A bug in the code might get fixed in a point release in a few months.  
An undefined in the spec takes a few years longer to wend its way 
through the working group.

>
>> 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.

Yes.  But no way to do that, as far as I can tell.

>
> 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.

Agreed, that isn't desirable.

>
>>> 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.

I'm not surprised... it wasn't particularly well stated.  Let me try again.

The scrollbars are positioned in the padding area, but the size of the 
padding is not reduced, rather the size of the content area is reduced.  
So even though the user would specify an exact width of the content 
area, if overflow is specified as auto, when overflow is needed, the  
content area is reduced from what was specified, by the size of the 
scrollbars.  The padding is retained, albeit shifted a bit in location.  
Yet there is no way to specify "leave room for a scroll bar, in case one 
is needed, but only display it if it is needed".


>> 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.

I might have it backward, but this explanation sounds backward to me... 
when you relayout assuming you don't need a scrollbar, you have more 
width, not a smaller width.  Maybe there are too many cases floating 
around.  Can we handle the case where the table is constrained by its 
parent separately from the case where it is not?

OK, so for the case where it is, the constrained width can be called X, 
and height Y.  Assume, that you need a scrollbar, and that scrollbars 
are 16px wide.  So the table must fit in an area of  X-16px by Y.  The 
height of the table can then be determined by the content, the rows, and 
the widths of the columns.  If it exceeds Y, then the scrollbar was 
needed, and we are done.  If it doesn't, the constrained area from the 
parent is not actually a constraint, and so we subtract the scrollbar, 
and have more area for the table, X by Y instead of X-16 by Y.  I fail 
to identify a case where a table could fit in X-16 by Y, and not be able 
to be laid out in X by Y.

And, actually, the unconstrained case turns out to be the same logic 
flow... there is always a constraint, the total viewport width.

Unless, of course, even the minimal column widths don't fit 
horizontally, and then you need both.  Unless the layout algorithm is 
significantly different that the non-normative one in section 17.5.3, I 
still don't find a case where the relayout without a vertical scrollbar, 
needing more vertical space than the layout with the 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.

Yep, and taking the complication out of Gecko pushes it into Javascript, 
it seems.

> > 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.


Yes, covering up the data was a problem.  But it was a minor problem, 
more of an annoyance... just define an extra column, give it the same 
width as the scrollbar, and leave it empty.  Ta da!  Maybe it could have 
been done with some padding-right in the last column, instead, I didn't 
try that.  But without the old Gecko solution, there seems to be no CSS 
solution.... not one better than old VisiCalc, anyway.

To be more explicit, I either have to "intuit" the right widths for each 
cell, or calculate them in Javascript.  Since data patterns have already 
told me I cannot "intuit" the correct widths, then either I have to let 
the headers scroll out of sight, or hope the user has Javascript turned 
on, and put headers and footers in different tables, adjusting their 
widths to that of the main table after the fact.  Neither is 
particularly appealing, the former is hard on users to understand what 
data is in what columns, and the latter clearly breaks the semantic 
model of tables, and is complex to code.

Is there is a list of use cases that the committee is trying to solve, 
somewhere I could see?

> -Boris

Glenn