Closed Bug 443550 Opened 17 years ago Closed 17 years ago

Legend won't wrap if text exceeds width of Fieldset or Form - even when display:block and explicit width is set

Categories

(Core :: Layout: Form Controls, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: bugs, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 Build Identifier: http://www.mozilla.com/en-US/firefox/ (Created date June 10) FFOX 3.0 Browsers obviously have very different methods of rendering form elements. One frustrating issue lies in legends. While some browsers wrap a longer legend, keeping it within the fieldset it is paired with, others do not. Since legends can not _always_ be kept as short as a form width may be, I struggled with a solution for this. I understand that a legend is an inline element and as such, is not meant to respect a width. However, the fact that it is paired with and contained by a fieldset, in my mind, should be a factor. FFOX 2 would force the fieldset to be as wide as the content in the legend - this horribly breaks layouts (view example page here: http://www.w3conversions.com/presos/AEA/2_form/form2b.htm - view in both FFOX2 and FFOX3). In IE (PC), though the legend doesn't wrap by nature, adding display:block and a width will give close to the desired result. However, in moz-based browsers, this solution doesn't work. One that does is to place a span within the legend (sadly non-semantic, but a solution nonetheless) and give the styling attributes (including display:block and the width) to the span. This gives you the desired effect in moz-based browsers. (I blogged about this back in November - you can read this for more information: http://www.communitymx.com/blog/index.cfm?newsid=882&blogger=15 And this URL shows the form with the fix in it. View the difference in FFOX2 and FFOX3 - http://www.w3conversions.com/presos/AEA/2_form/form2.htm) And until this month, all was well. But now with the release of Firefox 3, this solution no longer works. The span no longer respects the width even when its display is changed to block. However, now instead of pushing the fieldset wider, the legend simply hangs over the right side of it. Again, very problematic for layouts. If an elements display is changed, then it should render with those display rules - in this case, a block element should respect the width given (and I'd like to be able to set the legend to display:block and give it a width. I would not prefer to have to use the span trick.) I believe this issue needs to be given some priority treatment since breaking the only fix (I've found) to make an already problematic element work, but without fixing the issue really ties our hands as developers. These elements are really important from a form accessibility and usability stand point, but coders avoid them for reasons such as this. Please help the accessibility of the web by giving this bug some love (as in squashing it flat... ;)) Reproducible: Always Steps to Reproduce: 1. Create a form (give it a width) 2. Place a fieldset with legend within it (give the fieldset a width) 3. Place enough text in the legend that it will need to wrap to the next line Actual Results: It will push the legend wider than your specified width (in FFOX2) and will overflow out the right side of the fieldset (in FFOX3). Expected Results: The fieldset should contain the legend and thus, the text should wrap within it.
I think this is invalid. legend has, in the UA stylesheet: white-space:nowrap. http://mxr.mozilla.org/mozilla/source/layout/style/forms.css#52 adding to the author stylesheet: legend {white-space:normal} allows the long string in the legend to wrap, even without the span construction.
Component: General → Layout: Form Controls
Product: Firefox → Core
QA Contact: general → layout.form-controls
Yep. The current behavior is preserving the Fx2/IE behavior in the common case while actually making the whole thing more amenable to change by sites that care about changing it...
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Please see http://www.w3conversions.com/presos/AEA/2_form/form2c.htm ... I have added the white-space: normal to the legend rule. Yes, in FFOX3, it works. However, FFOX2 and IE (at least -- my Opera install is borked and I can't test it), the white-space: normal does nothing. I assume this is what you mean by "preserving the Fx2/IE behavior in the common case"... Which is, of course, not what most of us wanted (and the span fixed). So the span trick is still needed to make FFOX2 (and others) work. That said, adding white-space: normal to either the legend itself or the selector for the child span does make FFOX3 behave. So that much is good. http://www.w3conversions.com/presos/AEA/2_form/form2d.htm (added to the span) http://www.w3conversions.com/presos/AEA/2_form/form2e.htm (added to the legend with span preserved) (Thanks Philippe - and LONG time no talk. Good to see you. :) Stef.)
The common case is just text in the legend, with the author wanting default styling. In that case the text should not wrap. So the point is, you can make it wrap in Fx3 without changing the DOM (unlike Fx2). If you need Fx2 compat, you have to add the span, of course.
Yes, agree. We'll have to continue to use the span for now. :) Thanks for that. I do have one question though -- if you feel like walking me through the logic. A legend is inline. It is nested inside a fieldset which has a width. How can a span legally push open its parent element?
A legend isn't actually inline. More precisely, the default fieldset/legend combination rendering can't actually be described with CSS, so in fact they're replaced elements in Gecko.
I have just read the specs for 2 hours (maybe more - aye, my eyes!). I have been unsuccessful at finding a list of "replaced elements". I have found descriptions of a replaced element... I understand what they are... I have found partial lists of examples... I can see that form controls are replaced elements... however, I can find no reference where the legend is listed as a form control. In fact, in this reference: http://www.w3.org/TR/html401/interact/forms.html#edef-FIELDSET it is listed as inline (just as a label is). And the fieldset is listed as flow. None of the other form control elements have those designations. It does appear to say that it GROUPS the form controls but not that it is one. And in this reference, "A sample stylesheet for HTML 4.0" http://www.w3.org/TR/1998/WD-css2-19980128/sample.html the legend is listed with the caption, td and th, not the form controls, in the way it's defined by the various example properties (and one of the declarations includes white-space: normal). That said, I realize this is an old reference, but didn't find the newer one. I will be the first to admit that it makes my head spin to read through the specs for any length of time. But I have read through pages and pages... googled the w3.org site and still haven't come up with a good, exhaustive/explanatory reference/list. A simple list of replaced elements. Wouldn't that be cool? :) (Googling outside w3.org turned up other people looking for the same list I was though. Since 2002!) I found the lovely list of properties and how they can be applied -- you would think there would be a similar appendix for elements. That said, I realize that there are pages that discuss each element -- but never on those pages could I find legend referred to as a "replaced element" ... in fact, in HTML5 it's obvious it will not be. Hrm... don't know how you guys do this stuff. ;) In the end, I can see that if you're looking at the legend as a replaced element, then you must be looking at the text inside as its intrinsic width. But I would love to see a reference that defines the legend AS a replaced element. Dat's all. Happy Saturday. :)
There is no list in any spec. It's up to the user agent, basically.
Ah, ok. I guess that answers a lot about differences between user agents -- especially in the area of forms. Sure would be nice for us if the Standards/spec creators would be more specific in such areas. So I suppose arguing with you about all the reasons I don't think legend should be an inline replaced element won't change it, eh? Shucks. Thanks for hangin' in with the explanations... Ciao
I'm sure you breathed a sigh of relief after my last post, but I fear I must argue this point just a touch more. Work with me here. ;) If the specs call legend "inline" - http://www.w3.org/TR/html401/interact/forms.html#edef-FIELDSET - and I'll grant that you guys have gone with "inline replaced" (or simply "replaced" though to me, that would certainly seem to differ from the spec, but ok), then why are you not following the application rules for the property white-space which says it can only be applied to a block-level element? http://www.w3.org/TR/REC-CSS2/propidx.html It does not say "block-level and replaced" as it does with some other properties. It simply says block-level. And I don't think either of us would attempt to prove that legend is a block-level element. We could make an argument that it's either inline, inline replaced or replaced (dependent on the user agents interpretation of the specs). Correct? Could I request that this be reopened and looked at a bit more closely.
The inline/block thing in HTML has nothing to do with CSS box types. As far as whether legend should be replaced, that's happening because, as I said earlier, the default rendering of legend and fieldset CANNOT BE DONE for a non-replaced element (e.g. the way the border has to work). This ground is covered at length in other bugs. But even if it were non-replaced, the default behavior would still be exactly what it is right now, because that behavior is what websites depend on. Changing it would break them. If you want it to wrap, you have to opt-in by changing white-space on it.
Alright... just seems odd that ONLY FFOX3 reacts in this way. All other browsers either wrap the text or can be wrapped with the span (including FFOX2)... Maybe one day none of them will need the span... we can dream. :) Thanks for your input.
You need to log in before you can comment on or make changes to this bug.