Re: [css3] [css21] browser specific CSS

On 4/19/2011 7:52 PM, Boris Zbarsky wrote:
> On 4/19/11 5:59 PM, Glenn Linderman wrote:
>> However, Firefox 4.0 has explicitly removed this capability, per its
>> release notes, without a stated reason.
>
> For what it's worth, the reasons are in 
> https://bugzilla.mozilla.org/show_bug.cgi?id=28800

Thanks for the reference.  I had tried to search bugzilla, but didn't 
find this bug.  Indeed, HTML4 did mention "allow" support of scrollable 
<tbody>, but Mozilla was the only browser I know of that ever tried.  It 
saddens me to think of this capability, which is implemented in every 
spreadsheet program I've ever seen, being impossible to achieve using 
CSS and HTML only.  Borrowing/understanding/tweaking a few hundred lines 
of Javascript, presuming it is even enabled, to compensate isn't a 
pleasant thought.  I'll take the bug's word for the complexity that was 
removed as a result.

>> Is there a pure CSS solution for this, like was available in Firefox 
>> 3.x?
>
> No.

Thanks for the confirmation, sad as it is.

>
>> 1) no CSS technique for scrolling table body rows.
>
> Yep.
>
>> 2) without a float, directive, the scrollbar is far away from the data
>> being scrolled.
>
> Well, it's however far the width of the block puts it, right?  Whether 
> that's too far or not depends on the data and the block width.


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.


>
>> 3) with a float, different browsers render the table differently, even
>> though there is no width constraint.
>
> 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.

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

I could make the table full viewport width -- then the scrollbar would 
be related to the table... but the table would look stupid, stretched 
out so far.

So are there any plans to add CSS features that allow for making a 
reasonable, consistent layout for something this basic?  This surely 
explains why so many web sites do browser sniffing, besides the fact 
that past (still in use) browsers didn't implement the standards 
completely or correctly.

This doesn't seem to me to be a problem that should require Javascript 
to solve.


>
> In the case of Gecko in particular, the problem is that when we're 
> doing shrink-wrap sizing of a block with overflow:auto there is no 
> reasonable one-pass solution.  Either you assume the block _will_ end 
> up with a vertical scrollbar, and then it ends up too wide (in the 
> sense of there being blank space at the end of every line) in the 
> cases when it doesn't (which you don't know until you pick a width and 
> lay out at that width!) or you assume that it _won't_ end up with a 
> vertical scrollbar and then it ends up too narrow (in the sense of 
> some lines wrapping that might not have needed to if the block were a 
> bit wider) in the cases where one is needed.  Gecko does the latter, 
> which is why you see the behavior you see.  If your markup used 
> overflow-y:scroll the issue would not arise (but of course the 
> scrollbar would always be present).
>
> 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, and the 
experimentation I've done seems to confirm that.  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.  That still leaves me with using CGI or Javascript to sniff data 
sizes, and choose whether or not there is enough data that it should be 
scrolled, and emit different HTML or tweak the DOM for those two cases, 
or to put up with the scrollbar even if there are fewer rows.

And, of course, there seems to be no solution except Javascript or fixed 
size columns (so the headers and footers would be different tables, with 
same-size columns) for keeping the column headers/footers displayed 
while scrolling, and also have them aligned with the data.  Or am I 
missing some CSS feature to allow/specify multiple tables to have the 
same column widths?

I suppose for a 10 row viewport, I could spew a header row every 10 
rows, so that when one scrolls off, another would scroll in.  That's not 
a particularly appealing solution, especially for print, although I'm 
unaware of any demand for print for this particular application.

> Possible UA solutions here include the use of a multipass algorithm in 
> which we detect that whether a vertical scrollbar is needed when 
> layout is done doesn't match what we assumed at first and lay out with 
> the other assumption.  But note that this is subject to cycles (e.g. 
> if you assume a vertical scrollbar is needed and increase the width 
> accordingly when doing the layout, discover it's not actually needed, 
> relayout at width reduced by scrollbar width and discover than in that 
> case a vertical scrollbar _is_ needed).

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.  Would seem to require that something in the table has a very 
strange sizing dynamic.

> -Boris

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.  It does seem like once all the data is 
available, though, that the column widths/heights can be calculated, and 
then it shouldn't be any harder than VisiCalc to do the display.  Great 
progress we've made in last 30 years!  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, without rewriting VisiCalc in Javascript.