Closed Bug 1968 Opened 26 years ago Closed 26 years ago

Table background & Progressive Rendering problems

Categories

(Core :: Layout: Tables, defect, P2)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jordy, Assigned: peterl-retired)

References

(
URL
)

Details

(Whiteboard: (04/06) 3jrgm@qlink.queensu.ca -- review complete)

The table on the right of the Wired page does not proegressively render (must download completely and then flashes up). There is also a table within that table on the right which is displaying completely with a black background, which is incorrect.
Assignee: michaelp → karnaze
Component: Rendering → HTMLTables
Re-assigning to Chris, because it's a table problem
Status: NEW → ASSIGNED
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Whiteboard: (04/06) 3jrgm@qlink.queensu.ca -- review (partially) complete
Two problems noted on this page: (www.wired.com/news/) 1) the black table 2) the progessive rendering problem. Here is the breakdown for (1). I will post another note about (2) in a while (it may be covered elsewhere, already). The black table is a result of the fact that Wired uses the letter "O" instead of the number "0" to spec the table background colour. I presume that both 4.x and 5.0 toss the colour and pick a default, but that the default for 4.x is "white" while the default for 5.0 is "black". <!-- FOFOFO != F0F0F0 ... i.e., (Oh != zero) --> <html><body> <table bgcolor="#FOFOFO" border="1" width="152"> <tr> <td>&nbsp;</td> <td>&nbsp;</td> <td align="left"> <br><a href=""><b>Rants & Raves</b></a><br> Readers on Mozilla ... <cite>The Matrix</cite>.<br><br> </td> </tr> </table> </body></html>
Whiteboard: (04/06) 3jrgm@qlink.queensu.ca -- review (partially) complete → (04/06) 3jrgm@qlink.queensu.ca -- review complete
If you strip away the header section, the 'progressive display' bug is still in effect. At that point, the layout is handling a page with two main independent tables: a left column (1), and a content payload (2). +------+ +-----------------------+ | | | | | | | | | | | | | (1) | | (2) | | | | | | | | | | | | | | | | | +------+ +-----------------------+ Table (1) is ALIGN=LEFT, and contains three FORMs that will paint prior to the rest of the table(s), and are reflowed when table (2) is handled. Table (2) specs no alignment (but gets the default). This looks like a job for Kipp, since the tables themselves are fine, but the floating of them is not quite right. (Perhaps this floater issue should go in as a separate bug from the 'table background color' bug noted on the same page. This floater issue may already be a known problem). I've posted a semi-simplified example page at: http://qsilver.queensu.ca/~buslib/1968/
Just to be clear: the 'two tables' above are free floating (i.e., there is no "containing" table wrapped around them).
Assignee: karnaze → peterl
Status: ASSIGNED → NEW
Target Milestone: M4 → M5
I'm reassigning to Peter to resolve the background issue (see test case in 4/6 comments) and moving to M5. The main problem I saw in http://qsilver.queensu.ca/~buslib/1968/ was the left table crowding the buttons off the same line as the text fields. In ua.css margin-right is set to 10px for <input type=text> and <input type=password> which is incorrect. In my next checkin, I will change that, and it solves the crowding problem.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Using 4/30 Apprunner, page renders properly. Verifying bug fixed.
You need to log in before you can comment on or make changes to this bug.