269908 - <legend> default style changes restrict styling options

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Thomas O'Connor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041112
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041114 Firefox/0.9.1+

Can you please remove " ! important" from the float property of <legend> in the
resource://gre/res/forms.css file (addition shown in
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/layout/html/document/src&command=DIFF_FRAMESET&file=forms.css&rev2=3.92&rev1=3.91
)?

From what I have heard float wasn't causing the problems in the first place, and
it is the only way in which designers can break <legend> out of its rigid position.

The addition of these two line, from what I have heard and read, came as a
result of a bug[5] in the rendering engine surrounding an instance when
<legend>'s position was set to absolute or fixed. While I can see how
restricting position to static fixes this bug, I do not see the need to restrict
float as well. If float was left unrestricted it would mean that you could
manipulate it in the method which I currently practice. All that it would take
to allow for this is the removal of " ! important" from
resource://gre/res/forms.css, a total of 12 characters/96 bytes[1].

Opera, Internet Explorer, Safari and Konqueror all support this method. Gecko
did as well until this recent change.

I can see no perceivable downside in making this change to the stability of the
rendering engine, only the benefits of the extra styling. I checked to see
whether the browser (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5)
Gecko/20041114 Firefox/0.9.1+) crashed, hung, or malfunctioned in any way when
floating is allowed. The browser worked fine when the <legend> had float: left;
applied. I disabled the override by editing line 62 of
resource://gre/res/forms.css (found in C:\Program Files\mozilla.org\Mozilla
Firefox Nightly\res\forms.css on my Windows installation) from float: none !
important; to float: none/* ! important*/;.

Having such a restricted layout of this element not only limits the extend to
which developers can manipulate it to suit their needs but also might lead to
developers avoiding it due to this issue, thus leading to a loss in semantic
value of the page, which I doubt anyone would like to see for the greater good
of the web.

We should be encouraging people to use this very useful element - its benefits
extend to accessibility and semantics - making the web technologically better.
By enforcing such a strict layout you surely are impeding and limiting its uses,
as some might forsake the benefits it provides for the aesthetic appearance of
their site (however I would not personally).

It has been said this element and its parent <fieldset> are form controls. I
strongly disagree with this notion. They allow for form controls to be separated
and distinguished, just like <label>. They are not form controls themselves, as
a form control has a state and can be submitted to the server. Also it is not
defined where it should go or how it should look so the author should be able to
use CSS to style it to suit [2].

Also brought up was this issue of styling, and the inability to render a
<fieldset> and <legend> in their current way with CSS. The ability to be styled
using CSS I believe would benefit the push for flexibility of this combination.

Although my primary aim is to see the restriction of float lifted, in the long
run it would probably be better if the bugs associated with certain styles and
<legend> were sorted out, as well as the ability to completely unlock it from
it's locked state using CSS (which would be easier to implement if the current
rendition of <fieldset> and <legend> was able to be done in CSS).

Your consideration on this matter is appreciated.

   1. Whilst the removal of the leading space isn't a requirement to let this
change take place, for tidiness sake it would be best removed.
   2. Thank you to red_one in irc://irc.freenode.org/#web for his thoughts on
this matter, and CloCkWeRX for his time.
   3. Also thank you to bz, Callek, fantasai and any other members of
irc://irc.mozilla.org/#developers for assistance and time regarding this matter.
   4. Please note: I am not complaing to you as to the short falls of CSS,
merely asking you to remove the float restriction on <legend>. Any comments
regarding CSS's lack of ability in any area is just provided for information
purposes.
   5. https://bugzilla.mozilla.org/show_bug.cgi?id=263406


Reproducible: Always
Steps to Reproduce:
Float a <legend>

<style>legend{float:left;}</style>
<fieldset><legend>bob</legend></fieldset>
Actual Results:  
In the recent nightlies: no change.

Expected Results:  
The legend should have dropped below, breaking out of the <legend>'s normal
rendering, as it did before (
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/layout/html/document/src&command=DIFF_FRAMESET&file=forms.css&rev2=3.92&rev1=3.91
).

For an online demostration and markup version of this bug and report please see
http://bugs.ocoth.id.au/mozilla/2/ .

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'd like to see testcases that demonstrate that if we removed the !important on
'float: none', we would actually be interoperable with other browsers, rather
than just "doing something different".  In particular, they should test both
left and right floating, and should test margin, padding, and border, on both
the fieldset and the legend.

