Open Bug 53702 Opened 24 years ago Updated 2 years ago

Keep THEAD and TFOOT on screen

Categories

(Core :: Layout: Tables, enhancement, P3)

Product:
Core
Component:
Layout: Tables
Type:
enhancement

Tracking

()

People

(Reporter: BenB, Unassigned)

References

Details

(Keywords: helpwanted, html4, testcase, Whiteboard: specification required)

Attachments

(1 file)

testcase of a long table with thead and tfoot
9.47 KB, text/html
Details 
<quote src="http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.2.3">
Table rows may be grouped into a table head, table foot, and one or more table
body sections, using the THEAD, TFOOT and TBODY elements, respectively. This
division enables user agents to support scrolling of table bodies independently
of the table head and foot.
</quote>

Suggested implementation:
First, render THEAD like TBODY. If the user scrolls down and this hides parts of
the THEAD group, render it with same horizontal position, but with the top of it
having a vertical position of 0 (i.e. being at the very top of the canvas), i.e.
as soon as THEAD hits the top of the canvas, fix it there. However, THEAD must
never cover anything other than the containing TABLE, so fix THEAD as soon as
its bottom hits the bottom of the TABLE.
Similar for TFOOT, but THEAD should IMO have precedence over TFOOT.
Keywords: html4
Suggested behavior in more detail:



IF, for any TABLE,

    the viewport is in a position such that some of the TBODY is visible, but

    such that the {top, bottom} of the {THEAD, TFOOT} would not be at least

    {BODY.margin-top, BODY.margin-bottom} from the {top, bottom} of the viewport

    if laid out as normal table rows,

THEN

    temporarily lay out the {THEAD, TFOOT} as a floating element at a distance

    {BODY.margin-top, BODY.margin-bottom} from the {top,bottom} of the viewport.

    Do not actually lay out the TBODY under the {THEAD, TFOOT}, as this may cause

    undesirable results with a transparent or semi-transparent {THEAD, TFOOT}.



Exception:



IF, for any currently visible TR in the TBODY,

    the sum of {BODY.margin-top + BODY.margin-bottom + height(THEAD) +

    height(TFOOT) + height(TR)} is greater than the height of the viewport,

THEN

    lay out the THEAD or TFOOT (whichever started being visible most recently) as

    if it was normal rows,

    AND IF

        the above sum with that section removed is still larger than the height

        of the viewport,

    THEN

        lay out *both* the THEAD and the TFOOT as if they were normal rows.



I think that just about covers it.
Keywords: html4
Summary: Keep THEAD on screen → Keep THEAD and TFOOT on screen
Keywords: html4
Hmmm.  Is this a good idea?  Do we want to change the *default*?  I don't think 

that was what the HTML spec suggested.


This is a feature I looked very much forward to when I first heard of Mozilla. 
I'm surprised it hasn't been fixed yet. And yes, DBaron, I think it should be 
the default. This is a *very* useful feature. I have several times been reading 
long HTML tables (e.g. BugZilla lists!) and been wishing for this feature. It 
*needs* to be implemented (though it's not nsbeta3+, or even necessary for 
moz1.0).
mpt - I don't understand all the BODY margin-{top,bottom} stuff in your proposal.  
When one scrolls, the margin scrolls off with the content.  So why not at the 
viewport edge?  If the THEAD is offset by the top margin of BODY (why not HTML?  
why not DIV?  why not anything else?), then some of the TBODY contents will also 
be *above* the THEAD.  And I think "fixed" is a better term than "floating" for 
what you want, due to the meaning of both terms in CSS2.

I guess this could be implemented in terms of magic 'display' types such as
'-moz-magic-table-header-group' and '-moz-magic-table-row-group'.

Also, I think what one would want to do is display the head/foot in 2 places at 
once, since we don't want to reflow the document when the head/foot goes into its 
fixed position.

I agree with huftis. It is just what I expect from a HTML4 supporting viewer.

