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

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.

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

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.

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.

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

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

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

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.

No it shouldn't. See http://www.w3.org/TR/REC-CSS2/tables.html#q2 and, for example, http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-position .

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

Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.

qa contact updated.

SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.

qa contact updated.

Removing qawanted keyword

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.

Filter on "Nobody_NScomTLD_20080620"

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.