Comment 2

[Shane P. McCarron]

Why is it not possible to position this item?  That doesn't make any sense.  And
the answer really shouldn't be "'cause that's how IE does it"

Comment 3

[Boris Zbarsky [:bzbarsky]]

It's not possible, because fieldset/legend cannot be described in CSS, so
applying CSS to them has major intrinsic issues.  We consider it better to
follow the spec by doing nothing and then fixing things if or when the spec
covers this case instead of implementing something page authors will depend on
that will contradict what the spec comes to say.

Comment 4

[Shane P. McCarron]

Well - which spec do you think you are following by not permitting styling on
these elements?  And have you asked the W3C CSS Working Group for an
interpretation (assuming this is a W3C spec we are talking about)?

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Well - which spec do you think you are following by not permitting styling on
> these elements?

There is no spec that either requires or prohibits that the styling be allowed.
 Given that, not conflicting with future spec extensions is the way to go.

> And have you asked the W3C CSS Working Group for an interpretation

This change was made at the explicit request of a W3C CSS Working Group member.

He also commented in comment 1, describing what would need to happen for this
change to maybe be reversed.

Comment 6

[Jake Carlson]

As of Firefox 1.5, the legend element is not positionable *at all*.  It used to be floatable and positionable to a certain degree.  This is causing massive problems for standards-compliant forms that use the legend element but need it to be styled.

Comment 7

[Jake Carlson]

"There is no spec that either requires or prohibits that the styling be allowed. Given that, not conflicting with future spec extensions is the way to go."

This is absolutely and utterly false.

http://www.w3.org/TR/html4/interact/forms.html#h-17.10

The HTML 4.01 specification upon which XHTML has subsequently been based clearly states that the LEGEND element allows the "style" attribute.  That is proof positive that the W3 supports styling of the LEGEND element in its own documentation.

Furthermore, the WCAG 1.0 Guidelines encourage the use of proper structural markup in forms.  This means that the LEGEND element should be used to label groups of form inputs.  To not allow the styling of this structural element will cause accessibility-conscious developers such as myself to not use it anymore, resulting in less accessible forms.

http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms

For the life of me I cannot understand why Mozilla would support such a blatant disregard for accessibility and the W3 specification.

Please, allow styling of the LEGEND element. 

Comment 8

[Boris Zbarsky [:bzbarsky]]

> As of Firefox 1.5, the legend element is not positionable *at all*.

Yes, that's what this bug is about.

> It used to be floatable and positionable to a certain degree.

And very very buggy, note.

> This is absolutely and utterly false.

It's absolutely and utterly true.

> clearly states that the LEGEND element allows the "style" attribute. 

Sure.  You can apply CSS to the element.  That's all the HTML spec says.  The CSS spec then doesn't define what CSS should do on the element in question.

> For the life of me I cannot understand why Mozilla would support such a
> blatant disregard for accessibility and the W3 specification.

Frankly, because we haven't figured out how to make legend floatable and positionable in a sane way yet and because disabling those to fix major real issues (crashes, etc) did not violate any specifications.

If you feel that strongly about this, I welcome your help in making this work correctly; I suspect you'll need to start by completely rewriting the fieldset and legend implementation.

Comment 9

[Jake Carlson]

So... where does the spec explicitly spell out which CSS properties can be applied to each element? Show me where it breaks down each element and which CSS properties can be applied, and then show me where the legend element is absent from this list. Of course there is no such list. 

Yet by the reasoning through which this decision has been made, no element should allow any CSS properties to modify its display at all, because the W3 does not spell it out for *any* element.  The command to user agent makers is to go forth and allow styling, plain and simple.

All elements should allow styling, and I see no reason why the properties which can be applied to any given element should be limited in any way.  It seems, then, that this a browser bug as stated above.

It's too bad I don't have the time or knowledge to fix it.  I would be most grateful to whomever took it upon himself/herself to allow styling of the LEGEND element in CSS.  This single issue deeply sours my respect for the CSS implementation of Firefox.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> So... where does the spec explicitly spell out which CSS properties can be
> applied to each element?

The point is, <fieldset>'s default rendering cannot be described in terms of CSS.  So <fieldset> is effectively much like a replaced element in Gecko.  Please look up replaced elements in the CSS spec.

