In particular, per current spec, since elements are never associated to empty IDs, this can never match any form elements, but the existence of the attribute will prevent looking up the parent chain.  Is that the desired behavior?

Let me throw this out there. I find unassociated form elements on occasion very useful. For example, if I want form elements that trigger javascript behavior but that I don't wanted submitted anywhere. To abstract this a little, the issue isn't that I don't want unassociated form elements, it's that I don't want the form elements associated with anything on the server as the role of these form elements is purely a matter of browser interaction, however, when you're dealing with form elements that are never meant to interact with a server, does the form tag still have relevance?

Now that doesn't answer the question, because you could always just throw input elements outside the form tags. But on the other hand that can lead to serious issues with CSS + here's a scenario:
You have a select with the name "choice":
cars
a computer
a rocking chair

when someone selects "cars" it triggers a dependent drop down, and now you want the value of the dependent dropdown to be associated with "choice" for that form. However if someone selects "a computer" or "a rocking chair", the original drop down should still be associated. In this situation being able to turn on and off the association of a form element would be very useful, and thus being able to do 
selectTag.form="" would be nice

Right.  I understand the use cases for having unassociated elements, though you can always do that by pointing them to a nonexistent ID, right?

This came up in the context of a web compat issue in Gecko 2.0.  Some somewhat-widely-distributed intranet app is using markup like this:

  <input type="hidden" name="x" value="y"</form>

(Note missing '>' on <input>).

In IE, this parses <input> as having an attribute named "form" with an empty value, but IE doesn't support @form, so this has no effect.

In Gecko's old parser, an '>' is implied when we see the '<' for </form>, so there is no problem.

But when using IE-compatible tokenization and supporting @form, the <input> in question is not submitted (since it's no longer form-associated), breaking the app.

For now we're treating this as an evangelism issue, but if this behavior is just an accident, we'd really prefer to fix this on our side rather than trying to evangelize an unknown set of companies...

Right now it's mostly an accident, since form="" (empty) is a conformance violation. I'm open to either making it valid as a way to deassociate a form control, or making form="" (empty) be ignored.

bz: How did the evang attempt go?

https://bugzilla.mozilla.org/show_bug.cgi?id=638842 is the Gecko bug where this came up.  Last we heard, on 2011-03-07, a ticket was opened with the owner of the relevant non-public site... then nothing.  Pretty normal, for evang.

Apparently still no response from the vendor.

I guess we need to make a call on this. We have three options:

1. Leave it as is. One site break is known to break, but it's a conformance error so careful authors will catch it. In this particular case it's also an obvious typo in the source that is triggering this problem, so not breaking something that had any good reason to be done in the past.

2. Make it a valid way to disassociate a form control. This will mean no conformance error in some cases that break, but will add a new feature. Not clear how useful the feature is, though.

3. Make it be ignored. This means we can no longer add the feature if it turns out to be useful, but it fixes the one known broken site.

I'm leaning towards 1 right now.

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.

We've had a second report of the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=658254

I'm still not convinced that changes what we want to do here, but wanted to note it.

We have now had a third report of a similar issue, on tsa.gov: https://bugzilla.mozilla.org/show_bug.cgi?id=671298

I have also discovered that apparently WebKit didn't actually implement the spec here (see <https://bugs.webkit.org/show_bug.cgi?id=64509>).  So authors testing in WebKit-based browsers only would be likely to make this sort of mistake...

mass-move component to LC1

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Since WebKit changed also here, we're all gonna be in the same boat. So I'm WONTFIXing this for now, despite the growing number of reports. Please let me know if the problems get too big for us to keep ignoring them and result in browsers reverting this.