- From: <bugzilla@jessica.w3.org>
- Date: Fri, 24 Jun 2011 17:51:31 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12241
Estelle Weyl <estelle@weyl.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |estelle@weyl.org
--- Comment #7 from Estelle Weyl <estelle@weyl.org> 2011-06-24 17:51:30 UTC ---
Issue:
1. Explicitly state that form="" disassociates a form control from its ancestor
form
Rationale:
If form="" disassociates the form element from the form in which it is nested,
this should be explicitly stated in the spec (it is currently implicitly
stated).
There are times when disassociated a form element from it's parent form is
useful. However, the simplicity of form="" always making the input unassociated
is a concern. Would it make more sense to have form authors explicitly set the
form attribute to something other than null or the ancestor form's ID to ensure
that accidental inclusion of the attribute with no value, either thru WYSIWIG
text editors or erroneous JS (such as removing the attribute value but not the
actual attribute) not disassociate the form element.
For example, the John Thomas's 2011-03-07 dependent drop down example: the
dependent drop down is disassociated until activated. the js removes the value
of the form control's form attribute, but does not remove the attribute itself.
While the site author could have used disabled to not send the form control
data, this may not always be an option as the UI may allow for tabbing into or
otherwise altering the form control that is originally associated with an
outside form.
This unintended consequence is too serious of a consequence to not make site
authors explicitly aware of this intended behavior.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 24 June 2011 17:51:36 UTC