W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [css3] [css21] browser specific CSS

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 19 Apr 2011 22:52:46 -0400
Message-ID: <4DAE4A7E.3030503@mit.edu>
To: www-style@w3.org
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

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

No.

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

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

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.

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

-Boris
Received on Wednesday, 20 April 2011 02:53:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:39 GMT