> All elements should allow styling

Should you be able to position the <option>s in a <select>?  Should you be able to position the <area> elements in a <map>?  Or set their sizes via CSS?  Please don't make blanket statements like that without thinking them through.

Comment 11

[Jake Carlson]

"The point is, <fieldset>'s default rendering cannot be described in terms of
CSS.  So <fieldset> is effectively much like a replaced element in Gecko. 
Please look up replaced elements in the CSS spec."

The fieldset element's rendering can be described in terms of CSS. Here's why:

1)  The developers of Firefox chose to make fieldsets look like they do by default. If the decision they made renders the fieldset outside the scope of the CSS formatter, that is a problem of their own creation.

2)  The fact is, the fieldset element does support styling - just not very well.

3) Even the current implementation of the fieldset element can be fully described by properties specified in css 3.  The "border-radius" properties can be used to round corners. The borders margins, padding, and background can all be set.

http://www.w3.org/TR/css3-content/
http://www.w3.org/TR/CSS21/conform.html

The latter defines a "replaced element":

"An element that is outside the scope of the CSS formatter, such as an image, embedded document, or applet. For example, the content of the HTML IMG element is often replaced by the image that its 'src' attribute designates. Replaced elements often have intrinsic dimensions: an intrinsic width, an intrinsic height, and an intrinsic ratio. For example, a bitmap image has an intrinsic width and an intrinsic height specified in absolute units (from which the intrinsic ratio can obviously be determined). On the other hand, other documents may not have any intrinsic dimensions (for example a blank HTML document).

User agents may consider a replaced element to not have any intrinsic dimensions if it is believed that those dimensions could leak sensitive information to a third party. For example, if an HTML document changed intrinsic size depending on the user's bank balance, then the UA might want to act as if that resource had no intrinsic dimensions."

I'm not sure I agree that the fieldset element is a replaced element. In any case, it certainly doesn't need to be.

"Should you be able to position the <option>s in a <select>?  Should you be able to position the <area> elements in a <map>?  Or set their sizes via CSS? 
Please don't make blanket statements like that without thinking them through."

I thought through this statement, and I stand by it. I don't know why you would want to position an option in a Select element, but I see no reason why it should be prohibited. I'd love to have mere control over that element.  The area element is similar. I don't know what use it would be to position it, but why prohibit that?

The fact is that I can do all kinds of things with css that may seem odd (and even stupid), but I can still do them! I can position an element off everyone's screen visually just so that the visually impaired have the benefit of them.  I can permanently hide elements altogether. I can make text too small to read. I can try to deceive search engines (but I don't). I can do all these things, both good and bad, and now you say I should not be allowed to just because you personally don't understand my intentions? I find this disturbing.

The bottom line is that there is no good reason why the developer has such poor control over the fieldset and legend elements other than that it apparently wasn't a priority. Let's just admit it's a problem, wait for someone to fix it, and move on.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> The developers of Firefox chose to make fieldsets look like they do by
> default.

No other rendering makes sense; try changing the default rendering and see how much screaming will ensue.

> The fact is, the fieldset element does support styling - just not very
> well.

It supports it as well as it can given the other constraints.

If you think you know how this should all work, please feel free to write a patch.  I'll be happy to review it and get it checked in, if it's correct.

Comment 13

[Ben Boyle]

Very tricky! I thought it would straightforward to implement the default rendering simply through CSS in the default style sheet, but a quick test implementing those styles and I'm forced to concede the complexity is real; see http://inspire.server101.com/bttdb/html/forms/legend/

It's straightfoward enough to style a legend in this default manner (positioned to obscure the fieldset border). The issues are:
1. position absolute/relative set on fieldset and legend elements
2. background-color specified on legend element (to obscure fieldset border)

Nothing wrong with doing the above in your style sheet when authoring a website, but would you really want those styles built into the browser as defaults? Even if you did, such changes made now would have a major impact on existing web pages. I'm pretty certain most authors agree that do not want browser implementors creating issues like that.

I would also like to see this bug fixed (I would like to reposition legends on some of my forms) but unfortunately wouldn't know where to begin to fix it. Hopefully these comments are of some help. Beyond that — roll on XForms!

Comment 14

[Taylor Mathewson]

