46560 - boxacid: radio-button incorrectly enabled

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect, P3)

Description

[u12623]

[Linux2.2.15-i686-smp, 2000072608]

The boxacid-test is rendered incorrectly. According to the HTML, the first
radio-button should be disabled while the second should be enabled. But the
reference rendering shows both disabled. Whichever is correct, mozilla
incorrectly renders <input type="radio" name="foo" value="off"> in the boxacid
test as enabled. We need to clarify how the boxacid test should be rendered
correctly nevertheless.



Reference-rendering: http://style.verso.com/boxacidtest/layout.gif
Actual test: http://style.verso.com/boxacidtest/vd/

Comment 1

[Hixie (not reading bugmail)]

The value="on" and value="off" attributes do NOT refer to the state of the 
radio button. They are merely indicative of the what value to return to the
server. The only potential bug here is that the radio buttons default to
'checked', presumably because we have code that prevents radio button sets
from being all unchecked at the same time.

Recommend moving to Future. See also bug 14445.

Comment 2

[u12623]

Thanks for correcting me, Ian. I confused the value="on" with the 'checked' 
attribute. As the specs [1,2] says, at any one time only one radio-button can 
be 'checked'. If no radio-button has the 'checked'-attribute, the first one 
should be checked by the user agent. So we have to revise the code that checks 
which radio-button will be checked. Mozilla already checks that there is always 
at least one radio-button checked. We need to change this so it checks that 
exactly one is checked.

I propose it works this way:

- If there is exactly one with a 'checked'-attribute, check this.
- If there isn't any radio-button with a 'checked'-attribute, check the first 
one on the form [undefined by w3, but defined by RFC - we implement w3 specs, 
not RFCs - or are we after both? I think we can make this one comply to both 
specs]
- If there are more than one with a 'checked'-attribute, then the first one 
with the attribute should be checked [undefined, only in html-quirks mode?]

About the compat keyword: Right now, moz gets it wrong. But it will probably 
provide a work-around (see above) so I'll keep the compat keyword.

This issue affects conformancy with HTML 2 and up, so I suggest not to move 
this bug to Future.

BTW: although the the acidbox-test passes the validator, it doesn't have any 
radio-buttons with the attribute 'checked' - Should it be changed to make 
one 'checked'? Because no checked radio-button isn't really valid and the 
acidbox-test claims to be valid.

1) http://www.w3.org/TR/html4/interact/forms.html#form-controls
2) http://sunsite.cnlab-switch.ch/ftp/doc/standard/rfc/18xx/1866 section 8.1.2.4

Comment 3

[Hixie (not reading bugmail)]

No, moz currently gets it _right_. The two radio buttons are in a different
namespace since their "name" attributes differ.

Comment 4

[u12623]

ack. Well then, the real problem is that the radio-buttons on the reference
rendering of the boxacid-test should both be turned on. I suggest to mark this
bug as INVALID, remove compat keyword (since bug is invalid), and ask
[e-mail] to correct the reference rendering.

[ I should've known better: Gecko is always right! :-> ]

Comment 5

[Hixie (not reading bugmail)]

Todd... There's a bug with your Box Acid Test's reference rendering...

Comment 6

[fahrner]

Form widget appearance/state is explicitly out-of-scope for this test.

Comment 7

[bsharma]

Updating QA contact.