Closed Bug 50825 Opened 24 years ago Closed 24 years ago

Various strict-mode problems on www.elflife.com

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mozbug, Assigned: clayton)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(4 files)

testcase [1]
158 bytes, text/html
Details
testcase [2]
436 bytes, text/html
Details
testcase [3]
325 bytes, text/html
Details
testcase [4] (see 2000-09-14 comment for explanation of testcases)
529 bytes, text/html
Details 
Using M17,M18 build 2000082915 and M18 2000083008 on Nt4 Sp6a and Win2000Pro.

The main page at http://www.elflife.com is not rendered correctly.

Actual result: a picture is placed all down the page.

Expected result: the picture should be placed near the top as in Netscape 4.xx
and Explorer 4&5
Something strange :
I saved the page and all the pictures in it on my disk and opened it in Mozilla :
the page appears as it should.
So the point is : it is rendered correctly from my disk and not from the web site.
Doctype is
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 //EN">
but document is far (and i mean FAR) from being a valid html4.0 strict document.
Main problem seems to be a missing starting <tr>
Changing doctype to
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
should fix the problem (can't check, host isn't responding anymore)
page crashes for me
Using transitional doctype gives correct layout (with 082921 build as 090208
seems to have highly broken js and crashes on the page)
Yep, the page crashes with M18 Build2000090308 on NT4 SP6a and Win2000
OS: Windows 2000 → All
Still crashes with build 2000090408 on Nt4 Sp6

I don't think it has something to do with javascript because the paga crashes
mozilla with javascript disabled
Severity: minor → critical
Doesn't crashes if all file are saved locally.
Now it doesn't crash but still renders incorrectly using build 2000090708 on win2000
I'm simplifying this page.  (lowering from critical since the crash seems to 
have disappeared.)

BTW, sconest: saving the page and adding something like 
<base href="http://www.elflife.com/"> to the <head> generally confuses things 
less than saving all of the images as well as the page.
Severity: critical → normal
Keywords: makingtest
i get the comic all the way on the bottom right of the page, and it doesn't crash.

build 2000091212. Linux
Things that don't happen only in strict mode (split):
bug 52596: bold, "ms sans serif" text expands when selected

Things that happen only in strict mode:
[1] hex colors don't work without pound symbol (#)
[2] table inside <table><tr><td><font> ignored (calendar, black news box)
[3] table<br>table<br> expected to give space like <p> but doesn't
[4] <table><td>tables</td></table>, strange things happen (main problem)

Ian, can you please verify that these four strict-mode bugs are invalid and 
then send this bug to evangelism, or mark this as a dup of bug 50070?  I will 
attach testcases.

(Hint to evangelizer: tell the elflife people that we did find a legit bug in 
Mozilla while playing with their page, unless bug 52596 ends up as dup or 
invalid.)
Keywords: makingtest → testcase
Summary: Elflife.com not rendered correctly → Various strict-mode problems on www.elflife.com
Attached file testcase [1] — 

    
    

    
  

      
      
      
      

        Attached file
          
        testcase [2]
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        testcase [3]
        — 
      

    


  

    
    

    
  
Using build 2000092120, the page is rendered like it should be.


    
    

    
  
[2] and [3] work ok now.  [4] doesn't render the same way as IE but is more 
similar now than it was before.  [1] hasn't changed.

    
    

    
  
Testcase [1] is invalid on several counts: BGCOLOR is not valid in strict mode,
and even if it was, it would not be valid without the leading '#' on the hex
colour code. So we do that correctly.

[2] and [3] are ok per previous comment (unchecked).

[4] is correct, since we no longer apply the margin quirks in strict mode.

Ergo, this bug is INVALID. Marking as such.

Thanks for all the help guys!! (And especially thanks for the four amazing 
testcases! They rock!)
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: