HTML4 labels should use edit (I-BEAM) cursor on mouseover

VERIFIED WONTFIX

Status

()

Core
Layout
P1
normal
VERIFIED WONTFIX
18 years ago
17 years ago

People

(Reporter: Blake Ross, Assigned: Hixie (not reading bugmail))

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [have fix])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Build ID: 2000082208

HTML4 labels are currently using the default (probably arrow) cursor when you 
mouseover them.  This doesn't make sense, since they're just normal text (and 
you can select them as you can other plain text).  They should be using the 
edit (I-BEAM) cursor. 

Will attach a testcase...
(Reporter)

Comment 1

18 years ago
Created attachment 13319 [details]
testcase
(Reporter)

Comment 2

18 years ago
no idea what component this is (but I meant to place it in html element)
Assignee: rods → clayton
Component: HTML Form Controls → HTML Element
QA Contact: ckritzer → petersen
(Reporter)

Comment 3

18 years ago
argh. sorry for spam. fixing summary.
Summary: HTML4 labels should use default cursor (arrow) on mouseover → HTML4 labels should use edit (I-BEAM) cursor on mouseover

Comment 4

18 years ago
For what it is worth IE uses the default cursor also (not an ibeam)
Target Milestone: --- → Future

Comment 5

18 years ago
taking bug
Assignee: clayton → rods

Updated

18 years ago
Status: NEW → ASSIGNED

Updated

18 years ago
Keywords: testcase
(Reporter)

Comment 6

18 years ago
Yeah, I noticed that.  Weird -- Ian said that's not spec'd or anything, and I 
don't see why it should be that way (to the user, the text is the same as all 
other text).

Then again, if the label is for a checkbox or radiobutton, it's *not* like all 
other text (since it's really part of the button).  So maybe it should stay the 
arrow cursor...(or maybe only if the label is for a checkbox/radiobutton).  Oh 
well...future it is.
(Assignee)

Comment 7

18 years ago
reinstating CC line.

Taking bug. I have fixed this in my reworked ua.css.
Assignee: rods → py8ieh=bugzilla
Status: ASSIGNED → NEW
Keywords: nsbeta3
OS: Windows 98 → All
Hardware: PC → All
Whiteboard: [have fix]
Target Milestone: Future → M18
(Reporter)

Comment 8

18 years ago
I'm starting to rethink this, though.  After all, clicking on a label that is 
for a checkbox or radio button will check the checkbox or radio button.  So in 
that sense it's part of the box/button.  And checkboxes/radio buttons have the 
arrow cursor.  So...(I assume we can't only use the cursor in cases where the 
label doesn't have the for attribute specified?)

Matt, what do you think?  The labels can both be selected, and act as buttons 
of a sort.  So which cursor?

Comment 9

18 years ago
I think the <label> should use the arrow cursor, since clicking it change the 
button (as blake says). (But does it only do this if the <input> is inside the <
label>? What if they are matched by ID?)
(Reporter)

Comment 10

18 years ago
I believe you can bind a label to an input widget via the 'for' attribute (e.g. 
<label for=radioname>hello</label><input type=radio name=radioname></label>
(Assignee)

Comment 11

18 years ago
So, is this INVALID or should I fix it? Please make your mind up sometime this
week... ;-)
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Priority: P3 → P1

Comment 12

18 years ago
I think this is invalid. Comparison: when you mouse over selected text in an 
editor which supports D&D, you can either drag the text (which would suggest the 
normal cursor) or position the caret (which would suggest the I-beam cursor). The 
normal cursor `wins', and is used instead of the I-beam.

The same applies here. The most common action for mousing down inside the LABEL 
will be to activate the form element, not to select text; so the normal cursor 
should be used. Using the normal cursor here also hints to the user that for this 
form control, they do not have to click exactly on the checkbox or radio button 
itself -- like they have had to do with checkboxes or radio buttons on the Web up 
to now.
(Reporter)

Comment 13

18 years ago
Yeah, that seems to be the general consensus.  Not invalid, though. Marking 
WONTFIX.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 14

18 years ago
massive update for QA contact.
QA Contact: petersen → lorca

Comment 15

18 years ago
VERIFIED.
Status: RESOLVED → VERIFIED
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.
Component: HTML Element → Layout
You need to log in before you can comment on or make changes to this bug.