Closed
Bug 362045
Opened 18 years ago
Closed 18 years ago
Weird interaction between padding and form labels.
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
RESOLVED
INVALID
People
(Reporter: nick, Unassigned)
References
Details
(Keywords: regression)
Attachments
(1 file)
333 bytes,
text/html
|
Details |
Adding padding to a label makes clicking them to give focus to the wrong component. It's as if the calculation of which thing has ben hit by the click is different than the actual layout algorithm. Perhaps the wrong thing is layout, as I see no padding in the result. I'm using Firefox 2.
Reporter | ||
Comment 1•18 years ago
|
||
Comment 2•18 years ago
|
||
I see only a I-beam cursor when I click under C if this is what you mean.
Which is a regression between 1.9a1_2006012517 and 1.9a1_2006012609.
Updated•18 years ago
|
Comment 3•18 years ago
|
||
When I click 'A' the cursor appears in text area B, and when I click 'B' the cursor appears in text area C. Is this what you mean Nicolás?
Comment 4•18 years ago
|
||
When I click in the middle of every input field, there is no problem.
Only when I try to focus the first half cm of fields A and B. My "remove elements" bookmarklet shows that the beginning of field B is covered by the label of C and the label of B covers the first half cm of field A.
Comment 5•18 years ago
|
||
Probably
Reporter | ||
Comment 7•18 years ago
|
||
The problem I see is that when you click on the labels, the wrong controls gets the focus. And the "offset" can be modified by adjusting the padding.
Comment 8•18 years ago
|
||
So... the thing is that the padding of the "B" label overlaps the A label. You can see this if you give the three labels borders of three different colors or given them a background color. Since the B label is painted after the A label, clicking on the overlap triggers the B label.
So either we shouldn't be considering the padding area when doing hit testing, or we had a bug before we fixed bug 317375. I suspect the former (which would make this bug invalid).
Note also bug 102695.
Blocks: 317375
Flags: blocking1.9?
Did you mean "the latter" when you said "the former"?
This bug is invalid either way anyway, right? Either we need to make padding transparent to events, which is a different bug, or we should do nothing.
Comment 10•18 years ago
|
||
Er, I meant "the latter".
And if you agree, then it is so. ;)
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 11•18 years ago
|
||
Hi, I'm the reporter =). Perhaps I'm missing something... but why is there no padding there? Isn't that a bug?
Comment 12•18 years ago
|
||
There is padding. It's just that vertical padding and borders don't affect line heights. See the CSS2.1 specification.
Updated•18 years ago
|
Flags: blocking1.9?
You need to log in
before you can comment on or make changes to this bug.
Description
•