Why not do something like default the display attribute to "-moz-fieldset" and "-moz-legend" for the fieldset and legend elements respsectively.

These values indicate GRE should apply the specific rendering values that are hard/impossible to apply via css.

This would allow people to apply a display:block or display:inline to these elements and provide custom styling.

Comment 15

[Boris Zbarsky [:bzbarsky]]

> Why not do something like default the display attribute 

Because people style fieldsets as "block" and expect them to still be fieldsets.

Comment 16

[Gordon]

> Should you be able to position the <option>s in a <select>?  Should you be able
> to position the <area> elements in a <map>?  Or set their sizes via CSS? 
> Please don't make blanket statements like that without thinking them through.
> 

These are flawed examples as a legend tag has a lot more in common with a hx or a th tag than it does with an option tag.  hx and th can be styled, hell, you can even style legend in IE (which is probably the only case where IE does the Right Thing whereas Moz doesn't).  It seems to me from what I've read here that there are bugs in the layout engine but instead of fixing them the developers simply papered over the cracks and disabled styling rules that could provoke unexpected behaviour from the engine.  

I have a great deal of respect for Moz and for the most part love the CSS implementation. I use Moz as my default development platform, but the legend problem is simply not excusable.  I'm having to use H2s to title my fieldsets instead and leave empty legend tags so that the pages pass validation.  This reeks of the bad old days of tag soup and tabled layouts.  Please fix it properly.

Comment 17

[Boris Zbarsky [:bzbarsky]]

> It seems to me from what I've read here that there are bugs in the layout
> engine

Then you haven't read very well, sorry.

Now I agree that there might be non-CSS hacks we could do that would be better than the non-CSS hack we do now.  But I haven't thought of one yet, and neither has anyone else.  See comment 12.

Comment 18

[Jake Carlson]

> Now I agree that there might be non-CSS hacks we could do that would be better
> than the non-CSS hack we do now.  But I haven't thought of one yet, and neither
> has anyone else.  See comment 12.

Folks, by now it should seem pretty obvious to anyone that has read this thread that the behavior of <LEGEND> in Firefox sucks.  It's also apparent that nobody that actually knows how to fix it is going to.

It seems rather simple to me, but then again I have never and don't know how to develop or patch a browser.  I just have to put up with them.  :)

The default styling of a legend should be display:inline w/ the background color set to that of the parent element (fieldset), if there is no better way to cover up a fieldset's border.  (There obviously is since it's being done now.)  If the parent fieldset were position:relative, the legend should be absolutely positioned however far from the left it is now and -((x/2) + (Y/2)) from the top, where X is the thickness of the top border and Y is the height of the legend element.

Fieldset = block; legend = inline.  And of course all of that styling can be overridden via CSS.  For the life of me I cannot understand what is so difficult to grasp about this concept.  This would also solve that annoying problem of having background color outside the top border when you specify the fieldset as having top padding.  It's just so darn irritating.  If Firefox developers can make the fieldset and legend work in some custom funky way like they do now, why the hell can't they make those elements behave like all the other elements we're used to being able to style?

I work at a prominent web company, and I've had to create a very kludgy hack just to get around this problem.  I put in the semantic form, complete with proper <legend> elements.  Then I replace the <legend> elements onload via Javascript with <strong> tags, which I can style as I please.  The result is that the original markup is accessible and standards-compliant, but the form jumps around onload just to make the form look alright.

These are the insane workarounds we have to invest in, simply because browsers don't behave as they ought.  FireFox is supposed to be a beacon of standards-compliance that the rest of the browser world ought to emulate.  Yet this fieldset/legend problem absolutely forces a kludgy/non-standards-compliant implementation of forms.

Will someone just please fix it and stop bitching about how it can't be done?  I KNOW it can be done, because doing it properly is almost certainly easier than doing it the way that it's been done.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Yes, we all agree the current behavior is suboptimal.

> It's also apparent that nobody that actually knows how to fix it

The problem is that there is nobody who knows how to fix it.  At least without a LOT of work.

> It seems rather simple to me

If every time someone said this in a bug the bug would get fixed... ;)

> the background color set to that of the parent element (fieldset)

This is usually transparent, so this idea won't fly.

> There obviously is since it's being done now.

