Closed
Bug 653870
Opened 14 years ago
Closed 9 years ago
display:inline on a <legend> should pull it out of the <fieldset> border
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
RESOLVED
INVALID
People
(Reporter: zwol, Unassigned)
Details
Attachments
(2 files)
If I set display:inline on a <legend>, that should pull it back out of the associated <fieldset>'s box border. (Ideally, there would be a special display: value that has the effect of "put this into the containing element's box border" and setting display: to *anything else* should cancel that. I'm aware that I *can* pull a <legend> out of the box border with float:, but that still doesn't make its text baseline-aligned with other text in the same form.)
Rationale: I might want to use <legend> and <fieldset> strictly for their semantic consequences, such as their effect on screen readers, see http://www.paciellogroup.com/blog/2007/11/fieldsets-legends-and-screen-readers/ -- and not their layout effects. In the test case I've attached, this would be one of several multiple-choice questions in a form, so inline layout would be much more appropriate -- note also that the <fieldset> border has been disabled.
IE 8 and 9 do what I (my informant) wants. Webkit is the same as Firefox.
Reporter | ||
Updated•14 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Reporter | ||
Comment 1•14 years ago
|
||
Reporter | ||
Comment 2•14 years ago
|
||
Closely related: bug 292736, bug 507786. I think not an exact duplicate, though.
Reporter | ||
Comment 3•14 years ago
|
||
Further exposition on why this shouldn't be either a dupe or a dependency of bug 292736: that bug is substantially more ambitious than this one. It would be *nice* to be able to duplicate the effect of <legend> inside <fieldset> with nothing but CSS, but being able to *turn the magic off* is all I need for this bug, and I'm betting that's a lot easier to implement. Let's not wait a straightforward, desirable, well-scoped improvement on a much more nebulous and ambitious one.
Comment 4•14 years ago
|
||
I'm not sure how web-compatible this is. I seem to recall I kept the current behavior when we were making <legend> more stylable because there were pages out there that were using "display: inline" on legends and expecting that to keep them as legends....
Which IE mode(s) was the testing in comment 0 done in? Does the behavior depend on mode?
Comment 5•14 years ago
|
||
Amusingly enough, btw, I did just see http://stackoverflow.com/questions/5818960/legend-not-displaying-inline go by.
Reporter | ||
Comment 6•14 years ago
|
||
(In reply to comment #4)
> I'm not sure how web-compatible this is. I seem to recall I kept the current
> behavior when we were making <legend> more stylable because there were pages
> out there that were using "display: inline" on legends and expecting that to
> keep them as legends....
It would be okay by me if there was something else you had to do as well as setting display:inline, as long as it was a documented (and hopefully at least submitted for standardization) something.
> Which IE mode(s) was the testing in comment 0 done in? Does the behavior
> depend on mode?
With IE9, in its default mode and its IE8 compatibility mode, display:inline pulls the legend out of the border.
IE9 in IE7 compatibility mode, however, does not.
My informant didn't try any other modes or any actual installs of IE8 or 7, and I'm on a Mac right now :)
Comment 7•14 years ago
|
||
Is IE7 compat mode the "quirks" mode in IE9? Or is it one of the standards modes?
Reporter | ||
Comment 8•14 years ago
|
||
I think quirks mode in IE9 is orthogonal to the IE7 and 8 backward compatibility modes.
You can get immediately IE5.5 - IE9 screenshots oft testcases here:
http://meineipadresse.de/netrenderer/index.php
(replace https:// with http://)
> Is IE7 compat mode the "quirks" mode in IE9?
it's one of the standards modes
Comment 10•14 years ago
|
||
And "inline" seems to be legend's default in IE quirksmode. "block" expands width to 100%.
Comment 11•11 years ago
|
||
This still seems to be an issue in FF. Ran into this issue here:
https://drupal.org/node/2236789
I'm a bit surprised that this isn't an issue that has occurred more often.
Comment 12•10 years ago
|
||
(In reply to Mike Gifford from comment #11)
> This still seems to be an issue in FF. Ran into this issue here:
> https://drupal.org/node/2236789
>
> I'm a bit surprised that this isn't an issue that has occurred more often.
http://jsfiddle.net/yc70ptdq/1/ Firefox now seems to display it inline. If you add a surrounding <fieldset> element, however, it snaps back to the old display.
Comment 13•9 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #4)
> I'm not sure how web-compatible this is.
Note that I think Blink has made this change for version 50 in https://bugs.chromium.org/p/chromium/issues/detail?id=481983 so we can see if they revert due to compatibility issues.
Comment 14•9 years ago
|
||
That's hilarious. They made the change ostensibly to match us, but implemented a totally different behavior from ours.... And in the process started clearly violating the HTML spec.
Comment 15•9 years ago
|
||
Oh, and given that we're following the spec here, marking invalid. If people want the spec to change, the right approach is open discussion on the spec, not guerilla behavior changes by browsers...
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•