Closed Bug 227650 Opened 21 years ago Closed 19 years ago

Too large table cells instead of word-wrapping

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 307866

People

(Reporter: sander.vandemoortel, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031122 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031122 Firebird/0.7+

Why doesn't it word-wrap the text instead of stretching my table cells to fit
the text in it?

Reproducible: Always

Steps to Reproduce:
1. go to http://www.jnm.be/~middenkust/kalender.php?maand=12&jaar=2003
2. go to http://www.jnm.be/~middenkust/kalender.php?maand=12&jaar=2003 with IE
3. compare
Which table cells should I be looking at?  The page looks similar in Firebird
and IE, and I don't see horizontal scrollbars in either.

I tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b)
Gecko/20031122 Firebird/0.7+
and a December 4 build.
The text in the December 7 cell is wrapped in IE, but not in Firebird.
-> Browser, Layout: Tables.
Assignee: blake → table
Component: General → Layout: Tables
Product: Firebird → Browser
Version: unspecified → Trunk
WFM at 800x600.  But the Dec 13 cell wraps after "aan" in Firebird and after
"kijken" in IE.
The first five columns in the calender are narrower than the other two.
The table cells seem to be ignoring their 'max-width' property.
that's true, but I knew that already, because on w3schools.com it is stated that
this CSS2 property is not supported by either Explorer or Netscape, but this
doesn't mean Firebird shouldn't wrap?
Please ignore w3schools.com.  It's mostly wrong, last I checked, if I'm not
confusing it with something else.  Mozilla does support 'max-width', at least
for most elements.  I'm not sure if IE/Windows does, but Mozilla isn't
displaying the page correctly.

However, it's worth noting that you'll see different things depending on browser
window width.
max-width does not apply to table elements:
http://www.w3.org/TR/CSS21/visudet.html#propdef-max-width
That says "table elements", which I would think means tables, not tables and
table cells and everything in between, although I could be wrong...
This is why the spec should have friggin' links to term definitions in places
like this... for what it's worth,
http://www.w3.org/TR/CSS21/tables.html#internal does in fact say that "table
elements" includes tables and table cells and everything in between.  Which
makes it a little odd that max-width doesn't apply to table elements.
If someone wants this added to the 2.1 issues list, let me know exactly what I
should add (including proposed fix).
I just sent mail to www-style with one issue and the proposed fix -- that all
uses of a term (such as "table elements") should be linked to the term's definition.

I don't really know whether the fact that max-width doesn't apply to tables and
table cells is an issue or not -- someone familiar with the CSS table model
should decide that.
what I know for sure is that in mozilla's table code base max-widths are not handled
Boris do you remember what happened to your mailing to w3c style?
> Boris do you remember what happened to your mailing to w3c style?

As far as I can tell it got summarily ignored.  There was no response, no
acknowledgment of receipt, and not corresponding change to the spec.
QA Contact: ian
The issue was numbered P3, and was considered by the working group, but was
rejected, with a note that editors of individuals chapters should feel free to
linkify any terms that they felt worth linking. (No e-mail was sent regarding
this as it was received after the call-for-comments deadline.)

The issues list does not say why the issue was rejected, however at a guess it
would be because linkifying every term in the spec would be a humongous task
with limited rewards.

In either case, it doesn't appear to affect this bug as far as I can tell.

The 'max-width' property applies to all elements except non-replaced inline
elements and table elements. 'table-cell' elements are not table elements.
Hixie could you please verify that my understanding of your comment and CSS2.1
is correct (I guess I got something wrong):

Property                     width               max-width
table                        yes                 no
inline-table                 yes                 no
table-row                    no                  yes
table-row-group              no                  yes
table-header-group           no                  yes
table-footer-group           no                  yes
table-column                 yes                 yes
table-column-group           yes                 yes
table-cell                   yes                 yes
table-caption                yes                 yes

What the difference betweeen rows and cells if " 'table-cell' elements are not
table elements" why do we allow a maxwidth for rows when they don't even have a
width?
> 'table-cell' elements are not table elements.

Please reconcile that with http://www.w3.org/TR/CSS21/tables.html#internal (and
reread comment 10 as needed  ;) ).

> would be a humongous task with limited rewards.

If David, you, and I all make the same mistake while reading the spec, it would
seem that the spec could use something to keep everyone else in the world from
also making this same mistake...
>> 'table-cell' elements are not table elements.
> 
> Please reconcile that with http://www.w3.org/TR/CSS21/tables.html#internal 
> (and reread comment 10 as needed  ;) ).

Oops, missed the "cell" part. Ah well, I always said I hated tables...

   http://www.hixie.ch/tests/adhoc/css/box/table/README


>> would be a humongous task with limited rewards.
> 
> If David, you, and I all make the same mistake while reading the spec, it 
> would seem that the spec could use something to keep everyone else in the 
> world from also making this same mistake...

I would imagine if your request had been more specific, e.g. "please link this 
particular instance of that particular term to its definition", it would have 
been much more likely to get attention.

It's the difference between me saying, right before a final milestone release, 
"it would be nice if dotted border calculations at corners rounded up instead of 
rounding down", and, "it would be nice if Gecko did all pixel rendering using 
fixed-point decimal fraction arithmetic". One takes a few minutes and wouldn't 
really delay release, the other several months and risks delaying the release 
even further due to other people wanting their thing fixed at the same time. :-)
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

the behaviour changed in the spec.

*** This bug has been marked as a duplicate of 307866 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.