Last Comment Bug 33244 - [FIXED]TD Shouldn't have to have a spacer gif for background color to show
: [FIXED]TD Shouldn't have to have a spacer gif for background color to show
Status: VERIFIED FIXED
: testcase
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: x86 Windows 98
: P3 normal (vote)
: M16
Assigned To: Pierre Saslawsky
: Christine Hoffman
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-03-24 15:13 PST by Johnny Proton
Modified: 2001-04-04 22:11 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase in strict mode. Both rows of the table should render equal. (322 bytes, text/html)
2000-03-24 20:20 PST, Jonas Sicking (:sicking) No longer reading bugmail consistently
no flags Details

Description Johnny Proton 2000-03-24 15:13:19 PST
Mozilla forces HTML programmers to put something inside each table cell even in
cases when all we want to display is the background color of a cell.

This is pervasive, as far as I can tell, and applies to both the HTML bgcolor
and the CSS background-color declaration.  It shouldn't be necessary to put a
spacer gif inside each table cell, as it only bloats the code and forces
unnecessary download by the client.

This is, in my opinion, a pretty important bug, and would really help reduce
time for HTML development, while also simplifying the code we have to work with.

- Aaron Buckner
- http://cicadadesign.com/
Comment 1 Jonas Sicking (:sicking) No longer reading bugmail consistently 2000-03-24 20:16:29 PST
According to the CSS2 spec the default value for empty-cells should be 'show'.
Mozilla currently has 'hide' which is correct in quirks mode but not in strict mode.
Comment 2 Jonas Sicking (:sicking) No longer reading bugmail consistently 2000-03-24 20:18:39 PST
Guess this is more a layout problem since it is just the default css value that
is wrong.

Chaning component and reassigning...
Comment 3 Jonas Sicking (:sicking) No longer reading bugmail consistently 2000-03-24 20:20:24 PST
Created attachment 6925 [details]
Testcase in strict mode. Both rows of the table should render equal.
Comment 4 troy 2000-03-25 09:02:10 PST
Changing back to tables, because it sounds table specific to me
Comment 5 Jonas Sicking (:sicking) No longer reading bugmail consistently 2000-03-31 15:09:24 PST
This actually is a stylesystems bug since it is just the default value 
of 'empty-cells' that is wrong. Should be:

In quirks: 'hide'
In strict: 'show'

(Is now 'hide' in both)

Note to abuckner@cicadadesign.com, the problem of backgrounds not shown even 
when empty-cells are set to 'show' is covered in bug 8113.
Comment 6 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-04-02 13:47:11 PDT
The default value could be 'hide' for the TABLE element in HTML, though...
Comment 7 Jonas Sicking (:sicking) No longer reading bugmail consistently 2000-04-02 15:22:24 PDT
According to the HTML spec empty cells should show (or rather; there is nothing 
in the spec that says that they should hide) so I still think this has to be 
solved by using a quirks hack.
Comment 8 Pierre Saslawsky 2000-04-10 16:47:20 PDT
I'll check in the fix when the tree opens.
Thanks to sicking@bigfoot.com for the testcase and the investigation.
Comment 9 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-04-10 18:16:34 PDT
What fix is being checked in?  Will it affect conformance to section 17.5.1
(rule 6) of CSS2?
Comment 10 Pierre Saslawsky 2000-04-10 18:51:01 PDT
I changed the default value for empty-cells: 'hide' in quirks mode and 'show' in 
strict mode. MacIE5 does the same thing.

The transparency of empty cells (17.5.1#6) was broken and stays so (bug 8113). 
I'm going to attach a small testcase there.
Comment 11 Pierre Saslawsky 2000-04-14 20:51:22 PDT
fix checked in nsStyleContext.cpp
Comment 12 Christine Hoffman 2000-08-11 14:59:08 PDT
Verified bug fixed. Quirk default is 'hide' and strict default is 'show'
Comment 13 Brian 'netdragon' Bober 2001-03-29 22:00:03 PST
Quirks mode / Nav DTD 
A document without a DOCTYPE declaration 

from: http://www.people.fas.harvard.edu/~dbaron/mozilla/modes

I don't agree quirks mode should have a need for a spacer image. There is 
nothing that will get broken by removing the need for the spacer for existing 
pages. If the spacer is placed there, it will not affect anything and will work 
fine whether show is default or not. Therefore, show should always be default.

Anyway, a lot of pages don't have any doctype and should be automatically 
transitional, not quirks.

The quirks mode rendering is incorrect, and fixing it won't have any adverse 
affect.

Netscape 4.x had a bug in this respect, and if someone forgets to put the 
doctype, they will see this bug. I don't think that is correct.
Comment 14 Brian 'netdragon' Bober 2001-03-29 22:04:10 PST
Please see the recent changes to bug 8113.
Comment 15 Johnny Proton 2001-03-29 22:11:31 PST
Quirks mode shouldn't be the default.  I think the name "Quirks" says it all.
Comment 16 Jonas Sicking (:sicking) No longer reading bugmail consistently 2001-04-04 11:16:43 PDT
*Please* don't make this into a "what should trigger quirks/standard mode" bug!

However the default value for empty-cells in quirks mode could do with a 
discussion (I'd personally like 'show' to be default). But I'd recommend 
starting that discussion in n.p.m.layout
Comment 17 Hixie (not reading bugmail) 2001-04-04 21:04:47 PDT
Quirks mode _isn't_ the default. We only do it for stuff sent over the wire as
text/html, and even some of those get treated in Standard mode.
Comment 18 Johnny Proton 2001-04-04 22:11:54 PDT
I know that by default mozilla renders Empty Cells as "hide".  And that's about 
all I know, except I know I shouldn't have to put a spacer GIF in a TD to assign 
a background color.

Anyone who does HTML often know's this is a major deficiency and that MSIE 
already [correctly] displays empty cells as "show".  I like Mozilla, but this 
should honestly be an easy one!

Note You need to log in before you can comment on or make changes to this bug.