W3C home > Mailing lists > Public > www-style@w3.org > October 2010

RE: [css3-tables] Allow freeze of table headings similar to Microsoft Excel

From: Belov, Charles <Charles.Belov@sfmta.com>
Date: Thu, 14 Oct 2010 16:53:30 -0700
Message-ID: <E17F75B6E86AE842A57B4534F82D03769C30A5@MTAMAIL.muni.sfgov.org>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: <www-style@w3.org>

Tab Atkins Jr. [mailto:jackalmage@gmail.com] wrote at Thursday, October 14, 2010 4:19 PM
> On Thu, Oct 14, 2010 at 2:03 PM, Belov, Charles 
> <Charles.Belov@sfmta.com> wrote:
> > I would like to see CSS implement table heading freezing, both 
> > horizontally and vertically, similar to Microsoft Excel.  Available 
> > JavaScript solutions commonly fail in one way or another 
> > and can have 
> > cross-browser issues.  
> >  I do think a CSS solution would be much easier than a 
> > JavaScript 
> > one (not to mention saved bandwidth).
> Indeed, a CSS solution should be much easier here.
> I talked about this a few months ago in the context of a "sticky"
> value for 'position', which would act similarly to relpos, 
> but automatically adjust the position to keep the element on 
> screen as long as its parent was on screen.  You could then 
> use this for <thead>, <tfoot>, and/or the first <th> in each <tr>.

That would have the advantage of being both flexible and generalizable to other elements.

I recognize the following is a UI issue and not a CSS issue, but if this is being done through CSS rather than through JavaScript, perhaps this will encourage UI programmers to be aware of this issue and program so that no content is missed.  

I'll note a headache which occurs for the JavaScript versions of this freezing and which might indicate an additional needed property for CSS -- getting into the sticky area of possible CSS intrusion on browser UI behavior -- is that when such a JavaScript solution has been provided, for example at http://drupal.org/project/issues/search/ or http://www.sfmta.com/cms/mroutes/WeekdayFrequencyGuide.htm:

If I click near the bottom of the scroll bar (just above the down arrow, providing that the up arrow is at the top and the down arrow at the bottom) in the UI, Firefox 3.6 scrolls a full screen. Thus, whatever was just off the screen at the bottom gets obscured by the frozen heading row; the taller the heading row, the bigger the problem.

I note that IE 8 and Safari scroll not quite a full screen, so it is less an issue for those browsers, but still potentially a problem for a sufficiently tall thead or wide row <th>.

The same issue occurs on pressing the Page Down key.

Use of CSS should allow UI programmers to track the height or width of the sticky object  and reduce the distance scrolled accordingly.

Hope this helps,
Charles Belov
SFMTA Webmaster
Received on Thursday, 14 October 2010 23:55:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:39 UTC