47149 - [LBL]label element is treated as inline-block

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Hixie (not reading bugmail)]

It appears that we are treating the <label> element as an inline-block of sorts.
This predates October 1998 according to the CVS logs, so it's no regression...

This causes the rather amusing problems shown in the attached test case.

TO REPRODUCE:
   Open the testcase.

TESTED ON:
   Windows 2000 commercial bits 6.0.17.2000072920.

This is probably due to two things. One, the 'display:block' line in html.css;
originally added to ua.css by Troy in January 1998 (rev 3.81 of ua.css). Two, 
the "LabelHack" function in 
   http://lxr.mozilla.org/mozilla/source/layout/html/forms/src/nsLabelFrame.cpp
...which starts off:

  // XXX a hack until the reflow state does this correctly 
  // XXX when it gets fixed, leave in the printf statements or add an assertion 
  static
  void LabelHack(nsHTMLReflowState& aReflowState, char* aMessage)

I'd suggest it may (if I'm right) be time to "fix" that function...

BTW, there is another bug with radio buttons visible in that test case, namely
the strange vertical alignment in the span. That will be filed separately.

Nominating for beta3. This is a CSS1 and HTML4 compliance issue that can 
actually be seen in the CSS ImportTest, one of the testcases quoted by the Web
Standards Project.

Comment 1

[Hixie (not reading bugmail)]

Attachment: Testcase showing problem and reference rendering

Comment 2

[Suresh Duddi (gone)]

Kevin ?

Comment 3

[rods (gone)]

reassigning to self

Comment 4

[rods (gone)]

Marking as future for now, this is lower priority. I have looked at the 
LabelHack method and I am still not quite sure why Troy put it in. It needs 
another look. 

marking as nsbeta3- for now

Comment 5

[Hixie (not reading bugmail)]

Our creative handling of <label> elements is probably preventing them from
being drag&dropped, too (bug 49906).

Comment 6

[Hixie (not reading bugmail)]

*** Bug 53909 has been marked as a duplicate of this bug. ***

Comment 7

[Hixie (not reading bugmail)]

*** Bug 53909 has been marked as a duplicate of this bug. ***

Comment 8

[rods (gone)]

Ok, I give up. What exactly is wrong with the rendering of the testcase? Please 
describe what I am looking for.

Comment 9

[Hixie (not reading bugmail)]

Rod: Sections 1 and 2 of the testcase: 
   http://bugzilla.mozilla.org/showattachment.cgi?attach_id=12211
...should look identical (the second section is the right rendering).

Currently they look rather different.

Comment 10

[James Green]

Nomination for 0.9. Still occurs in tip build on linux from a couple days ago.

Comment 11

[rods (gone)]

Ok, so the point here is that a label should act like a span? Or I guess what 
Troy was trying to fake was an inline-block.

Marc, what is going on with inline-blocks these days? I know it was something 
somebody was always going to get to.

Comment 12

[Kevin McCluskey (gone)]

Setting milestone to future

Comment 13

[Jesse Ruderman]

See also bug 76117, checkbox label doesn't unwrap when resizing browser window.

Comment 14

[Tim Powell]

See also bug 77141, table's colspan is ignored because of label.

Comment 15

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

*** Bug 85306 has been marked as a duplicate of this bug. ***

Comment 16

[Brian Duff]

I logged bug 85306, which has been marked as a duplicate of this bug. In light
of the fact that this is not just an academic standards complience issue, but
results in a real problem with the layout of all HTML forms which support
accessibility, is there a target milestone for this bug? "Target Milestone:
Future" doesn't fill me with confidence that it's ever going to be fixed.

I don't want to bitch too much (Mozilla generally rocks), but the internal
Oracle javatools bug logging application looks like a pile of crap because of
this bug, yet it has to use <label> tags in order to comply with our
accessibility policies. I usually do a good job of convincing people in my group
at Oracle to use Mozilla rather than IE, but I can't in all good faith recommend
Mozilla while it still has bugs like this.

If bugzilla was properly accessible and used <label> as it was intended, this
bug would get fixed pretty quickly.

Comment 17

[basic]

there is no more label{display:block;} in html.css or even quirk.css

Comment 18

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

*** Bug 89432 has been marked as a duplicate of this bug. ***

Comment 19

[Tim Powell]

To echo Brian Duff, this bug also makes our web-based product look broken, but we
can't remove the label tags because of government accessibility requirements.
Please! This is a CSS1 compliance issue with high priority. Can we get a
reasonably soon target milestone for this?

Comment 20

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

Attachment: patch

Comment 21

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

The basic idea of the patch is that label doesn't need to be all that special. 
So it removes a lot of code that made label different.  All it leaves is the
hacked GetFrameForPoint that is needed to forward clicks to the controls and the
accesskey registration/unregistration.

Comment 22

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

taking

Comment 23

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

This patch makes label inline-only (i.e., 'display: block' fails), which isn't
great, but it's better than what we have now.  The real long-term solution would
be to move this form control stuff into content so that we don't need a special
frame class for label.  (And moving form control content model stuff into the
content model would fix a lot of bugs in general.)

Comment 24

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

Attachment: testcase showing clicking/accesskey still work

Comment 25

[rods (gone)]

Wow, a lot of code gone, that isn't a bad thing. I applied the patch and it 
looks good r=rods (thanks for taking the bug and fixing it)

Comment 26

[Marc Attinasi]

sr=attinasi

Comment 27

[Brian Duff]

Retested the test cases for bug 85306 with the patch. The layout of labels is
still completely broken. Please advise whether  85306 was closed as a duplicate
in error and should be reopened.

Comment 28

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

Bug 85306 sure looks fixed to me.  Are you sure you applied the patch correctly
and rebuilt correctly?

Comment 29

[Brian Duff]

Terribly sorry, I haven't been building my own mozilla for long. Did a rebuild 
from the top, and the patch seems to have done the trick. Thanks David!

Comment 30

[Asa Dotzler [:asa]]

a=asa on behalf of drivers

Comment 31

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

Fix checked in 2001-08-24 06:58 PDT.

Filed bug 96813 on additional problems.

Comment 32

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

Reopening, since I forgot to check in the forms.css half of the change!

Comment 33

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

forms.css change checked in too, 2001-08-27 13:56 PDT.

Comment 34

[Tim Powell]

*** Bug 77141 has been marked as a duplicate of this bug. ***

Comment 35

[Amarendra Hanumanula]

 The two sections look identical now... The patch checked in did fix the 
problem..
Tested with Platform : win2K
build ID : 2001-09-21
and 
Platform : Linux 7.1
Build ID : 2001-09-24

Comment 36

[Boris Zbarsky [:bzbarsky]]

jkeiser, see dbaron's comments from 2001-08-22 17:53

Just something to keep in mind as you move form controls into content....