The way that's done now cannot be expressed in CSS.  It involves the fieldset explicitly knowing about the legend and drawing the border around it.  To make the "explicitly knowing about the legend" part work, the legend cannot be out of flow.  Hence this bug.

> If the parent fieldset were position:relative

Unfortunately, doing that by default is also not an option -- it'd break existing sites.

> Fieldset = block; legend = inline.

Legend doesn't lay out like an inline by default, actually...

> For the life of me I cannot understand what is so difficult to grasp about
> this concept.

Nothing, except it doesn't match reality.

> why the hell can't they make those elements behave like all the
> other elements we're used to being able to style?

Because you (collectively, web authors) are demanding that on the one hand the elements follow CSS and on the other hand the borders by default be painted in a way that is not possible with CSS.  The latter makes the former VERY hard to do, if possible at all.

> because doing it properly is almost certainly easier than doing it the way
> that it's been done.

If you drop the requirement that unstyled fieldsets display reasonably, then yes, this is all really easy.  I realize that's not a requirement your site has, but it's a requirement the web has as a whole.

I'm going to stop following this bug due to all the noise (in the form of email) from people who clearly haven't really read the bug, understood the issues, and looked at the code in question.  So whatever small chance there was of me taking the time to fix this someday is gone now...

Comment 20

[Jake Carlson]

> > why the hell can't they make those elements behave like all the
> > other elements we're used to being able to style?
> 
> Because you (collectively, web authors) are demanding that on the one hand the
> elements follow CSS and on the other hand the borders by default be painted in
> a way that is not possible with CSS.  The latter makes the former VERY hard to
> do, if possible at all.
> 
> > because doing it properly is almost certainly easier than doing it the way
> > that it's been done.
> 
> If you drop the requirement that unstyled fieldsets display reasonably, then
> yes, this is all really easy.  I realize that's not a requirement your site
> has, but it's a requirement the web has as a whole.

Right now, a fieldset has that nifty default styling with rounded corners, etc.  If you apply a border of any kind, the rounded corners disappear.

This seems to me to indicate that it is possible to allow developers to nullify the default styling of fieldsets & legends via CSS while still maintaining that default styling if untouched by CSS.

Why isn't it possible for other properties of legends and fieldsets to behave in this manner?

Even if this is not possible, I think that the best way forward would be to express fieldsets and legends using CSS only -- especially since the developer now has more control than ever before as to the styling of elements (in theory).

Comment 21

[Yves Van Goethem]

"To not allow the styling of this structural element
will cause accessibility-conscious developers such as myself to not use it
anymore, resulting in less accessible forms."

I fully agree with that, as many other developers I have to spent a lot of time to hack some workarounds, it would be really helpful to let us style this element as it could be done on other browsers.

Comment 22

[Ray Schamp]

Too bad this is hard to fix and seems like a touchy subject.  I have had to fall back on non-semantic markup to get around this problem, which saddened me because I didn't want to have to spend an IE-length of time worrying about a Firefox inconsistency.  I can tell it's a complicated issue since people are used to an unusual default style, but the legend tag ACTS as and LOOKS like a heading, so it should act like one when I strip it of its default style.  It's really not anything like an option or an area (and I agree that I should be able to style those too). I can't self-righteously support Firefox again until it actually has consistent rendering of all text-like elements, sorry.

It's pretty ironic that if you're reading this page without having logged in, you see an unstyled fieldset and legend saying you have to log in to comment.  I don't think that's even an appropriate use of a fieldset/legend (what field?) -- it's just exploiting the hard-to-style default appearance for a quick good looking layout.

Comment 23

[Jim Thoburn]

I absolutely love Firefox. It's such a breath of fresh air to be able to develop for a browser that does what you expect it to, and that renders pages so beautifully.

This is about the only exception I've ever found. I could say a lot here, but smarter people have already said it in the comments above. I just wanted to add one more plea...

I hope someone with a passion for accessible forms, and who has the skills needed to write a patch will find a way to resolve this.

Comment 24

[Ernst de Haan]

