Bug 3898

Summary: Fieldset layout incorrect when styled by CSS
Product: WebKit Reporter: David Blundell <david.blundell>
Component: Layout and RenderingAssignee: Dave Hyatt <hyatt>
Severity: Normal CC: ian
Priority: P2 Keywords: HasReduction
Version: 412   
Hardware: Mac   
OS: OS X 10.4   
Description Flags
Safari screenshot showing incorrect rendering
Firefox screenshot showing correct rendering
Explorer screenshot showing correct rendering
Test case as attachment
Minimal Testcase
Patch that fixes the bug mjs: review+

Description David Blundell 2005-07-07 14:54:00 PDT
When minimal CSS styling is applied to a form and fieldset, the fieldset layout
is incorrect when rendered by Safari (412).  Firefox 1.0.3 and Explorer 5.2.3
both render correctly.  I will add screenshots to this bug to demonstrate the
problem.  The shortest amount of valid XHTML that I could write to reproduce the
bug follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<style type="text/css">
input {margin-left: .5em;float: left;}
fieldset div {clear: both;margin: .1em 0;position: relative;}
label, fieldset div.cr {margin: 0;display: block;width: 13em;text-align:
right;float: left;}
.buttons {text-align: center;float: right;}
<form action="login" method="post" id="loginform">
    <input checked="checked" name="existing" type="radio" value="existing" />
    <label for="user_password">Yes, my password is:</label>
    <input type="password" name="user_password" id="user_password" size="23" />
    <input name="existing" type="radio" value="new-home" />
    <label for="user_password">No, I would like to create a home account.</label>
    <input name="existing" type="radio" value="new-business" />
    <label for="user_password">No, I would like to create a business
    <div class="buttons">
    <input type="submit" name="login" value="Login &#187;" class="primary" />
Comment 1 David Blundell 2005-07-07 14:55:03 PDT
Created attachment 2852 [details]
Safari screenshot showing incorrect rendering
Comment 2 David Blundell 2005-07-07 14:55:51 PDT
Created attachment 2853 [details]
Firefox screenshot showing correct rendering
Comment 3 David Blundell 2005-07-07 14:56:27 PDT
Created attachment 2854 [details]
Explorer screenshot showing correct rendering
Comment 4 Joost de Valk (AlthA) 2005-07-08 10:47:48 PDT
Confirmed, i will attach the code below as a minimal testcase.
Comment 5 Eric Seidel (no email) 2005-12-27 14:27:33 PST
Created attachment 5312 [details]
Test case as attachment
Comment 6 Eric Seidel (no email) 2005-12-27 14:28:25 PST
This really could use some further reduction.
Comment 7 Joost de Valk (AlthA) 2005-12-27 22:28:23 PST
Created attachment 5324 [details]
Minimal Testcase

This is very small, and should allow for some easy fixing :)
Comment 8 Joost de Valk (AlthA) 2005-12-27 22:28:57 PST
Changed NeedsReduction to HasReduction, since i just added it.
Comment 9 Dave Hyatt 2006-09-11 23:45:49 PDT
This is a fun bug.  Apparently there's an unspecified behavior for fieldsets, which is that they behave in a fashion similar to floats.  If the height of a fieldset is auto then it expands to encompass overhanging floats (just as an enclosing float might).

This would be an interesting thing to note in the HTML5 WhatWG spec, as this behavior is not documented anywhere that I can find.
Comment 10 Dave Hyatt 2006-09-11 23:48:27 PDT
Created attachment 10510 [details]
Patch that fixes the bug

Create a new method, allowOverhangingFloats(), and better factor the code so that fieldsets and table cells can subclass for their respective specialized behaviors.
Comment 11 Maciej Stachowiak 2006-09-12 00:04:53 PDT
Comment on attachment 10510 [details]
Patch that fixes the bug

I would consider reversing the sense of allowOverhangingFloats and naming it something like expandsForOverhangingFloats().

In any case r=me
Comment 12 Dave Hyatt 2006-09-12 00:21:57 PDT
Comment 13 David Kilzer (:ddkilzer) 2006-09-12 08:04:09 PDT
(In reply to comment #12)
> Fixed.

In r16319.  Tests in r16320.