| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
This check is in place in most other places, mostly because we have run into widespread issues under similar circumstances and we like to avoid those, but it was forgotten here. There also were no tests covering this, so it was never caught. This adds tests that ensure that the option in the results list will be generated with the correct "disabled" state based on whether or not it, or a parent element, is marked as disabled. This should have been easy: just check `element.disabled` Unfortunately the `disabled` property is not inherited within the option chain, so if an `<optgroup>` is disabled, the `<option>` elements or other `<optgroup>` elements held within it do not have their `disabled` property set to `true`. As a result, we needed to use the `matches` method to check if the `:disabled` state is present for the element. The `matches` method is part of the official standard, but it was not implemented under that name for a while and as a result Internet Explorer only supports it under the prefixed `msMatchesSelector` method and older versions of Webkit have it implemented as `webkitMatchesSelector`. But once we use this method, it appears to consistently return the expected results. This `matches` method and prefixed predecessors are not supported in IE 8, but they are supported in IE 9 and any browsers newer than that. Instead of buulding a very hacky solution using `querySelectorAll` that was brittle, I have chosen to act like everyone else and pretend IE 8 no longer exists. Fixes #3347 Closes #4818
This check is in place in most other places, mostly because we have run into widespread issues under similar circumstances and we like to avoid those, but it was forgotten here. There also were no tests covering this, so it was never caught. This adds tests that ensure that the option in the results list will be generated with the correct "disabled" state based on whether or not it, or a parent element, is marked as disabled. This should have been easy: just check `element.disabled` Unfortunately the `disabled` property is not inherited within the option chain, so if an `<optgroup>` is disabled, the `<option>` elements or other `<optgroup>` elements held within it do not have their `disabled` property set to `true`. As a result, we needed to use the `matches` method to check if the `:disabled` state is present for the element. The `matches` method is part of the official standard, but it was not implemented under that name for a while and as a result Internet Explorer only supports it under the prefixed `msMatchesSelector` method and older versions of Webkit have it implemented as `webkitMatchesSelector`. But once we use this method, it appears to consistently return the expected results. This `matches` method and prefixed predecessors are not supported in IE 8, but they are supported in IE 9 and any browsers newer than that. Instead of buulding a very hacky solution using `querySelectorAll` that was brittle, I have chosen to act like everyone else and pretend IE 8 no longer exists. Fixes select2#3347 Closes select2#4818
| Back | FazBrowse Home | New Git URL |
This check is in place in most other places, mostly because we have
run into widespread issues under similar circumstances and we like to
avoid those, but it was forgotten here. There also were no tests
covering this, so it was never caught.
This adds tests that ensure that the option in the results list will
be generated with the correct "disabled" state based on whether or
not it, or a parent element, is marked as disabled.
This should have been easy: just check element.disabled
Unfortunately the disabled property is not inherited within the
option chain, so if an <optgroup> is disabled, the <option>
elements or other <optgroup> elements held within it do not have
their disabled property set to true. As a result, we needed to
use the matches method to check if the :disabled state is
present for the element. The matches method is part of the official
standard, but it was not implemented under that name for a while and
as a result Internet Explorer only supports it under the prefixed
msMatchesSelector method and older versions of Webkit have it
implemented as webkitMatchesSelector. But once we use this method,
it appears to consistently return the expected results.
This matches method and prefixed predecessors are not supported in
IE 8, but they are supported in IE 9 and any browsers newer than
that. Instead of buulding a very hacky solution using
querySelectorAll that was brittle, I have chosen to act like
everyone else and pretend IE 8 no longer exists.
Fixes #3347
Closes #4818
This pull request includes a
The following changes were made