Closed Bug 451733 Opened 16 years ago Closed 16 years ago

Table COLSPAN not functioning properly

Categories

(Core :: Layout: Tables, defect)

1.8 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: mmanning, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(8 files, 2 obsolete files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 E-mail me for the complete HTML. (Won't fit here.) I created a report using tables. The first two lines are the same but the third line combines various boxes together to form longer areas. This is where the problem occurs. General layout for box usage: Line #1: 1,1,1,1,1,2,1,1,1,1,2,1 Line #2: 1,1,1,1,1,2,1,1,1,1,2,1 Line #3: 1,4,1,5,1,2 Line #4: 1,4,1,5,1,2 When the table creates line #3, instead of what it is set to do I get: Line #3: 1,4,2,4,2,1 Line #4 is the same way. Instead of using only half of the size of the box on Lines 1&2, FireFox, instead, stretches the "1" into becoming a "2" and shortens the next area to be "4" instead of "5". I use the "COLSPAN=X" part of the "<TD>" command to specify exactly how many columns wide each of the boxes should be. (So: <td colspan="1"> and so forth) Reproducible: Always Steps to Reproduce: 1.You have to run my program which generates the HTML. Which you can't do because the databases and site are protected. 2. 3. Actual Results: The table output looks like this: 111|111|111|111|111|222-222|111|111|111|111|222-222|111 111|111|111|111|111|222-222|111|111|111|111|222-222|111 111|444-444-444-444|222-222|444-444-444-444|222-222|111 111|444-444-444-444|222-222|444-444-444-444|222-222|111 Expected Results: The output should look like this: 111|111|111|111|111|222-222|111|111|111|111|222-222|111 111|111|111|111|111|222-222|111|111|111|111|222-222|111 111|444-444-444-444|111|555-555-555-555-555|111|222-222 111|444-444-444-444|111|555-555-555-555-555|111|222-222 E-mail me if you want the actual output. (mmanning@mdanderson.org)
Attached file Output of the program (obsolete) —
Don't ask me my FireFox decided to tack the ".php" onto the end of the output. The original program's name was "DailyRpt.php" but the output should have been "DailyRpt.html". Another possible bug maybe?
Firefox 2 has a pretty old layout engine. Please upgrade to Firefox 3.0.1 and test again. If the problem persists, try to create a minimal testcase and attach it to this bug.
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
Version: unspecified → 1.8 Branch
To: steffen.wilberg@web.de Thanks for the VERY rapid response. I upgraded to v3 of FireFox - and it looks worse than before. :-( So FFv3's new layout engine either either more accurate than the FFv2 layout engine. Or it's less accurate. Unknown. :-P What's going on now is each individual table is different sizes. Which is really weird given that I use the "width:###px" style command. Which, I would have thought, would have forced FF (or IE) to make each table entry the size specified. As for minimal example: Heck, you can just delete everything past the first table as they are all just the same table code being generated for each of the example people I have. (Not real data BTW.) If you want me to do it just let me know and I'll zap all of the other tables for you. However, I would think you'd want the entire example just in case the problem starts occurring only in the second, third, etc... table being generated.
Stripping unneeded tables is not enough. Strip everything, isolate the problem. Strip the inline style declarations, use a <style> element instead if you need it. Or just start from scratch with a table as simple as possible. Please see http://developer.mozilla.org/en/Reducing_testcases Also fix the markup errors using http://validator.w3.org/ For example, there can't be a </html> tag in the middle of the page. And have a look at the spec: http://www.w3.org/TR/html401/struct/tables.html#column-width
(In reply to comment #4) > Strip the inline style declarations, use a <style> element instead if you need > it. Inline style is often better for reduced testcases since it's much less likely to accidentally apply to a different element.
These were EXCELLENT suggestions. Especially the validator. It found four errors and complained that there wasn't a DOCUMENT HTML command at the beginning of the report. (Which is true - this program was originally put together by a grad student and I am trying to update it. So I'll go put that in here in a sec.) Let me correct the four errors which the validator found before I do anything else because it may (or may not) fix the problem. I'm bookmarking the validator! That is something I can really use. Thanks for the tip Steffen! :-)
Attached file Example output - 2nd Try (obsolete) —
Ok! Here is a completely validated HTML v4.01 minimal document which shows the error. :-) Enjoy! :-)
Comment on attachment 335399 [details] Example output - 2nd Try The "REF MD" section has a COLSPAN="2". The "PC Needs" section has a COLSPAN="1". The "Como:" section has a COLSPAN="1". So both of the latter sections should only take up half of the "REF MD" section's area. PS: When did <TD> stop allowing the "WIDTH='X'" stuff? The validator said it was not a valid option to the <TD> section. (Just a Q&A kind of thing there. :-) )
I went back and started from scratch making the table. I managed to remove everything except the colspan. So it looks like colspan is the culprit. The only thing I put in as a style is the border so you can see how wide each cell in the table is. I've also included an image of the original Excel Spreadsheet output that I was building everything by. I hope this helps. :-)
Attached image The Excel Image (obsolete) —
I just checked the upload and noticed that the image was not there. Hopefully this will upload it.
I think I may have figured out what the problem is. (But I can't fix the problem because the problem is a part of how FireFox/IE work.) Here is my hypothesis: The problem is a look-ahead problem. Since, in a two or more celled area, there is only one size for that area, when you try to split up the area on another row, FireFox (and IE) assign only one pixel to the second area. (Instead of checking to see how much area is used by the other area first, subtracting out all other area's usage, and then subtracting the left over area from the multi-celled area on the previous row.) Thus, both FireFox and IE are trying to do the right thing, but can't because they have no reference for how large the split up area should be. So it assigns X-1px to the first area and 1px to the second area. (If that makes sense.) If you look at the very simple example I provided you will see that the "5" area overlaps just a tiny bit into the "2" area on the row above it. That tiny area is probably just 1px wide. Now - why FireFox is doing that I have no clue. But I just noticed that and thought I'd post about it. :-)
I have difficulties to follow, can you attach a reduced test case with a single table that shows the problem (http://developer.mozilla.org/En/Reducing_testcases).
Eh? Is not the "A very simple example" not simple enough? I don't think you can get any simpler without just not giving an example. :-) Take a look at the "Excel example". That is what it should look like. Then look at the "A very simple example" and that is what I'm getting. Note that the "1/2", "1/5", and "1/8" areas do not match the "Excel example". (That is to say, these areas should be split in two with each half being half the size of the area above them.) The earlier example (ie: the "Output Example") shows the entire section of the output. (Which is a lot closer to the "Excel example"'s image. The second example removes everything except the first block of output. The third example is stripped down to the bare essentials. The fourth example is the Excel output. If you guys need me to - I can try making a static image that has writing on it to show what I'm talking about.
This example uses Excel to show the problem. I'm using colors to denote the various areas and numbers to denote how many cells are supposed to be used. So if there is a "1" in a cell, it means I'm only using one cell, a "2" means I'm using two cells (in this case always left to right), "4" means four cells, and so on. :-)
this is a colspan width distribution problem where columns that do not have cell originating at it (I would call them virtual columns) are suppressed. This is very similar to bug 187550.
Yes. I see that. I also have a VERY simple solution to this problem: Divide the colspan into the width of the entire set of cells. This would eliminate the "zero sized cells". Fractional parts would be added on to the first/last cell according to however the Mozilla people want to do it. Thus, an example would be: <table> <tr><td colspan=2 width=100>test</td><td>test</td></tr> <tr><td>test</td><td colspan=2>test</td></tr> </table> Would work because the first COLSPAN would be made up of two cells which each have 50px assigned to them. Thus, the second line would have a first <TD> section with a width of 50px and the second section would be a COLSPAN=2 where the width would be 50px + <td width from the line above>. This is not rocket science on how this should be working. I'm a programmer by trade but I do not know what the Mozilla code looks like. However, using my over thirty years of programming experience I think I can say with some confidence that this should not be a big thing to fix. The actual widths should be calculated if not given or used if given (as in my case). Then, to use your terminology, a VIRTUAL width should be calculated for each of the cells based upon the colspan. If colspan isn't given, it defaults to one(1). Thus (ACTUAL WIDTH)/COLSPAN = VIRTUAL WIDTH per cell. Once you have that, the lines under it are just an accumulation of the VIRTUAL WIDTHs. If an ACTUAL WIDTH changes later in the table, then the table has to be regenerated (or changed) to reflect this. (This is already being done presently when you have large tables and the table resizes itself as everything is loaded in to the browser.) As far as I can tell, (without actually looking at the Mozilla code) the only thing that isn't being done is to assign the VIRTUAL WIDTH to multi-columned cells. If you just did that, the whole problem would probably go away and everyone would be very happy. :-)
Whatever you think might make sense, the problem is that a lot of Web pages depend on a particular (non-optimal) algorithm being used for table width distribution, going back to compatibility with the first browsers that implemented tables and then the series of market-leading browsers. I haven't looked into your particular issue. But the question you need to ask is not "what algorithm would make this work?" but rather "what are the differences between Mozilla's algorithm and the algorithm used by browsers in which this does work?".
Thanks! I'll look at the code here in a bit. Not to be rude or anything like that - but saying what you said before is like saying cars were originally invented with square wheels and we aren't going to change it because everyone expects square wheels on our cars. I'm sure a lot of people may complain at first about the fix, but if it fixes the problem I think a lot more people will be happy that it now works the way it should. Let me go look at that code. BRB.
Ugh. Those links are HTML docs. Let me go look at the responsitory....
(In reply to comment #19) > Not to be rude or anything like that - but saying what you said before is like > saying cars were originally invented with square wheels and we aren't going to > change it because everyone expects square wheels on our cars. No, I think it's more like saying that because most US railways are built with the tracks 1435mm apart that we expect train cars to have the wheels that far apart. It's somewhat arbitrary, and may not be ideal, but picking anything new requires everybody to change. Authors writing new pages might prefer other behavior. But users and authors get very annoyed if we break pages already on the Web. (In reply to comment #20) > Ugh. Those links are HTML docs. Let me go look at the responsitory.... There's also a "raw file" link in the corner; but the repository at http://hg.mozilla.org/mozilla-central/ does have them as well, of course.
Hmmmm.... Actually, your analogy is an all or nothing, while mine - you just have to change the tires. You could still drive the car, the road is still the same width, but the car drives better with circular wheels. :-) There is a difference between the two outlooks. :-)
Attached file First solution - Generic HTML (obsolete) —
The attachment termed "Solution" is something I came up with after thinking about it overnight. This is a generic HTML solution which can be used to overcome the bug in the code. All instances of this bug should point to this solution as it does allow you to have multiple/split cells. The upload is the HTML example. Here is the explanation: To overcome this bug what you have to do is to put a hidden line at the top of your table. This hidden line has each of the cells separated out into individual cells. So if you have a single cell with a COLSPAN=2, you have to make two cells in this hidden top line with each of them having half of the total width of the cell with the COLSPAN=2 in it. (So if the width of the COLSPAN=2 cell was 100, you have to make two cells with only 50 assigned to each of them.) So if your table looked like: <html> <head><title>Test #1</title></head> <body> <table> <tr><td colspan=2 style="border:1px solid black;width:100px;">A</td> <td style="border:1px solid black;width:100px;">B</td></tr> <tr><td style="border:1px solid black;width:100px;">C</td> <td colspan=2 style="border:1px solid black;width:100px;">D</td></tr> </table> </body> </html> It would now look like this: <html> <head><title>Test #2</title></head> <body> <table> <tr><td style="height:0px;width:100px;border:1px solid black;"></td> <td style="height:0px;width:100px;border:1px solid black;"></td> <td style="height:0px;width:100px;border:1px solid black;"></td></tr> <tr><td colspan=2 style="border:1px solid black;width:100px;">A</td> <td style="border:1px solid black;width:100px;">B</td></tr> <tr><td style="border:1px solid black;width:100px;">C</td> <td colspan=2 style="border:1px solid black;width:100px;">D</td></tr> </table> </body> </html> This fixes this problem without having to change the code for Mozilla. However, I've already downloaded the code and plan on looking at it this weekend. At over 255MB for the entire source code it may take me a few days to find and read through those sections which may pertain to this error. So more next week probably. :-) Side note: Bugzilla needs a "Preview" on the posting of comments so people can read their comments and make any changes which they might want to make. Just a thought. :-)
Ugh. Like I said - need a preview. :-( I just noticed that I used 100px for everything. It still shows that it works but I should have made the COLSPAN=2 be a width of 100 and the others a width of 50. :-/ Also, instead of a "1px solid black" on the hidden line I should have used "0px solid black". It makes the table show up better. (Not to mention I didn't use cellpadding, cellspacing, or any of the other items. Oh well, it still shows this works.)
Attachment #335564 - Attachment description: Final example using Excell to show table layout problem → Final example using Excel to show table layout problem
Just an update: I downloaded the source code to FireFox and tried to compile it via my Cygwin installation. No go. W32api was too old. So downloaded new copy of Cygwin. No "Fixed Font" problem. Did research. Found solution. Tried to recompile. No go again. Read some more, found out that FireFox has to be compiled with Microsoft's Visual C++!!!! Eh? I would have thought that FireFox would use MinGW or Dev C++ (which uses MinGW) and maybe wxWidgets. Or maybe Mono for C# compatibility. Oh well, downloaded Microsoft's 768MB complete Visual Studio Express. Installed everything only it seems to be refusing to use C++ or C# either one after install. (Also downloaded the MSDN and Vista SDK the FireFox notes said you had to have in order to compile FireFox.) So that's taken all day Saturday and Sunday. Today (Monday - Labor Day) I'm back at work because if I don't work I don't get paid. When I get home tonight I'm going to see about downloading just the Visual C++ program and install just that. Maybe I can get everything up and compiling by tonight. More later. BTW: The Visual Web Developer DOES work on that 768MB download. When I did the above test using the VWB - it works fine. Now, the table winds up with extra items sticking out on the right. But you can delete those extra columns and the output is still right. Any ideas on why that is? (It shows up correctly in both IE and FireFox.) So if you want to do the: 2-2-1 1-2-2 thing in the VWD, it actually creates: 2-2-1-1 1-2-2-1 (Those are table cells up there.) The extra cells (the fourth "1" above) can be selected and deleted and then you get the first table and it shows up correctly in (as I've said) both FireFox and IE. Why? I don't know. I didn't program these programs - they just do. But when I try it by hand - it messes up. A really neat trick I think. :-)
Yeah, as I said - no go. Or, in other words, "It would not work." :-)
Well, there is nothing like a good hurricane to mess things up. :-) Hurricane Ike came through and our house now has one fewer trees in the back yard, no fence, and a rear porch which looks just peachy until you notice it is slightly twisted, has just about ripped the eave under the roof off, and put a post through a panel we had out in the wood pile behind the house. Oh yeah - no electricity either. Been a hot week so far. At least we didn't flood. Came close, maybe a 1/4" (or about 6mm - which ever way you want to look at it), but the water did not come into the house. All of my home computers are offline presently until power is restored. Hope everyone else is doing well. BTW: I recently finished working on reformatting and documenting the S3DB code at S3DB.org here at work. We haven't uploaded it back to them yet, but that's because power here at work only came back on on Wednesday and I only came back today. :-/ Probably get it done next week. Sorry for the delay in looking at the Mozilla code. I'm hoping electricity is restored to our house early next week. (And why was I able to help the S3DB people? Because they are here at M.D. Anderson and it is a part of what I was hired to work on.) Later! :-)
Depends on: 187550
Keywords: testcase
As far as I can tell, what you're asking for here is that colspan="2" means that the cells in that column will take twice the width of cells with colspan="1". Nothing guarantees that; we size the columns to fit the contents. If you want cells or columns to have particular widths, you can give them particular widths. (However, if you give widths that conflict with each other, we'll generally take the bigger one, although resolving conflicts when column-spanning cells are involved is a little more complicated.) If that's not what you're asking for, it would help if you filed a new bug with a clear statement about what behavior is incorrect. This bug is too big to be useful, given that the first 24 comments don't have such a statement.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Actually, that is not at all what I was saying. What I am saying is just the opposite. If you have a colspan="2" and nothing else, then that colspan is equal to two colspan="1" which each has half of the size of colspan="2". Just like in math where 1/2 = 0.5 and 0.5 + 0.5 = 1.0. Thus, if the colspan="2" had a width of 2500 pixels, the two colspan="1" would each be 1250 pixels in length. Better?
That's exactly what we do when there's nothing else in either column. So the question is what to do when there are other (non-colspanning) cells in the column, but there's extra width to distribute from the spanning cell. We distribute it proportionally to the existing (i.e., for cells with lower colspans) widths of the columns. Perhaps there's a case to be made for equally. However, in order to make that case, it would be good to show that at least some other browsers do it equally rather than proportionally.
It looks like four of the attachments on this bug have potentially private medical information. If so, they shouldn't be left publicly-visible. Mark, are the names/information in these attachments fake, or are they real people? (If they're real people, each attachment should probably be marked as private on its "details" page.) The attachments in question: attachment 335074 [details] attachment 335399 [details] attachment 335438 [details] attachment 335932 [details]
They are fake. Development system where we generated fake information. Any association to real/living/dead people is purely coinsidental. Hey! I just wanted David to know that I haven't forgotten about this. I knew I said I'd get back to you on this with some thoughts about the software - but things have been rather rough since the hurricane knocked out power. (Like getting terribly sick a couple of times and last weekend was a funeral for a very good friend. [His name was Eric Von Mitchell in case you want to check out who he was. Worked at NASA with him. So they may have some write-up on him.] Anyway, been too busy to spend some time going over FF3's code. Still want to so I can contribute - but workload is really heavy right now and I go home really tired presently. Just want to collapse and go to bed right now. Probably a bit depressed over Eric's death too. You can see what he looked like at: http://www.jsc.nasa.gov/history/roundups/issues/98-12-04.pdf. He's the black guy on page 7. Anyway, I haven't forgotten about this - just really busy right now. :-/
To David: Equal versus proportional: Ok, if everyone else jumped off of a cliff - should we? The answer is, of course, - no. So just because everyone else does it proportionally - does it mean FF should do it too? Shouldn't someone do it properly? Further, as per my example, what is actually done is to adjust how wide the hidden line actually is. So what I'm suggesting isn't proportional or equal - it's additive. As in my example: If you have one line that is comprised of three columns: The first row has a 100px column(colspan=2) and a 50px column(colspan=1). The second row has a 50px column(colspan=1) and a 100px column(colspan=2). Thus, the hidden row would actually have three columns: Hidden row: 50px, 50px, 50px FF would then see that in order to make a 100px column it would have to combine two columns. Since the first row from above has a colspan of two(2), it gobbles up the first two entries in the hidden row. (So 50px + 50px = 100px) and then gobbles up the last 50px for the colspan=1. The second line does the opposite. Gobbling up only the first 50px for the colspan=1 and then the next two 50px for the colspan=2. What I would like to know is why you are having trouble understanding what I am saying. I've sent examples and gone over this in various ways a couple of times. So - what is it that I am not saying or you not understanding that is causing the confusion. Changing the status to Resolved/Worksforme because the hidden line takes care of this problem.
Resolution: INVALID → WORKSFORME
To David: Ok, my fault - just got another e-mail. Non-Colspanning columns ARE colspanning columns. They just default to "colspan='1'". Just because you don't specify the "colspan" option - doesn't mean it doesn't have a colspan. It's just the default colspan option - which is one(1). :-)
Hold EVERYTHING! The example for Bug #187550 works now - let me try this on my report. (I made sure to update to the latest version of FF3 before I tried the other bug and now that table example is working. So hold everything! BRB!)
(In reply to comment #35) > Non-Colspanning columns ARE colspanning columns. They just default to > "colspan='1'". Just because you don't specify the "colspan" option - doesn't > mean it doesn't have a colspan. It's just the default colspan option - which > is one(1). :-) Note that in comment 31 I defined the existing width as the width as contributed by all cells with *smaller* colspans. That's how we do the allocation -- we allocate widths for cells with smaller colspans first. (In reply to comment #34) > Equal versus proportional: Ok, if everyone else jumped off of a cliff - should > we? The answer is, of course, - no. Just because equal works better in your use case doesn't mean it works better for everybody's. For example, in <table width="100%" border> <tr> <td>1 <td>This has enough text to fill half the width. </table> it's better to keep the first cell quite narrow. However, we're actually distributing two different concepts of width, minimum and preferred. I think what we currently do is actually based on two different proportions, where we distribute extra minimum width proportionally up until it hits the preferred width (so that if we have extra minimum width to distribute that makes the minimum equal the preferred, we end up with both widths equal in both columns), and then differently above that. We could potentially change the latter part to equal distribution, but I would not even consider making that change without knowing what other browsers do. (For example, if they're all proportional but behave differently, there's more latitude to change than if all browser behave exactly the same.) Compatibility with existing content on the Web is important to our users, and if you continue to insist that we change our behavior in ways that ignore compatibility, you're just going to get ignored. (In reply to comment #34) > Changing the status to Resolved/Worksforme because the hidden line takes care > of this problem. The state of bugs in our bug system reflects the state of a problem report in our software, not in your Web page. Until it's clear what output would need to be different in order for this problem to be fixed in our software, the bug report is invalid.
Resolution: WORKSFORME → INVALID
Ok - no. The report still doesn't work properly without the hidden line which has all of the correct sizes of the columns in them as sent in the original example. To Daniel Holbert: I went and talked with my boss about the examples. The data is taken from the live database but the first/last names and other information is randomly picked. So the first/last name combo is not the real people's names and whatever statuses are in the report are randomly picked so they are not really associated with the a particular name (first or last). The data IS taken from a live database, but I believe it would be impossible to pick and choose who the people are and what their actual data is. However, it probably is a good idea to set it to be private. Because someone might be able to do who-knows-what and put everything back together somehow. Don't know how they'd be able to do that without access to the actual databases. But in this day and age you never know! :-)
(In reply to comment #38) > The data IS taken from > a live database, but I believe it would be impossible to pick and choose who > the people are and what their actual data is. However, it probably is a good > idea to set it to be private. Ok, yeah -- probably better to be on the safe side. Marked as private.
To Daniel Holbert: I do not see an option to make the attachments private. Obsolete - yes, private - no. Can you give me a hint on where it is located? Because when I click the "Details" option to the right it doesn't have a private option anywhere. :-/ To David: Ok - here is your example: <table width="100%" border> <tr> <td>1 <td>This has enough text to fill half the width. </table> There are a number of problems with the example. These are: 1. You only have one row displayed when we are talking about multiple rows. 2. I believe (please correct me if I am wrong about this) you are talking about the "width='100%'" part while I do not care anything about the "width='X%'" at all. That is a separate issue altogether. 3. A good example of my issue is Bug #187550. Although now that example works in FF3 (since I updated my FF3 again). This is an example of a proportional problem. For that simple case - it works. But if you up the number of columns from just two to, say, five, FF3 begins having problems again. So this isn't a question of "if I have a web page will things space themselves out proportionally?", it is a question of "I'm specifying the exact number of pixels for each of the columns and FF3 doesn't honor those specifications." The reason it doesn't is because it is trying to do things proportionally all of the time. Rather than listening to what the human is trying to tell it to do via the "width=Xpx" or via the style/css command "width:Xpx". As per comment: Comment #23 From Mark Manning 2008-08-28 11:16:18 PST Where I gave specific examples of what the problem is. The second example shows how, with a hidden line, the table should look. The first example shows the problem that FF3 can not resolve. It can not, without me inserting a hidden line, correctly line everything up.
To Daniel Holbert: Thanks! :-)
To David: I have a problem with this bug being listed as "RESOLVED" and "INVALID" because it is neither. My simple examples still shows there is a problem and the problem has not been resolved. Now, if you just want to say to everyone "Just put in a hidden line and this problem will go away." I can live with "RESOLVED" and "FIXED", but to say that this problem has been resolved is to say that you are through looking at it and I feel that should not be done until the problem has actually been resolved. Nor is this an invalid problem as the examples show. Can someone else from the Mozilla group weigh in on this? Is this a valid designation? (ie: RESOLVED/INVALID) I've provided a perfectly good example of a given problem with FF2/3. I've also provided a perfectly good work-around for the problem. The term INVALID would mean that people won't know about or read the HTML solution to the problem and I believe that is unfair. Because if nothing else - the HTML solution does work. So if nothing else, at least make this a FIXED thing instead of an INVALID thing.
Mark: IMHO, you still haven't explained / demonstrated exactly what you think is wrong here. If you think there's still an outstanding issue, please **attach a very simple[1] testcase that Firefox 3 renders incorrectly** (in your opinion). Attach it as an HTML file, so it can be easily viewed -- don't just paste the HTML in a comment. Once we have a concise, concrete testcase, it's much easier to examine / explain current behavior and examine whether different behavior would make more sense. [1] By "very simple", I mean e.g. 2 rows / 3 columns maximum (unless more are absolutely needed), and without any extraneous formatting / text, and with a short sentence at the end explaining what the expected behavior is. (Once we have such a testcase, we can perhaps open a new bug for it, as David suggested in comment 29, since this bug is already so long...)
(In reply to comment #43) > If you think there's still an outstanding issue, please > **attach a very simple[1] testcase that Firefox 3 renders incorrectly** (in > your opinion). > > [1] By "very simple", I mean e.g. 2 rows / 3 columns maximum (unless more are > absolutely needed), and without any extraneous formatting / text, and with a > short sentence at the end explaining what the expected behavior is. Note that your attached testcase, "Example #3 - A very simple example", doesn't fit my above criteria for being "very simple". :) A much smaller testcase would probably be helpful in illustrating your point (with exactly one thing in it that you think is broken, rather than 3 supposedly broken things and many many not-broken things all included in the same table)
Attached image Example #4 - a very simple example (obsolete) —
Example showing the same table with and without the hidden line used to correct the problem.
Attached file Example #4 - HTML code (obsolete) —
To Daniel Holbert: Hmmmmmmmmm..... Ok. I presented outputs to show what the problem was, then I was asked to provide HTML examples which I did. So what I am doing is giving a screen capture of what I am seeing as well as the HTML code, already presented, but put together one on top of the other, so you can compare the top versus the bottom parts. They are the same table, but the bottom one has a hidden line that causes the table to straighten up and display correctly. Let me know if you are seeing the same thing I'm seeing. If not, then that would mean that it is something to do with FF3 on my system. (Although I've tried this with Opera, IE, and Safari on a different computer.) Please tell me if you are getting the same output I've posted. Thanks.
So your HTML has four width constraints on it: * cell A (spanning columns 1 and 2) should be 100px wide * cell B (in column 3) should be 100px wide * cell C (in column 1) should be 100px wide * cell D (spanning columns 2 and 3) should be 100px wide I think we're coming as close as we can to satisfying those constraints (which can't be satisfied at all given that the table has nonzero cellspacing). If you want cells A and D to be 200px wide, you shouldn't write that they should be 100px wide.
Ugh! I saw that I had everything set at 100px. This corrects the image making the lines with "colspan='2'" having 200px. Same error, but incorrect HTML.
Ugh! I saw that I had everything set at 100px. This corrects the image making the lines with "colspan='2'" having 200px. Same error, but incorrect HTML.
Attachment #353305 - Attachment is obsolete: true
Attachment #353306 - Attachment is obsolete: true
To Daniel: As per my "ugh" above. :-( Cellspacing should have nothing to do with how the cells themselves look. A 200px wide cell should be 200px wide and a 100px wide cell should be 100px wide. Besides which - this happens no matter what the cellspacing is set to. I just did that to have a little space between the cells so the border shows up better. If you take that out - the same things still happen. So cellspacing has no bearing on the problem.
To Daniel: Actually, I just went back and looked at the HTML and there isn't a "cellspacing" item in there. I think you are confusing the border around the cells (ie: "style='border:1px solid black;'") versus the table's border command (ie: "<table border='1px'>") which would make the cells all be jamb up against each other. :-)
No, the cellspacing should matter, because a column spanning cell spans not only the widths of the columns but the width of the cellspacing between them. See your own Example #4.
Ok - here is the same table with cellspacing set to "0px".
Here is the same example with the tables set to having cellspacing set to '0px'.
The cellspacing point related to example 4, not example 5.
Ok here is the same tables with cellspacing set to "0px". Now they have a zero based cellspacing. Same output. :-/ If you mean something different by "cellspacing" could you post a simple HTML example so I can see what you mean? Thanks!
Sorry guys - been here for twelve hours - going home. I'll read your comments tomorrow. :-)
Attached file testcase 7
Here's a further-simplified testcase, with borders removed so that we're *just* dealing with the cells' specified widths. However, AFAIK, Firefox 3's current output for this testcase and for the previously-posted examples is exactly what we're expecting from our current table-layout algorithm, for the reasons dbaron explained in comment 31.
Er - no. He was referring to the colspan=2, width=100px example. Again though, this is not a proportional or equality problem. It is a problem that deals with correctly counting up the number of pixels someone wants for their cells. In this case, I want 200px for the first cell and 100px for the second. FF can not handle this situation (or rather - it handles it incorrectly). The way to handle laying out a table is: 1. To make a first pass and determine how wide the table is supposed to be (ie: Max number of pixels/points) 2. To make a second pass gobbling up how many cells there are and how wide each cell is supposed to be (in pixels/points). 3. To create a new row in the table which contains all of the cells and their widths in pixels/points that are needed in order to correctly display the table. 4. And then to either insert a hidden line at the top like I've done in order to ensure that the table displays correctly or to fix the engine so it displays things correctly. But the thing you can not do is to say FF is displaying things correctly either equally or proportionally because it is doing neither. Nor can you say this problem is invalid - because to be invalid I would have to not be able to show you the problem. Would I? To be invalid means that the problem doesn't really exist - yet I've shown it does. You may not want to fix the problem (which - if that is what you want to say then ok - what can I say?) But to gloss over the problem by saying "That's what it is supposed to do" is like saying "I ran over that guy back there because cars are supposed to work that way." It doesn't really make a lot of sense if you know what I mean. :-/
Mark: No, comment 31 applies to pretty much all of the testcases here -- I think you're misunderstanding what dbaron was saying there (though that's understandable, because table layout is pretty complex). The basic goal is calculating width per individual column. This is roughly how Firefox handles this (at least as pertains to the examples here): * For (n = 2; n < largest_colspan_in_table; n++) { * For (each cell with colspan = n:) - If cell is wider than its spanned columns, then distribute the excess width among its columns. This width is distributed proportionally according to their existing width. In the case of testcase 7 (and most of the other testcases) this plays out as follows: 1) We start out with column 1 = 100px (from cell C), column 2 = 0px (no width specified on that column), and column 3 = 100px (from cell B). (Note that we haven't allocated any width from Cells A and D yet -- that's what we're about to do next) 2) We hit the loop above for Cell A (colspan=2). It spans columns 1 and 2, which currently occupy a total of 100px. That leaves 100px to distribute. This excess is given *proportionally to the current widths of the spanned columns*, so since column 2 currently has 0 width, all the excess goes to column 1. So column 1 ends up 200px wide. 3) We hit the loop above for Cell D (colspan=2). It spans columns 2 and 3, which currently occupy a total of 100px. That leaves 100px to distribute. This excess is given *proportionally to the current widths of the spanned columns*, so since column 2 currently has 0 width, all the excess goes to column 3. So column 3 ends up 200px wide. I hope that makes sense.
Mark -- here's one other way to think about it -- the first table in testcase 7 is actually *under-specified*. We have the following information: - a minimum width on Col 1 (100px), from cell C - a minimum width on Col 3 (100px), from cell B - ***no specified width info** about Col 2 (so it starts out with 0 width) - there's 200px to be distributed amongst col 1 and col 2 (from cell A) - there's 200px to be distributed amongst col 2 and col 3 (from cell D) There are many, many ways that we could distribute the 200px widths mentioned in the last 2 points there. Firefox distributes it in a deterministic way, giving out excess width proportional to the existing widths of the spanned columns, as described in my last comment. This may not be the best way for your particular case, but it works well in general. If you want to fix this underspecification issue in your HTML in a cleaner way (not resorting to an "invisible row"), you can use <col> tags to give Firefox more information about the desired column widths, as shown in the file I'm attaching right now. I hope that's helpful.
Ok, let me answer each of these two comments (ie: #61 & #62): er.......... :-? Ok, ummmmmmmm...... you've got the test case mixed up. Here are the problems with what you've posted. First, bring up one of my examples (#5/#6), testcase 7, and your example. Now look at the source code for each. In my examples (#5/#6) and testcase 7 there are three columns specified. Not two. Two columns seem to work ok with FF - but three do not. In my examples and testcase 7 - all widths are specified. In mine I use inline style and in testcase he uses CSS styles. So the example you give doesn't work when you get to three columns. Two, yeah - it works for some reason (See my earlier comment where I say this). But three or more columns do not work properly even if you specify the width of each column. I know my example looks like it is only using two columns - but that's the rub. It's really using three. In my original examples I'm using something like twenty columns. When you get up to twenty columns the columns really show up in weird places. Thus the need for the hidden line to give the table stability in how it displays the columns. So I understand what you are saying about proportionally allocating widths if not specified - but we are specifying the widths and FF ignores them. I also know why it ignores them - because it's trying to adjust for each of the succeeding rows after the first. Each of them applies changes which FF tries to proportionally handle. This is why I'm saying if FF did a multi-pass scan of the incoming table, gathered up all of the information about the width, numbers of different cells per row, and adjusted itself for there were enough small columns to make up the larger columns - it wouldn't have this problem. In pseudo code this would be: max_width = 0 for( i=0; i<Number_of_rows; i++ ){ row_width = 0 for( j=0; j<Number_of_cells_for_this_row; j++ ){ row_width += calc_cell_width( table_info[i][j] ); } if( row_width > max_width ){ max_width = row_width; } } // // The following call sets up the cell_array_widths which contains // only one value to begin with - the maximum width of the table in // whatever units (ie: pixels/points) FF uses to do its calculations. // clear_my_cell_width_table( max_width ); // // Now we go through and figure out how many individual cell widths // we need to make the table show up correctly. // for( i=0; i<Number_of_rows; i++ ){ // // The following command resets our cell calculations so // we are starting back at column #0 on the page layout. // start_new_row(); for( j=0; j<Number_of_cells_for_this_row; j++ ){ // // This function splits up the cell_array created by the call to // clear_my_cell_width_table() above. It does this by using the // secondary array cleared in start_new_row(). As each cell is // looked at the program checks to see if there is enough room for // the new cell. Since we have already figured out the maximum // width of the table, we simply break up the full amount into // smaller and smaller bits. Like so: // // Originally we have, say, 300px to work with. (As per my examples.) // We get our first cell, it says its width is 200px. So the array will // not change because 200px will fit into 300px. So our array still looks // like this: // // global_cell_array[0] = 300; // // When we get to the next cell (because cell #1 contains the "colspan='2'") // we find out that the cell's width is 100px. So now the program looks // at the global_cell_array and sees that it uses the max_width and that it // has to break it up. Since we already know the max_width and since the // first entry contains all of it, and we know that all of our cells have // to fit within the max_width - we can split up the global_cell_array // into two separate areas. Like so: // // global_cell_array[0] = 200; // global_cell_array[1] = 100; // // So then we go to the next row. NOTE: We do NOT reset the // global_cell_array. We only reset the current row's counting of the // individual cell's widths for the row we are currently on! So the // global_cell_array retains it's information. This time, the first // cell has a width of 100px. The program looks at the first entry in // the global_cell_array and sees that it contains 200px! So it gets // split into two separate array entries like so: // // global_cell_array[0] = 100; //Originally 200px. // global_cell_array[1] = 100; // New entry. // global_cell_array[2] = 100; // Old 100px entry from above. // call_adjust_cell_info( calc_cell_width(table_info[i][j]) ); } } // // At the end of the above, you now have a global_cell_array which // contains all of the various cell's widths - split up into individual // areas so all cells would line up correctly. This was demonstrated // in either one of my comments here or in the 187550 bug. In this // example though, you now have all three column's widths (ie: 100px // each). There is no guess work, this process will work every time // and you don't have to do proportional or equal. It's absolute! :-)
Additonal notes on the pseudo code: I probably should have done the last 200px. The last 200px looks at the global_cell_array (which is presently pointing at entry one(1), sees it is not large enough to hold the 200px and continues to look down the array adding together the various widths until it either has: 1. Enough pixels (in this case) to hold the 200px. (Which will happen after adding together the two 100pxs.) 2. Or that the number of pixels exceeds how many it needs. When this happens it again splits the global_cell_array at that point just like it did to get the first row's pixel areas. Ok?
(In reply to comment #63) > In my examples (#5/#6) and testcase 7 there are three columns specified. Not > two. Two columns seem to work ok with FF - but three do not. Right... I've been talking about working with 3 columns. I don't know why you're bringing up two-column situations now. > In my examples and testcase 7 - all widths are specified. No -- all *cells* have specified widths, but not all *columns*, and that's the bottom-line root of the problem here. As I pointed out in Comment 62, we basically have specified widths for columns 1 and 3 (because of the single-column cells in those columns), but we have **no specified width on column 2** -- its width is completely ambiguous (which is why we leave it at its default value of '0'). I think I made this pretty clear in comment 62 -- please re-read that if this doesn't make sense. > So the example you give doesn't work when you get to three columns. Two, yeah Um... My examples *used* three columns. I don't know why you're talking about two-column situations now. > Thus the need for the hidden line to give the table stability > in how it displays the columns. See comment 62 -- again, the "hidden line" simply gives specified widths to columns that otherwise have no width-information provided. You can get the same effect as your "hidden line" using <col> tags, as in attachment 353496 [details] > So I understand what you are saying about proportionally allocating widths if > not specified - but we are specifying the widths and FF ignores them. No, you aren't -- at least not in the examples 4-7. In those examples, there is *no specified width* on the second column. Really. So, again -- it starts out with (default) width=0, and as a result, it doesn't get any love from the colspanning cells, as described in my above comments. That's the way it goes. > In pseudo code this would be: > ... I have to go soon, so I'm not reading through all this pseudocode right now. However, I think I've pretty clearly addressed what's going on.
OH! Sorry - you are right. I misread your example. Ok - I'm obviously going too fast through this (working on other things at the same time). Let me go back over your last post again. Let me ask this: If you have a colspan='2' and the width is specified as width='200px', shouldn't each column get <100% of colspan's width>/2? Just as if you had a colspan='3' it should be X/3? (Either way you could get a fractional part. Like 15/2 = 7.5 (or 7 & 8). Now let me go back and re-read your last post again. Pseudo code though would make everything absolute rather than proportional or equal. Later! G'night! :-)
(In reply to comment #66) > OH! Sorry - you are right. I misread your example. Ok, cool :) > Let me ask this: If you have a colspan='2' and the width is specified as > width='200px', shouldn't each column get <100% of colspan's width>/2? Just as > if you had a colspan='3' it should be X/3? No -- it gets a chunk proportional to its current width. So if you have a wide cell and a skinny cell, spanned by a large colspan that gives them excess width, then the wide cell gets a bigger proportion of the excess width.
Good moring Mozilla! :-) Ok, after trying the <col...></col> on my report here is what I have to say: In this instance - the <col...></col> is the same workaround as my hidden line. It doesn't really solve the colspan problem - BUT! It will allow me to try to rephrase my original problem using the <col...></col> command. (I know - here we go again - but wait! Give me a chance here. :-) ) My first question is this: Since COLSPAN is just an extension of the COL command (in that COLSPAN simply means to have a COL that spans one or more columns) should not the COLSPAN command simply reduce itself down to the equivalent of one or more COL commands? (Uppercase being used just to differentiate between what I am saying and the HTML commands. Not meant to be yelling or anything like that.) My second question is: If you have <td colspan='2' width='200px'>...</td> Shouldn't the width's absolute size override any attempt by FF to change that width? This is to say that <td colspan='2'>...</td> Should have the width of the column calculated for the user(or web page or whomever it is being calculated for). But when the user specifies the width, should not FF stick to what the user has asked the width to be?
(In reply to comment #68) > My first question is this: Since COLSPAN is just an extension of the COL > command (in that COLSPAN simply means to have a COL that spans one or more > columns) should not the COLSPAN command simply reduce itself down to the > equivalent of one or more COL commands? No -- <col> and colspan do entirely different things. * <col> is a tag which allows you to specify a minimum width (and other styling) on an entire column. * colspan is an attribute on a table cell, which says "this table cell spans n columns". (and any excess width in this cell should be distributed among those columns) > My second question is: If you have > <td colspan='2' width='200px'>...</td> > Shouldn't the width's absolute size override any attempt by FF to change that > width? Well, first of all, we *are* honoring *that* absolute size (the 200px). In the attached examples, both colspanning cells end up being 200px-wide, as specified. So, Firefox isn't trying to change _that_ width. But in general (and in the particular case of the 100px-specified-width cells), no -- specifying a width on a table cell doesn't clamp it in the way that you're suggesting -- it really behaves more like a *minimum* width (particularly in cases where there's a colspanning cell that's wider than its spanned columns, as is the case here.) If you're interested, I'd suggest reading up on "Auto Table Layout" at http://www.w3.org/TR/CSS21/tables.html#auto-table-layout Anyway, this is one of the reasons that tables are kind of evil -- their behavior is underspecified, and they don't always do what you might expect. I think this bug page is pretty much done, though... any further questions/discussion should probably be moved to a thread on http://groups.google.com/group/mozilla.dev.tech.layout or http://groups.google.com/group/mozilla.dev.tech.css
Yep. My questions have been pretty much answered. Thanks again! :-)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: