Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[mediaqueries-4] More explicit clarification for when any-* 'none' evaluates to true #842

Merged

Conversation

patrickhlauke
Copy link
Member

Adds more explicit clarification about the possibly non-intuitive way in
which any-pointer:none/any-hover:none work.

Splits out the initial mention (that "ALL pointing devices need to
match") into its own line, and provides two sets of notes/examples that
clarify scenarios where this may not be completely obvious.

Additionally, this explicitly highlights the situation that currently
cannot be detected: having more than one pointing device where at least
one is non-hover-capable (as touched on in
#737 (comment) )

Adds more explicit clarification about the possibly non-intuitive way in
which `any-pointer:none`/`any-hover:none` work.

Splits out the initial mention (that "ALL pointing devices need to
match") into its own line, and provides two sets of notes/examples that
clarify scenarios where this may not be completely obvious.

Additionally, this explicitly highlights the situation that currently
cannot be detected: having more than one pointing device where at least
one is non-hover-capable (as touched on in
w3c#737 (comment) )
@darktears
Copy link

darktears commented Nov 9, 2017

I would like to mention for posterity that this change had a potential compat impact on Chrome.

Historically any-hover:none would match in the case of a laptop with touchscreen and keyboard (because the touch screen doesn't have hover capabilities). We read literally the "union of capabilities" and maybe the spec wasn't very detailed at the time of implementation. That said thanks for the change and the clarification.

Interaction MQ are truly dynamic in Chrome since recently : we react to the best we can to input capabilities changes from the OS. Think the case of convertible/detachable laptops where the touchpad is gone/deactivated. With that said just to clarify, I'm assuming that a tablet where a mouse/touchpad is added (through USB/Proprietary connectors like Asus Transformers or Bluetooth) should behave like a touchscreen laptop with touchpad/mouse? Aka any-hover:none should be false when some external input is connected and true when only the touchscreen is available to the user?

I'm aligning the implementation with the spec as we speak.

@patrickhlauke
Copy link
Member Author

@darktears

Historically any-hover:none would match in the case of a laptop with touchscreen and keyboard (because the touch screen doesn't have hover capabilities). We read literally the "union of capabilities" and maybe the spec wasn't very detailed at the time of implementation. That said thanks for the change and the clarification.

Do you mean you ignored the trackpad (assuming the laptop scenario had one)? Or do you mean that both any-hover:none (for the touchscreen) and any-hover:hover (for the trackpad) evaluated to true? From discussion in #737, I believe the latter was not the intention of the spec at the time - hence my clarification.

I'm assuming that a tablet where a mouse/touchpad is added (through USB/Proprietary connectors like Asus Transformers or Bluetooth) should behave like a touchscreen laptop with touchpad/mouse? Aka any-hover:none should be false when some external input is connected and true when only the touchscreen is available to the user?

correct. any-hover:none should only evaluate to true if there are NO inputs at all that are hover-capable. so, for instance, a pure touchscreen device like a phone (but if you then pair a bluetooth mouse with the phone and it results in a hover-capable mouse pointer, like on android/windows 10 on mobile, then any-hover:none should be false due to the mouse being detected).

@darktears
Copy link

darktears commented Nov 15, 2017

Do you mean you ignored the trackpad (assuming the laptop scenario had one)? Or do you mean that both any-hover:none (for the touchscreen) and any-hover:hover (for the trackpad) evaluated to true? From discussion in #737, I believe the latter was not the intention of the spec at the time - hence my clarification.

I meant in the laptop with touchscreen and trackpad/mouse any-hover:none (for the touchscreen) and any-hover:hover (for the trackpad) matched to true. Therefore the clarification of this PR slightly change the behavior because in that particular case any-hover:none will not evaluate to true anymore.

correct. any-hover:none should only evaluate to true if there are NO inputs at all that are hover-capable. so, for instance, a pure touchscreen device like a phone (but if you then pair a bluetooth mouse with the phone and it results in a hover-capable mouse pointer, like on android/windows 10 on mobile, then any-hover:none should be false due to the mouse being detected).

Ok then we need to adjust our Android implementation as well.

@patrickhlauke
Copy link
Member Author

@darktears thanks for clarifying. yeah i believe the confusion (even for me at the time) comes from the word "union" in the spec, and how it treats the "none" in this case.

@patrickhlauke patrickhlauke deleted the mq4-clarify-any-pointer-any-hover-none branch May 30, 2020 11:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants