Closed Bug 42180 Opened 24 years ago Closed 24 years ago

<pre> element treated as inline element -- should be block

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: waterson, Assigned: rickg)

References

(
URL
)

Details

(Keywords: html4, regression, Whiteboard: [nsbeta2+] was: in DEBUG builds, <pre> text is displayed with tags in strict mode)

Attachments

(2 files)

minimized test case
128 bytes, text/html
Details
revised testcase
128 bytes, text/html
Details 
The ingredients seem to be

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

(That means "strict mode", right?), and some <pre>-formatted text with embedded 
tags; e.g.,

  <pre><a name="1">1</a></pre>

Expected result: see a blue, underlined "1". Actual result:

  <a>1</a>

I'll attach a minimal test case.
Attached file minimized test case — 

    
    

    
  
The doctype literally means transitional, which is only barely different from 
strict. (I'll give you the gory details if you really care.)

I'll take a look.

    
    

    
  
Yup -- pre is definitely broken. I'll dig deeper.

    
    

    
  
Marking nsbeta2 because: 1) <pre> tags are commonly used; 2) it's a trivial fix 
(in hand) and 3) RickG is going on sabbatical, so it's now or never.
Status: NEW → ASSIGNED
Keywords: nsbeta2

    
    

    
  
Fix in hand
Whiteboard: fix in hand

    
    

    
  
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: fix in hand → [nsbeta2+]fix in hand

    
    

    
  
Fixed by treating the <pre> element like the inline that it is.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
Minor problem though Rick... <pre> isn't an inline element! This 'fix' has 
broken most of my test pages, since <pre> content is now being dropped if it
is child of <body>, which is perfectly legal.

Reopening. If you need a specific test case, give me a shout.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: in DEBUG builds, <pre> text is displayed with tags in strict mode → <pre> element treated as inline element -- should be block
Whiteboard: [nsbeta2+]fix in hand → [nsbeta2+]  was: in DEBUG builds, <pre> text is displayed with tags in strict mode
Blocks: html4.01
Keywords: regression

    
    

    
  
*** Bug 42698 has been marked as a duplicate of this bug. ***

    
    

    
  
From bug 42698 by David:

DESCRIPTION:  The [following] URL has two PRE elements that aren't showing up.
Neither they nor any of their contents are in the content model.

STEPS TO REPRODUCE:
 * load http://www.people.fas.harvard.edu/~dbaron/www/httpreq

ACTUAL RESULTS:
 * No HTTP headers listed.

EXPECTED RESULTS:
 * lots of HTTP headers listed

DOES NOT WORK CORRECTLY ON:
 * Win98 mozilla 2000-06-15-08-M17

ADDITIONAL INFORMATION:
 This is a major regression, and thus nominating nsbeta2.


    
    

    
  
Ack! Yes, of course, what was I thinking. I was attempting to get the right 
answer (which is to allow inline elements in pre) but went too far. Fixed 
(again) in my tree. 

    
    

    
  
Ack! Yes, of course, what was I thinking. I was attempting to get the right 
answer (which is to allow inline elements in pre) but went too far. Fixed 
(again) in my tree. 
Status: REOPENED → ASSIGNED

    
    

    
  
Landed fix. Please retest.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
Reopening
I get a 1 with no <a> tags, but the 1 is not a link (no underline)

2000-07-12-11-M17 : Linux
2000-07-12-09-M17 : WinNT & Win98
2000-07-12-13-M17 : Mac

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Not sure, if this is important, but the first assumption is wrong. With the 
current source the DOCTYPE will NavQuirks rendering. This happens because the 
SystemID is missing. Use the following DOCTYPE to get STANDARD/TRANSITIONAL 
mode:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd"> and this one to turn STANDARD/STRICT on:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd">

For further details please look into nsParser.cpp. However all modes render 
equally - a 1 without an underline.

    
    

    
  
Chris's original description of expected behavior was wrong - there should be no
underline in his testcase.  I attached a revised testcase with the name changed
to href, so there should be an underline.  Marking fixed again.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago

    
    

    
  
Reopening to resolve correctly.
Status: RESOLVED → REOPENED

    
    

    
  
Resolving again
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago

    
    

    
  
With 4.x now, reopening...
Status: RESOLVED → REOPENED

    
    

    
  
And resolving as ***FIXED***.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
looks good to me
Marking verified.
Verified
2000-07-17-13-M17 : Linux
2000-07-17-09-M17 : WinNT & Win98
2000-07-13-08-M17 : Mac

Status: RESOLVED → VERIFIED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: