Closed Bug 674214 Opened 13 years ago Closed 3 years ago

Add the ability for rowgroups to scroll (e.g. <tbody style="overflow:auto">)

Categories

(Core :: Layout: Tables, enhancement)

Product:
Core
Component:
Layout: Tables
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: keiths, Unassigned)

References

Details

(Whiteboard: read comment 16-17) 

User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
Build ID: 20100914125854

Steps to reproduce:

In Firefox 4 and above, bug 28800 removed the ability for rowgroups to scroll.  This breaks many, many websites and violates the html standard:  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."



Actual results:

Tables no longer scorll


Expected results:

Table should scroll
I think this is invalid per CSS2.1, but that spec is such a mess I can't be sure. Otherwise, this would be wontfix.
Component: General → Layout: Tables
OS: Other → All
Product: Firefox → Core
QA Contact: general → layout.tables
Version: 4.0 Branch → Trunk
That's just INVALID, bug 28800 comment 37:

<fantasai> it's in line with spec and other implementations

If fantasai thinks it's in line with the spec, it IS in line with the spec, I'd say...
Thanks for the pointer.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
(In reply to comment #0)
> ... and violates the html standard: 
> http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.2.3.

... and HTML4 is mostly irrelevant for implementations these days.
We are here now:  http://www.w3.org/TR/html5/
I should note that http://www.w3.org/TR/html5/ is mostly irrelevant to implementations as well, we're at http://whatwg.org/html now (excluding Microsoft, that is).
(In reply to j.j. from comment #2)
> That's just INVALID, bug 28800 comment 37:
> 
> <fantasai> it's in line with spec and other implementations
> 
> If fantasai thinks it's in line with the spec, it IS in line with the spec,
> I'd say...

Argument from authority.

About HTML 4.01 vs. HTML5: Red herring.  This is a CSS issue, not a HTML issue.  Stylesheets apply to more markup languages, and Gecko can render more, than just (X)HTML.

The CSS 2.1 argument (also presented as rationale for removing the feature) is a fallacy because there is not one Specification for CSS, there are at least two: CSS 2.1 and CSS3 (split into several modules).

CSS3 Box Model includes `table-row-group' elements like TBODY in the list of elements that the `overflow' properties apply as it says they apply to "non-replaced block-level elements and non-replaced ‘inline-block’ elements".  Different to CSS 2.0 and 2.1, CSS3 Box Model says "A block-level box is a box that has a used value for ‘display’ of ‘block’, ‘list-item’, ‘table’, ‘table-*’ (i.e., all table boxes) or <template>."  The initial value for the TBODY element in the default Gecko stylesheet is `table-row-group'; it is clearly a "non-replaced block-level element" to which the `overflow' property should apply.

<http://www.w3.org/TR/css3-box/#overflow>

If the argument for not restoring/implementing this feature is that CSS3 Box Model is only a Working Draft at this point, and we don't implement Working Drafts, when is this useful feature going to be available (to come back to Gecko, really), then?  A W3C Specification should have implementations to become a Recommendation:

<http://www.w3.org/2005/10/Process-20051014/tr#cfi>

And if the argument for not restoring/implementing this feature is that CSS3 Box Model is only a Working Draft, and we don't implement Working Drafts, then why are all these other CSS3 features more or less supported by Gecko: Selectors (PR), Backgrounds and Borders (CR), Color (PR), Fonts (WD), Multi-Column Layout (CR), to name just a few?

Also note that CSS3 Box Model says that in its "Status of this document" section that it "should eventually replace corresponding parts of the revised CSS level 2 specification [CSS21]" so the argument that says that we are not implementing this because CSS 2.1 is more recent than CSS3 Box Model is flawed as well.

Neither fixed column widths nor client-side scripting are an adequate replacement for what was a built-in feature.  Please reopen this bug and restore the feature.

BTW, there is a similar bug report for WebKit: <https://bugs.webkit.org/show_bug.cgi?id=3239>


PointedEars
Thomas, CR is a call for implementations.  So once something is in CR or later (that includes PR) you definitely want to be implementing it, unless you think it shouldn't be part of the standard at all.  That covers most of the things in your list, if you note.

The real argument here is that we implement things that we either think won't change much before standardization or that we need implementation experience with to proceed towards standardization.  Neither is true of the CSS3 Box draft you cite: it's years out of date, the working group feels that it's got some serious issues, and worse yet no one is working up pushing it through to a standard.  See http://dev.w3.org/csswg/ for the list of things the working group _is_ working on and note the absence of css3-box.
> > If fantasai thinks it's in line with the spec, it IS in line with the spec,
> > I'd say...

> Argument from authority.

This was mostly ironical because of the complexity of the CSS spec which less people seem to recognise fully (myself at last). Next time with smiley :-)

> About HTML 4.01 vs. HTML5: Red herring.  This is a CSS issue

Indeed! The HTML4 argument was brought up by the bug reporter.
> Argument from authority.

Oh, one thing.  Given that the "authority" happens to be a CSS working group member who actually has some idea of what the concrete plans for css3-box are (unlike everyone commenting in this bug), it might be worth assuming that the "authority" is in fact someone worth listening to, since it directly affects people's assumptions about the stability of the current css3-box text.
(In reply to Boris Zbarsky (:bz) from comment #7)
> Thomas, CR is a call for implementations.

Patently untrue.

"6.2.3 Candidate Recommendations (CR)
[…]
There is no requirement that a Working Draft have two independent and interoperable implementations to become a Candidate Recommendation. Instead, this is the phase at which the Working Group is responsible for formally acquiring that experience or at least defining the expectations of implementation."

> So once something is in CR or later (that includes PR) you definitely want to 
> be implementing it, unless you think it shouldn't be part of the standard at
> all.

Your logic is flawed, and you should know it.  That what I quoted holds true does not mean there cannot be implementations before that stage.

> That covers most of the things in your list, if you note.

But not all, if you read more carefully.

> The real argument here is that we implement things that we either think
> won't change much before standardization or that we need implementation
> experience with to proceed towards standardization.  Neither is true of the
> CSS3 Box draft you cite: it's years out of date, the working group feels
> that it's got some serious issues, and worse yet no one is working up
> pushing it through to a standard.  See http://dev.w3.org/csswg/ for the list
> of things the working group _is_ working on and note the absence of css3-box.

Pray tell, who is going to push it if not browser vendors?

The real problem here is that you have already used this argument and others to rationalize in hindsight removing the useful feature, which has *worked* (with slight adjustments, of course) in Gecko before (see <http://PointedEars.de/es-matrix#features> for an example).  Back then you have "asked" that people stop requesting this feature in that bug, and open a new bug instead.  A new bug has been opened with the result that it is marked RESOLVED INVALID.  Great.

You can see that people (not just me) want this feature (and we don't want no ugly markup-duplicating scripts to have it!), and all you can do is to deny that this is even an issue.  Your rationale is that it is not considered by the W3C WG at this time.  Well, I guess that if certain vendors had waited until the W3C CSS WG got their act together, we would not have gradient support and other great CSS features (some with prefixes, but working) anywhere by now.
(In reply to Boris Zbarsky (:bz) from comment #9)
> > Argument from authority.
> 
> Oh, one thing.  Given that the "authority" happens to be a CSS working group
> member who actually has some idea of what the concrete plans for css3-box
> are (unlike everyone commenting in this bug), it might be worth assuming
> that the "authority" is in fact someone worth listening to, since it
> directly affects people's assumptions about the stability of the current
> css3-box text.

FUD, and still fallacious, of course.  We have only the statement from this member that not supporting `overflow' on `table-row-group' elements is in line with CSS 2.1.  Which is correct, but means nothing for the future.

Well, from MN^Wpast experience, I have a fairly good idea what is going to happen:

1. You remove the feature from Gecko code for good (or have you already?).
2. Competitors will close their related bugs INVALID, referring to your decision ("nobody implements it").
3. In a decade or so, if the W3C is still considered relevant, after all the other CSS features that nobody really needs have become RECs, CSS3 Box Model will have finally become a CR.
4. The W3C WG will request experience from implementations.  There will be none.
5. The W3C WG will adapt the CSS3 Specification text to exclude `table-row-group' from the definition for block-level element accordingly, in order to advance to PR.
6. CSS3 Box Model PR will become a REC.
7. Your implementation will be in line with the new REC, and you can claim CSS3 compliance.
8. People will still be using dirty hacks to achieve the desired effect, or it will not be used at all (which is equally bad).

or

2. WebK^WCompetitors will ignore your illogical reasoning, and implement this feature (first with prefix).
4. If the W3C is still relevant by then, the W3C WG will request experience from implementations (otherwise Hixie will have just defined it in CSS5).  One major implementation having paved the way, others will have followed, and there will be several implementations at this point; but Gecko will not be among it.
5. If you are still there, you will rush to implement this feature in order to claim ("living") standards compliance.
8. Due to lack of experience, the feature will be borken for several versions in Gecko, so if Mozilla is still considered relevant at that point, few people will be using it, saying that it does not work properly in all the major browsers.

I can't believe you want any of this, but I'm not so sure anymore.
I'm not going to bother replying point to point, as that doesn't seem helpful, but I've got to point out one thing. You quoted

"6.2.3 Candidate Recommendations (CR)
[…]
There is no requirement that a Working Draft have two independent and interoperable implementations to become a Candidate Recommendation. Instead, this is the phase at which the Working Group is responsible for formally acquiring that experience or at least defining the expectations of implementation."

and then interpreted it incorrectly. No implementation experience is required to *enter* CR, but it is the phase in which that experience is *sought*. That is, it is the phase where browsers are expected to implement the specification. See also <http://www.w3.org/TR/CSS/#testing>.
(In reply to comment #10)

> Back then you have "asked" that people stop requesting this feature 
> in that bug, and open a new bug instead.  

Anyone asked to open a new bug? I don't see that in bug 28800.
I see that people were asked to make suggestions to www-style
http://lists.w3.org/Archives/Public/www-style/
(In reply to Ms2ger from comment #12)
> I'm not going to bother replying point to point, as that doesn't seem
> helpful, but I've got to point out one thing. You quoted
> 
> "6.2.3 Candidate Recommendations (CR)
> […]
> There is no requirement that a Working Draft have two independent and
> interoperable implementations to become a Candidate Recommendation. Instead,
> this is the phase at which the Working Group is responsible for formally
> acquiring that experience or at least defining the expectations of
> implementation."
> 
> and then interpreted it incorrectly.

No, I did not.

> No implementation experience is required to *enter* CR,

And I did not debate that.

> but it is the phase in which that experience is *sought*. That is, it is the 
> phase where browsers are expected to implement the specification.

s/to implement/to have implemented/

Which means an implementation, albeit experimental, should already exist at this point, otherwise no experience can be reported.  I rest my case.
> Patently untrue.

Uh...  The whole point of CR is to say that if there aren't any implementations yet then some had better appear now for a spec to progress.  So I have no idea what you think is "patently untrue".

> That what I quoted holds true does not mean there cannot be implementations
> before that stage.

What I said is that once something is in CR you _definitely_ want to be implementing it (since you seemed to be claiming in comment 6 that we were doing something wrong by implementing certain features which are in CR or PR).

You can of course have implementations of things before they reach CR, as long as they are vendor-prefixed.  That happens all the time, for things that seem to need implementation experience or that just look like they might be pretty stable.

> But not all, if you read more carefully.

I didn't say it covered all, now did I?  And I explicitly addressed the one exception.  Stop the silly straw-man arguments.

> Pray tell, who is going to push it if not browser vendors?

Any organization is welcome to join the W3C, last I checked (for a fee, as all industry consortia).

Furthermore, the CSS working group has an open mailing list on which anyone can comment.

So the answer to your question is "anyone who cares about it".

> A new bug has been opened with the result that it is marked RESOLVED INVALID.

Oh, that's just bogus.  The bug is a feature request, and I have no idea why it was marked invalid.  Reopening.  Though honestly, it may be better to open a new clean bug and forbid ms2ger from touching it, since this bug has so much noise in it now it's completely unusable for the actual purpose it's filed for.  :(
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
One more mistake from comment 10 and comment 11 that I think is important to point out.  The old code for this in Gecko didn't "work" except by accident.  It was completely broken by design and caused all sorts of problems throughout the table layout code.  If we implement this again, it will need to be done in a totally different way.
And just to be clear, a decent spec for how this should work would be a big step forward here.  Certainly any patch would need such a spec, whether written by the patch author or not, to get reviewed, since there's no way to check whether the patch does what it means to otherwise.
Severity: normal → enhancement
(In reply to Boris Zbarsky (:bz) from comment #16)
> point out.  The old code for this in Gecko didn't "work" except by accident.

I wouldn't quite say that -- some people did intend it to work.  The code just had a lot of problems.
Within the firestorm of this issue.  The pluses just exceed the minuses for my applications.  Please put this back into the product. Thanks.
Another request do reenable it. Matter of fact is it is used widely out there and now broken. It's standardized, which Mozilla holds so dearly, but was removed from Gecko, which sort of contradicts the "if it adheres to standards and worked before it will work after any update whatsoever" statement that's been used to death when defending the new rrp.
(In reply to Martin Jungowski from comment #20)
> Another request do reenable it. 

There is nothing to "reenable". Read this bug and bug 28800.
Comment 19 and comment 20 are pointless. Boris described what's to be done. There is a lack of CSS specification.

Place your proposals here:
http://lists.w3.org/Archives/Public/www-style/
Whiteboard: read comment 16-17
Comments like "Comment 21" some what disturbs me.  As far as I can tell, from the bug 28800 items, there was never a survey of the user community to determine if the functionality was being used and what would the impact be to their application in removing it.  Therefore, it shows a lack of consideration for your customers. 

My point was to express the need here to the developers, the ones who removed it.
(In reply to r.rhodes from comment #19)
> The pluses just exceed the minuses for my applications.

This is a real and valid usecase (without specification), but the minuses (of the old implementation) just exceed the pluses for the browser software and for developer's workload. Read bug 28800 again.
Therefore this needs a new implementation and a proper specification. 

(In reply to r.rhodes from comment #22)
> As far as I can tell, from the bug 28800 items, there was never a 
> survey of the user community

Why should there be a survey? Open Source is not Democracy or something.
If you were a person who maintains great parts of Gecko's table layout code or has deep insight into it, and/or you were an excellent specialist in CSS table model, your opinion would have more impact. Otherwise less.

> My point was to express the need here to the developers, the ones who removed it.

The problems and needs are well understood.

> Therefore, it shows a lack of consideration for your customers.

Who is "your"? This is an Open Source community and you are part of it. Do it yourself. Or ask interested people to do it. If you feel like a customer, pay someone to do it. Comment 17 describes what's to be done.
(In reply to Boris Zbarsky (:bz) from comment #16)
> One more mistake from comment 10 and comment 11 that I think is important to
> point out.  The old code for this in Gecko didn't "work" except by accident.
> It was completely broken by design and caused all sorts of problems
> throughout the table layout code.  If we implement this again, it will need
> to be done in a totally different way.

I think we have a communication problem here. I just read through all the comments here and at bug 28800, but never did I get the impression that the real problem was that the feature was broken "by design" and never expected to work in the first place. Instead the rationale seemed to be: "our table code is hard to maintain, so let's just cut our losses and revert this feature because no other browsers implement it anyway". If you had clearly explained this from the start, perhaps there wouldn't have been such a backlash.
The problem that web developers want addressed is for the table headers to not scroll when the values in the table scroll.  That way, when scrolling a long table people can still see what the headers in the column are.  It's a usability issue.  The solution for this currently out there is not sufficient:

Use two tables, in which the widths of the columns will need to be manually maintained, which is a nightmare.

As a developer, I need an easy way to have the headers visible while the content scrolls.  With this feature removed, I will be falling back on just scrolling the headers which presents my users with an unfortunate usability problem, but I need to spend my time on other issues.

If someone can manage to fix this issue, in whatever way they deem appropriate, they will have some happy developers.  Thanks for reading.
The example link below leaves me somewhat mystified - does the addition of 'display:block' on the component elements of the table completely bypass the troublesome table layout code from which overflow was removed? It would seem so, as this example, using a single table, appears to function exactly as the overflow property did < v4. However, specific column widths are still required.

http://jsfiddle.net/mnnGA/29/
(In reply to Chris from comment #26)
> The example link below leaves me somewhat mystified - does the addition of
> 'display:block' on the component elements of the table completely bypass the
> troublesome table layout code from which overflow was removed? It would seem
> so, as this example, using a single table, appears to function exactly as
> the overflow property did < v4. However, specific column widths are still
> required.
> 
> http://jsfiddle.net/mnnGA/29/

Yes, the problem is with table-row-group which is the default "display:" value for a table. By changing it to block you're essentially making it no longer a table in CSS terms.
Would love to see this feature added back in.  Wish I had the coding chops to do it myself.
Agreed. This was a really useful feature and I'm disappointed that it was dropped from Firefox.

Here are links to the related bugs on the Chromium and Webkit trackers:
 * https://code.google.com/p/chromium/issues/detail?id=8998
 * https://bugs.webkit.org/show_bug.cgi?id=3239

For now having to resort to horrible Javascript and CSS hacks.

Just google scroll table to see how popular this feature would be.
Still not implemented. Official W3C test document:

http://www.w3.org/WAI/UA/TS/html401/cp1001/1001-THEAD-TBODY-TFOOT-OVERFLOW.html
(In reply to Alan O. from comment #32)
> Still not implemented. Official W3C test document:
 
> http://www.w3.org/WAI/UA/TS/html401/cp1001/1001-THEAD-TBODY-TFOOT-OVERFLOW.html

HTML 4 is outdated, what Mozilla aims to implement is this:
http://www.w3.org/TR/html5/
or, to be more precise, this:
http://www.whatwg.org/specs/web-apps/current-work/multipage/

(that said, we have, as discussed, a lack of specification here and this is a styling/CSS issue. Also reread comment 17)
Where does the HTML 5 specification explicitly state to disregard that rule? Please try not to intentionally misinterpret the spec as Bernd had before (I pointed this and other logical errors out in comment 28), and also please try to avoid using an argument from incredulity as a rationale for not at least attempting to come up with an idea to resolve this.

Ultimately any reasoning presented here for this not to be implemented does not matter as this was supposed to already be implemented years ago. If you need ideas on how to make it work, look at the infinite number of applications with this same concept actually being used.

As for this being a styling/CSS issue, please read the description of the Component under which this bug is filed (Layout: Tables):

> For bugs in the CSS and HTML table layout and rendering code. For example bugs
> with the HTML 'rules' attribute or the CSS 'border-collapse' property belong here.

Having attempted to open another bug in the "correct area," I have yet to find another area whose description sounds more appropriate for this bug.

FTR, the relevant spec is clear that the 'overflow' property doesn't apply to table row groups:
https://drafts.csswg.org/css-overflow-3/#overflow-properties

There is an open csswg issue to add support for it here:
https://github.com/w3c/csswg-drafts/issues/5301

I'm resolving this bug as wontfix for now (without implying Mozilla is in favor or not of this feature).
We can easily open a new bug in case the CSSWG decides to add this feature to the spec.

Status: REOPENED → RESOLVED
Closed: 13 years ago → 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.