This bug still exists in Firefox 3.0 RC.... :-(

Comment 25

[Radu]

It isn't really easy nor elegant, but you CAN style the legend tag however you want using CSS and an additional span element within it

Comment 26

[Marc Bauer]

Such a solution is not possible in CMS systems like Drupal as themers don't have the hand on the legend's and absolutely unacceptable from technical view. This bugs must be fixed ASAP.

Comment 27

[Boris Zbarsky [:bzbarsky]]

I would like everyone who has commented on this bug to read https://bugzilla.mozilla.org/etiquette.html

In particular, section 1 item 1 and section 1 item 2...

Comment 28

[Peter Boughton]

> If you think you know how this should all work, please feel free to write a
> patch.  I'll be happy to review it and get it checked in, if it's correct.

Ok. I've just checked out cvs-mirror.mozilla.org/cvsroot/mozilla/browser from CVS.

How do I get started with developing it?

Also, can you also point me towards the files related to this bug?

Thanks.

Comment 29

[Boris Zbarsky [:bzbarsky]]

Peter, the relevant files are probably:

  layout/forms/nsLegendFrame.{h,cpp}: The current legend layout object
  layout/forms/nsFieldsetFrame.{h,cpp}: The fieldset layout object
  layout/base/nsCSSFrameConstructor.{h,cpp}: The class that handles
     constructing the layout object tree.  There is some special logic there
     for legends.
  layout/base/nsCSSRendering.{h,cpp}: The class that handles various
     painting operations, in case you need to change the way fieldset border
     painting around legends works.

Depending on how you want to approach this problem other things might be relevant as well, of course (e.g. if you decide to introduce new style properties).  Please feel free to ask questions in the mozilla.dev.tech.layout newsgroup (or the [e-mail] mailing list, which forwards to the newsgroup; if you want to subscribe to this list, see https://lists.mozilla.org/listinfo/dev-tech-layout).

As far as starting, see http://developer.mozilla.org/en/docs/Build_Documentation
and please feel free to mail me with any questions!

Comment 31

[fentex]

If someone does do some work on this (If I find the time I may make the attempt) may I suggest the follwing approach:

Currently fieldsets and their legends behave non-css standardly because pure css doesn't allow for the manner in which they are rendered (for typical HTML), which seems to be inline for the legend and block for the fieldset with the extra behaviour of legends erasing fieldset borders they overlap and fieldsets top borders being dropped half the legends height.

The problem starts when someone (like me and the reason I found my way here) tries to style the legend and find it won't move.

I think a simple fix would be to leave the current functionality in place, but if absolute, relative positioning or block display are applied to the legend have it (and the fieldset) abandon their special behaviour to become a standard block (fieldset) and inline (or specified block) legend that apply styles.

The worse that could happen, I think, is the fieldset border moving up and/or bleeding through the legend unexpectedly for designers. But because they're purposefully styling the legend these should be easy fixes.

I think this behaviour is approximately what I see in IE and Opera and ought be comprehensible to designers (you can style it when you try to style it) with minimal backwards breaking.

It might make sense to require a certain specificity to engage the new behaviour (I assumme the code makes it relatively easy to check css specificity) so that older pages or carelessly styled ones don't break current rendering because sloppy css accidentally specifies a fieldset legend.

Comment 32

[DChaffin]

WOW ... I just ran across this bug and its comments and am floored by the fact that this has been issue since 2004 and is still unresolved. For a presentation on web form design, I was trying to recreate the following form: 

http://www.flickr.com/photos/rosenfeldmedia/2366424765/sizes/o/in/set-72157604272550634/

That is how I came to this bug. What is incredible to me is that with some simple CSS, I can make this work perfectly in Chrome, IE7 and even IE6 - but not Firefox 3.0.9! What!?!? Normally, I prefer Firefox over any other browser for many reasons including its CSS support, but I just can't fathom how, for this element, it seems they're not even trying.

If anyone has any CSS tips for styling the fieldset, please let me know. Until then, I guess I'll have to use some extra, non-semantic HTML to work around this ridiculous issue.

Comment 33

[Timothy Nikkel (:tnikkel)]

Attachment: patch?

Do we need to do more than this?

Comment 34

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Have you checked that relative positioning works sensibly for legend inside fieldset?  (You're enabling that too, with this patch.)

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #33)
> Do we need to do more than this?

At the very least, some reftests. :-)

Comment 36

[Boris Zbarsky [:bzbarsky]]

That patch allows positioning or floating the legend but not changing its width or height....  That seems undesirable to me.  I'm not sure whether it's more undesirable than what we have now.

As a data point, position:relative on a legend makes the special legend handling go away in Opera.  It continues to get the special handling in webkit, with the border gap where the legend would have been except for the positioning style:

data:text/html,<fieldset><legend style="position: relative; top:100px">aaa</legend>bbb</fieldset>

I suspect that we get neither behavior with this patch; I'm not sure what we do get.

Comment 37

[Timothy Nikkel (:tnikkel)]

Sorry for the delay. Adding an attachment doesn't automatically add you to the CC list like most other bugzilla commits, so I just saw these comments now.

As for relative position I don't think my patch enables that. IsAbsolutelyPositioned checks for absolute or fixed positioning only. I checked in my build too, relative position is ignored. Am I missing something?

If I specifically allow relative positioning then my build does the same thing as Opera (except we handle dynamic changes to the position type properly, looks like Opera doesn't invalidate enough and leaves behind some of the old fieldset border, Chrome seems to have similar problems with the float property).

If you use smaller offset values you can also notice that Webkit makes the position relative to if the legend were in the fieldset border, and Opera makes the position relative to if the legend were inside the fieldset content area.

Just for context, we're still going to be different from both Opera and Webkit in this area due to bug 450418.

Why do we need the ! important's on width/height? I did a few simple tests without them and it worked the same as Webkit and Opera.

Comment 38

[Timothy Nikkel (:tnikkel)]

Attachment: above patch plus reftests

Above patch plus reftests. Also fixed the parentheses level on this franken-if condition. I had it right originally, but then changed it. Maybe I should simplify it.

Comment 39

[Boris Zbarsky [:bzbarsky]]

> I don't think my patch enables that.

David meant that now your legend can end up with a computed position of "relative".  He was asking you to check what happens with your patch if you do that.  Sounds like we ignore it; that should be ok for now, I think, but we might want a separate bug on it.

> Why do we need the ! important's on width/height?

Is the rendering correct for <legend style="display: block; width: auto"> without it?

Comment 40

[Boris Zbarsky [:bzbarsky]]

Timothy, see comment 1 for some things the reftests should be testing.

I'm still worried about letting people float/position this but not change its size.  I assume that's very much not what webkit and presto do?

What we really want here, in some ways, is to make legend shrink-wrap for auto width when it's in-flow and do whatever it would do based on its styling otherwise.  That's for width.  I can't even guess at the right height behavior; I haven't tested it extensively in other browsers...

Maybe we could always set isBlock false for legend frames in nsHTMLReflowState::InitConstraints?  Would that do the right thing?

Comment 41

[Timothy Nikkel (:tnikkel)]

I've done some testing of how IE8, Chrome, and Opera handle legends.

IE8 has something equivalent to white-space: nowrap that authors can't remove. Opera/Chrome don't have this at all. We have this, but authors can override.

IE8 treats float on legend as specifying which side to put the legend on, the legend stays in the border of the fieldset. (Chrome and Opera treat the legend as a div and put it inside the fieldset.)

Chrome uses the text-align property to put the legend on the left/right inside the border of the fieldset (as well as aligning the text inside the legend if it wraps). Opera aligns the text inside the legend if it wraps, but doesn't move the legend. Firefox does the same as Opera if the white-space is overridden to allow wrap. In IE8 you can't override the nowrap, so I can't tell if its doing anything (it doesn't move the legend).

IE8, Chrome, and Opera all shrink-wrap the legend for all positions.

All of the widths/heights results were the same, and didn't depend on if the legend was special, or what type of position it had.

IE8 will let you expand the width and height of a legend, but not shrink it.

Chrome will let you expand and shrink the width and height of a legend.

Opera will let you expand and shrink the width. It will let you expand the height, but not shrink it.

I used the patch posted in this bug, plus removed the ! important's in forms.css on legends and made legend frames always shrink wrap in nsHTMLReflowState::InitConstraints (since we only create legend frames when they are in-flow this does what we want) and tested the things described in comment 1 against Chrome and Opera (IE8 allows floating and positioning legends but the rendering looks completely broken). I tested regular legends, float left and right, absolute position, absolute position with the fieldset being the containing block, and fixed position. With my patch we do the same thing as Chrome with respect to widths/heights. For everything else it is the same as Chrome and Opera with one exception: absolutely positioned legends inside fieldsets that have padding due to bug 450418. But that applies to all elements inside of fieldsets, not just legends.

Comment 42

[Boris Zbarsky [:bzbarsky]]

> IE8 treats float on legend as specifying which side to put the legend on, the
> legend stays in the border of the fieldset. (Chrome and Opera treat the legend
> as a div and put it inside the fieldset.)

Which means the big question is which behavior here would break more sites...  <sigh>.

> IE8 will let you expand the width and height of a legend, but not shrink it.
> Chrome will let you expand and shrink the width and height of a legend.
> Opera will let you expand and shrink the width. It will let you expand the
> height, but not shrink it.

Again, a little scary.  Implementing the IE behavior would be a huge pain, I think.  I'd _like_ to be able to get away with the Chrome behavior, as long as it's not a compat issue.

Comment 43

[Timothy Nikkel (:tnikkel)]

Attachment: above patch, plus shrink-wrap and test for that, and drops ! importants

This matches what Chrome does, minus the "position: relative" case.

Comment 44

[Boris Zbarsky [:bzbarsky]]

What does it do in the position:relative case?  Just ignores the positioning?

If so, file a followup bug on that?  It should be easy enough to fix.

Comment 45

[Timothy Nikkel (:tnikkel)]

(In reply to comment #44)
> What does it do in the position:relative case?  Just ignores the positioning?

Yes, it ignores it.

> If so, file a followup bug on that?  It should be easy enough to fix.

I left it out because Opera and Chrome differ in what they do. Chrome positions the legend relative to its special legend position, Opera makes it a regular item inside the fieldset and positions it relative to that.

Comment 46

[Timothy Nikkel (:tnikkel)]

Attachment: above patch with fixed up tests

Comment 47

[Boris Zbarsky [:bzbarsky]]

> I left it out because Opera and Chrome differ in what they do.

In the new setup, either one should be fairly easy to do; that's why I said to file a followup bug to decide on the right behavior.  ;)

Comment 48

[Boris Zbarsky [:bzbarsky]]

Another option for the reflow state change is to force mFrameType to inline or some such for legend frames...

Comment 49

[Timothy Nikkel (:tnikkel)]

(In reply to comment #47)
> > I left it out because Opera and Chrome differ in what they do.
> 
> In the new setup, either one should be fairly easy to do; that's why I said to
> file a followup bug to decide on the right behavior.  ;)

Ok, I just wanted to make sure we were both on the same page. I will file a followup when this bug is settled.

Comment 50

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 390634 [details] [diff] [review]
above patch with fixed up tests

>+      // always shrink-wrap legend frames
>+      if (frame->GetType() == nsGkAtoms::legendFrame)
>+        isBlock = PR_FALSE;

What's this needed for?  Is it so legends behave reasonably if somebody sets both display:block and width:auto but doesn't do something to make them non-special?  If so, then maybe say that in a comment?

>+  position: static;
>+  float: none;
>+  width: -moz-fit-content;
>+  min-width: 0;
>+  max-width: none;
>+  height: auto;
>+  min-height: 0;
>+  max-height: none;

It seems like all of these except for 'width' could probably be removed, but it might be better to do that in a followup patch that's not right-before-a-branchpoint.


I think bz is probably a better reviewer here, though... he's been involved from the beginning.

Comment 51

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 390634 [details] [diff] [review]
above patch with fixed up tests

>+++ b/layout/generic/nsHTMLReflowState.cpp
>       PRBool isBlock =
>         NS_CSS_FRAME_TYPE_BLOCK == NS_FRAME_GET_TYPE(mFrameType);
>+      // always shrink-wrap legend frames
>+      if (frame->GetType() == nsGkAtoms::legendFrame)
>+        isBlock = PR_FALSE;

Probably better to use && than an extra if.

Comment 52

[Boris Zbarsky [:bzbarsky]]

Er, and actually I changed that to use a separate shrinkWrap boolean, since isBlock is used after that for the CalculateBlockSideMargins call.

Comment 53

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/mozilla-central/rev/6cb862f77f0f

Please do file that followup bug!

Comment 54

[Boris Zbarsky [:bzbarsky]]

And pushed http://hg.mozilla.org/mozilla-central/rev/c4be2972d076 to fix a test that was testing things that are no longer true.

Comment 55

[Timothy Nikkel (:tnikkel)]

Bug 507786 filed to allow 'position: relative' and get rid of most of the legend specific declarations in forms.css.