For this application, the :disabled selector and disabled elements are a particularly hard case to handle.
Selector syntax
It actually depends on an attribute, unlike similar looking selectors that depend on a state triggered by a user interaction. I guess using [disabled] was too easy.
It's unclear whether it should be treated as a full selector, and only shown on actually disabled elements, or whether it should be treated similar to the hover state, and shown on each occurrence on the element even if not actually disabled. The choice is further made difficult by the following.
Disabled elements are fundamentally unclickable
If an element is disabled, the browser really pretends it's not there, and the click ends up on the first non-disabled parent. Hence it becomes un-inspectable through a direct click.
I expect this to be hard to address, because the inspection behavior is also like that in browser dev tools, and I imagine they would have fixed that if it was easy.
For this application, the
:disabledselector and disabled elements are a particularly hard case to handle.Selector syntax
It actually depends on an attribute, unlike similar looking selectors that depend on a state triggered by a user interaction. I guess using
[disabled]was too easy.It's unclear whether it should be treated as a full selector, and only shown on actually disabled elements, or whether it should be treated similar to the hover state, and shown on each occurrence on the element even if not actually disabled. The choice is further made difficult by the following.
Disabled elements are fundamentally unclickable
If an element is disabled, the browser really pretends it's not there, and the click ends up on the first non-disabled parent. Hence it becomes un-inspectable through a direct click.
I expect this to be hard to address, because the inspection behavior is also like that in browser dev tools, and I imagine they would have fixed that if it was easy.
Even
elementFromPointhas this behavior.