As I asked in news://news.mozilla.org/8qgln1%24iog2%40secnews.netscape.com - what do we propose to do for nested tables, that is, when a table with a thead appears within a (tbody) cell of another table with a thead?  Ideally, one would like the nested table's thead to stick just below the outside table's thead, when the outer table row that contains the inner table is being squeezed under the thead (I don't know whether I'm being clear here).



Or do we assume that nobody will be wicked enough to ever nest a thead-ed table within a thead-ed table?



The same question might hold, in fact, for other absolutely positioned elements which could hide the thead from view.  See for example http://www.eleves.ens.fr:8080/home/madore/.test/table-wicked.html
Assignee: clayton → mozilla
Whiteboard: Awaiting proposal to W3C for defining interaction with CSS.
mpt: This should be proposed as a CSS3 table module feature, since doing what
you describe clashes dramatically with the current rendering model and all
possible outcomes must be defined.

Things to define:
 * Behaviour with nested tables
 * z-indexing (is it absolutely positioned? So does z-index apply?)
 * THEAD and TBODY are not special, tables can be constructed from DIV elements
   or, in XML, from foobar elements, using CSS. Are you defining new behaviours
   for the CSS table-row-group display properties?
 * Behaviour in over constrained situations
 * Interaction with the 'overflow' property and positioned content

Reassigning to reporter for discussion with W3C.
> Ideally, one would like the nested table's thead
> to stick just below the outside table's thead,
> when the outer table row that contains the inner
> table is being squeezed under the thead (I don't
> know whether I'm being clear here).

I think I understand, and agree. It should work exactly as a 'thead' with
several rows.

> mpt: This should be proposed as a CSS3 table module feature,

Yes.

> Are you defining new behaviours for the CSS
> table-row-group display properties?

'display: table-header-group' means display as a 'thead', so I think yes.

David B.: by body.margin-top and body.margin-bottom, I was referring to the same 
margins (with respect to the top of the viewport) that apply when the document is 
scrolled to the top/bottom of the canvas. (It's probably not that notation in any 
relevant language, but I don't care.) My point was, that for aesthetic reasons 
the top and bottom of a document are usually a certain distance away from the top 
and bottom of the canvas, and for those same aesthetic reasons those same margins 
should be applied when fixing the THEAD/TFOOT at the top/bottom of the viewport 
(just as you would, actually, if HTML frames were used instead).

However, that may not be possible for tables which are floated to the left or 
right of text, since the text alongside will still need to scroll while the 
THEAD/TFOOT is fixed. So you may have to go with Ben's original suggestion of a 0 
margin between the top/bottom of the viewport and the top/bottom of the
THEAD/TFOOT.

David M.: for nested tables, you would use the same algorithm as I described 
above, with the following find-and-replace actions:
* `top of the viewport' --> `bottom of the outer THEAD'
* `bottom of the viewport' --> `top of the outer TFOOT'.

Ian: This is an RFE for better HTML support, it is not an RFE for new CSS 
capabilities. This version of Mozilla, unlike previous versions, implements HTML 
using CSS with a generic layout engine; but as far as vanilla HTML support is 
concerned, we shouldn't have to care about that. You wouldn't expect the reporter 
of a bug in any other part of Mozilla to personally fix all the bug's 
dependencies before the bug itself could be fixed; and that shouldn't apply to 
this bug either.

If implementing this HTML RFE in Mozilla requires defining and implementing new 
CSS stuff, because of the way Mozilla does HTML, then surely that's best left to 
those who are experts in such things -- such as yourself and David.
Assignee: mozilla → clayton
Whiteboard: Awaiting proposal to W3C for defining interaction with CSS.
Matthew, with BODY.margin-*, you mean the space that usually exists between the
content (e.g. text) of the docs and the border of the canvas (i.e. usually the
border of the window)? That doesn't apply to scolling. Try it yourself. The doc
us "cutted" directly at the border of the canvas. (Is there a way to prevent
that using CSS, e.g. with |HTML {margin: ...}|? *That* would have to be taken
into account.)

Yes I know it doesn't apply to BODY scrolling, and I didn't say it should; what I 
said was that it should apply to THEADs and TFOOTs if possible, for aesthetic 
reasons.

BenB: yes, margins on body then set body to overflow: scroll and positioned 
fixed with the height of the viewport. Takes some tweaking, but I have a 
test case that shows we do it almost correctly iirc.

mpt: HTML does not define any rendering model, ergo our rendering system 
cannot implement "HTML". We are a CSS rendering system. Older browsers used 
propriatary rendering systems with in-house specifications.

This is not an HTML RFE. That's an important point! HTML does not have 
rendering rules. In fact, since we DO "support scrolling of table bodies
independently of the table head and foot", we even completely support the 
suggestion in the spec!

To implement the ADDITIONAL and none-standard feature proposed, one needs a 
very specific specification which takes into account all the situations it
can find itself in. This bug does not have such a specification, thus it cannot 
currently be implemented. Since we are a CSS browser, the spec has to be in
terms of CSS if we want to implement it.

Personally, I understand the idea and can see its value, but do not see how
it could interact with all the situations it could find itself in. Thus I do
not intend to try to specify it. In particular I do not understand the margin
stuff that you have mentioned.

Reassigning to nobody@mozilla.org, since no engineer can implement this until
behaviour is defined, and no-one has accepted to write a specification.
Assignee: clayton → nobody
Component: Layout → HTML Element
Keywords: helpwanted, qawanted
QA Contact: petersen → lorca
Whiteboard: specification required, testcase needed
> HTML does not define any rendering model

<quote src="http://www.w3.org/TR/REC-html40/present/graphics.html#h-15.2.1">
I: Renders as italic text style.
B: Renders as bold text style.
BIG: Renders text in a "large" font.
</quote>

I know what you are saying, but there are expectations how to render certains
elements in 2D graphical clients.

> This is not an HTML RFE

It is an RFE how to better make use of the information in the HTML source to
improve the rendering. Thus, I would call it an HTML RFE.

> but do not see how it could interact with all the situations it could find
> itself in [...] Reassigning to nobody@mozilla.org, since no engineer can
> implement this until behaviour is defined

As Matthew said, it is not the job of the bug reporter or any other interested
party to make a complete spec. If somebody makes an RFE "recognize URLs in
plaintext", it is my job to figure out how to do it. Because
- It is clear what he wants
  The reported wants to be able to click on links. He doesn't want to worry
about edge cases like an URL ending in a "," or similar. he just wants me to get
the common case right, and leaves the rest up to me. IMO, ithis is the roght
approach, because I am used to create such "specifications" and also know
possible code-level problems (which might make a certain spec impossible to
implement in the current code) best. E.g. I know that libmime is line-oriented
and thus will have a hard time to recognize links across lines.
- It does not seem to be impossible or overly hard to implement.

Traditionally, there is not much of a "spec" or "design" phase in the Mozilla
project. A requirement is stated (oftenin form of a bug), and then, sometime,
the "implementation" starts, which includes detailed spec and design.

Similar for this bug. Based on the above comments, reassigning to default owner.
Assignee: nobody → clayton
> If somebody makes an RFE "recognize URLs in plaintext"

That is completely defined, though, since we have a URL RFC. Ergo, the work
of defining behaviour is already done.

> Traditionally, there is not much of a "spec" or "design" phase in the Mozilla
> project. 

Nonsense. The HTML part of Mozilla was in "design" phase for ~7 years. The CSS
part was in design phase for ~3 years. The XUL part was in design many months
prior to implementation, and continues to be in design now. The preferred menu 
system (not the poor one which is implemented) was in design for months before
work started. And so on and so forth.

When you have a feature that is implemented without a spec, QA cannot test it.
ESPECIALLY with something as complicated as a new feature interacting with CSS.


> A requirement is stated (often in form of a bug), and then, sometime,
> the "implementation" starts, which includes detailed spec and design.

Right - *which includes detailed spec and design*. Someone needs to do that
next. Nobody at Netscape will do so in the forseable future, given our current
priorities (namely:, standards compliance, performance, footprint, stability,
in reverse order).

Triagine clayton's list. Since this was not accepted by nobody@mozilla.org,
sending to nobody@netscape.com. Since this is in the Netscape pile, triaging
per PDT priority guidelines.
Assignee: clayton → nobody
Priority: P3 → P5
Whiteboard: specification required, testcase needed → specification required, testcases needed
> That is completely defined, though, since we have a URL RFC. Ergo, the work
> of defining behaviour is already done.

No, read the spec and compare reality.
Assignee: nobody → nobody
Priority: P5 → P3
Let's take the discussion about the spec to n.p.m.layout. I started a thread called "Spec 
for bug 53702 needed".
> Since we are a CSS browser, the spec has to be in
> terms of CSS if we want to implement it.

thead { display: table-header-group; }?

This *should* work, just like tfoot { display: table-footer-group; } is always 
displayed at the *end* of table, even though it comes *before* the 'tbody' in 
the DOM.

[David Baron]
> No it shouldn't.

What shouldn't (do what)?
> thead { display: table-header-group; }?
> 
> This *should* work.

No it shouldn't.  ...
>> thead { display: table-header-group; }?
>> 
>> This *should* work.
>
> No it shouldn't.  ...

Why not? The CSS rec. says:

"These values cause an element to behave like a table element (subject to 
restrictions described in the chapter on tables)."

"table-header-group (In HTML: THEAD) 
Like 'table-row-group', but for visual formatting, the row group is always 
displayed before all other rows and rowgroups and after any top captions. Print 
user agents may repeat footer rows on each page spanned by a table."

And the sample style sheet (Appendix A) says:

THEAD           { display: table-header-group }

Then *why* shouldn't it work?
It doesn't imply 'position: fixed' or values for 'left' and 'top'.  Your
proposal conflicts with the definition of 'position: static'.
> It doesn't imply 'position: fixed' or values for 'left' and 'top'.
> Your proposal conflicts with the definition of 'position: static'.

So you don't think table headers and footers should be repeated at the top and 
bottom of printed output either?

And do you think table footers should be displayed at the top of the table 
(that's where they are in the DOM) (i.e. display: static)? 

The text implies that the element should be displayed as a table header. 
According to HTML 4.01, "User agents may exploit the head/body/foot division to 
support scrolling of body sections independently of the head and foot sections. 
When long tables are printed, the head and foot information may be repeated on 
each page that contains table data."

You don't need to use 'position: fixed' or any other CSS property. You just 
need (well, "may") render it in a way so that the user can always see the table 
header cells when looking at the table body cells. And quite a few people think 
this is a good idea.
Nominating for Mozilla 1.2 ...
Keywords: mozilla1.2
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
qa contact updated.
QA Contact: gerardok → bsharma
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.
Component: HTML Element → Layout
QA Contact: bsharma → moied
qa contact updated.
QA Contact: moied → amar
 Removing qawanted keyword
Keywords: qawanted
Component: Layout → HTMLTables
I noticed that a testcase is wanted. You can use the one at
http://www.bluesweb.org/bands.phtml/B (and every other page at this website).
I've used THEAD and TFOOT for the nice rounded metallic plaque that contains the
data.

They're used in print-preview, where a thead and tfoot is repeated on every
page. You can also see it when you jump to the end of the page before it's
completely downloaded.
Keywords: testcase
Whiteboard: specification required, testcases needed → specification required
Filter on "Nobody_NScomTLD_20080620"
QA Contact: amar → layout.tables
Tiis can be achieved by setting a height on the rowgroup and overflow:auto on the tbody, however there a couple of bugs that hork the overflow on row groups.
That would allow the table body to scroll while keeping the headers visible, but I think previous commenters were describing a way of keeping the headers fixed while scrolling the *page*, not just the table body.
Depends on: 975644
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: