Add methods for finding labels and forms for controls

[arschmitz]

This adds 2 new $.fn methods to core, and a new prop to $.ui.escapeId.

$.fn.labels which mimics the native control.labels ( and uses it where possible ). This method unlike the native property also works on detached DOM nodes, and in browsers not supporting control.labels.

$.fn.form which fixes the native control.form in IE8 where setting the form attribute breaks the form property by changing it to a string.

$.ui.escapeId is a regex for escaping id and similar to be able to use them as jQuery selectors. Its needed anytime you are building a selector from the id or some other attribute of an element because there are characters valid in the HTML that need to be escaped when used as a selector.

This also updates selectmenu to use both $.fn.labels and $.ui.escapeId and it updates tabs to use $.ui.escapeId. $.fn.form is needed both by checkboxradio in the button rewrite but also by the from reset extension @scottgonzalez is working on. Checkboxradio will also use $.ui.escapeId. jquery-mobile will also use all three of these.

Note: This does add 3 new exceptions to htmllint:bad for the labels tests. These are needed to make sure we match that native implementation. While the markup may not be valid it is supported by every browser, so it is required otherwise we could get label / input mismatches which would break visual state and underlying state consistency for inputs and labels in things like checkboxradio. Specifically this can happen with inputs wrapped in multiple labels, and inputs which are wrapped in a label which is associated with an input besides the one it contains based on its for attribute.

[scottgonzalez]

While the markup may not be valid it is supported by every browser

It doesn't matter what happens natively if it's invalid markup. We never support invalid markup.

[scottgonzalez]

Why is this duplicated?

[arschmitz]

mistake

[scottgonzalez]

Since removing support for nested labels is likely to change a lot, I'll wait before reviewing this.

[arschmitz]

It only actually removes the filter here https://github.com/jquery/jquery-ui/pull/1546/files#diff-9642379d08d860be4c2831b0ff5b9a85R168 which is why i think making sure we have the proper label to ensure the DOM matches the state of the widget is more important then saying we don't support invalid markup.

[scottgonzalez]

It doesn't matter how small the code is for the support. Invalid markup is never supported and we absolutely should not test against it.

[scottgonzalez]

This is no longer relevant.

[arschmitz]

All updated

[scottgonzalez]

Is this a typo?

[arschmitz]

if you mean that these are not in the test fixture, No. Though i did mean to add a comment to explain why.
If you place these in the test fixture they get reset / replaced between each async test which is not what i want. because then any saved references are to a detached fragment, not attached DOM which i specifically want to test.

[arschmitz]

@scottgonzalez updated

[scottgonzalez]

Much better :-) Just need to start with a capital letter here.

[scottgonzalez]

Just a few minor things. You can land this after making those updates.