Closed Bug 165261 Opened 22 years ago Closed 21 years ago

<hr style="width : auto"> not working if <hr> is block

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: halcanary, Unassigned)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(1 file, 1 obsolete file)

slightly more extensive testcase
598 bytes, text/html
Details 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html><head><title>Boog!</title></head><body>
<hr style="width : auto; margin : 3ex;">
<hr style="width : auto; margin : 3ex; display : inline;">
</body></html>

I've run across this bug in mozilla 1.1 and 1.0, on both win2k and linux.  I'm
guessing it's a gecko problem, but I could be wrong.  

The <hr>'s width is by default 100%.  This can be changed to any percentage or
fixed length.  But I can't seem to change it to "width:auto".

This only happens under strict compliance mode.

Workaround:  use "display:inline;"
So, HR is treated like a replaced block element, adding 100% of the containing
block to the 6ex margins.

Setting margin:auto "cures" the problem.

Confirming on Mac OS X, 1.1 release, although it is a style issue.
Attached file testcase HTML (obsolete) — 
attached above HTML as testcase
confirming on trunk 20021015
Assignee: asa → attinasi
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: asa → petersen
Priority: -- → P3
Target Milestone: --- → Future
OK, well this is "easy" to fix.  Just subtract the margins off the available
width when computing the desired width.  Except that's not the right way to do
it if the <hr> is display:inline, since the available width for inlines already
subtracts off their margins...

So we could work on some consistency in the availableWidth values we pass
around.  Or we could just stop doing the HRuleFrame thing in standards mode and
use a block with some CSS on it.  I looked over HRuleFrame::Reflow and
HRuleFrame::Paint, and this should be doable (even including noshade support)
except for all the selection voodoo that HRuleFrame does (in Paint() and in
GetContentAndOffsetsFromPoint()).

mjudge, is there a reasonable way of moving those out into CSS so that we can
use a regular block/inline/whatever frame for <hr>?
Assignee: attinasi → other
QA Contact: cpetersen0953 → ian

        Attachment #103031 -
        Attachment is obsolete: true

    
    

    
  
This happens in quirks mode too if you style the <hr> as "display: block".
OS: Windows 2000 → All
Priority: P3 → --
Hardware: PC → All
Summary: <hr style="width : auto"> not working under strict mode. → <hr style="width : auto"> not working if <hr> is block
Target Milestone: Future → ---

    
    

    
  
> Or we could just stop doing the HRuleFrame thing

You mean like my (heavily bitrotted) patch does in bug 38370? I think that's
what we should do in general. Someone just needs to take that patch and bring it
up to date (which means rewriting it to work in a rule-tree world, since that
patch was written in a pre-rule-tree environment).

    
    

    
  
Hey, if we can resolve the selection issues, I'd be happy to do that.
Depends on: 38370

    
    

    
  
The original problem reported is WFM, 2003-08-14-22 trunk Linux.
Keywords: testcase

    
    

    
  
This has been fixed by the patch in bug 38370 which got checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: