Enum TooltipFocusTrigger

pub enum TooltipFocusTrigger {
    Always,
    IfHoverNone,
    IfAnyHoverNone,
    IfAnyPointerNoneOrCoarse,
    Never,
}

Trigger options for TooltipProps::trigger_on_focus.

This allows tooltips to be selectively enabled on focus, depending on the result of which Interaction Media Features the user’s device supports.

Variants

Always

Always show the tooltip on element focus.

This is the default option, and provides a reliable and accessible alternative when using a non-hover-capable device (such as a touchscreen) or navigating with a keyboard on a device that also has a pointing device.

Because of the many side-effects, browser and platform bugs that come from attempting to selectively disable showing tooltips on focus, this is generally the best choice, but may lead to unexpected tooltip display for users on a desktop browser with a traditional mouse.

IfHoverNone

Show the tooltip on element focus only if the primary pointing device does not support hovering (eg: touchscreen), or there are no pointing devices connected (hover: none).

If the primary pointing device supports hovering (eg: mouse, trackpad, trackball, smart pen, Wiimote, Leap Motion Controller), the tooltip will not be shown when the element has focus.

Figuring out what the “primary” pointing device actually is can be complicated to answer for some devices. They generally err towards reporting the use and presence of an ordinary mouse with hover capabilities (eg: Firefox bug 1851244), even when there are no pointing devices connected, or used with a touchscreen.

Both Chromium and Firefox on Windows erroneously report touch-only devices as having an ordinary mouse with hover capabilities if the device lacks an auto-rotation sensor (even if disabled), which is generally the case for non-tablet devices like external touchscreen monitors and all-in-one PCs).

Some Android devices also erroneously report hover: hover, even when they only have a touch screen.

Safari on iOS always reports hover: none, even when using an iPad with hover-capable pointing devices, such as the Apple Pencil (stylus), Magic Keyboard (trackpad) or an ordinary mouse with an external display. All hover-capable devices except the Pencil are reported via any-hover: hover.

For someone who primarily uses a keyboard to interact with their computer, but has a mouse plugged in (eg: a laptop with a built-in trackpad, or a virtual device), their browser will still report a primary pointing device which is “hover capable”, even when they have no way to hover.

These implementation problems and shortfalls make the hover: none media query unreliable, and an unreliable indicator of user preferences.

IfAnyHoverNone

Trigger showing the tooltip on element focus only if all pointing devices connected to the device do not support hovering, or there there are no pointing devices connected (any-hover: none).

For a device with only one non-hovering pointing device (eg: a mobile phone with a touch screen or basic stylus), this is the same as TooltipFocusTrigger::IfHoverNone.

For a device with both hovering and non-hovering pointing device(s) (eg: a laptop with a trackpad and touchscreen, or a tablet with both pen and touch input), this option will never show will never show the tooltip on focus.

Unfortunately, there is no way to detect if not all pointer devices support hovering.

Most desktop browsers will always report the presence of an ordinary (hover-capable) mouse, even if none is attached. This can be caused by:

• a wireless mouse dongle which is plugged in, but the wireless mouse itself is turned off

• the presence of a PS/2 mouse controller

• the presence of a virtual mouse device

• a touch screen which does not have an automatic rotation sensor (but this will report hover events from touch), due to Chromium and Firefox bugs.

These issues may also impact someone who primarily uses a keyboard to interact with their computer.

These implementation problems and shortfalls make the any-hover: none media query an unreliable indicator of user preferences.

IfAnyPointerNoneOrCoarse

Trigger showing tooltips on element focus only if:

• there are no pointer devices present (any-pointer: none), or,
• there are coarse pointer devices present (any-pointer: coarse), such as a touchscreen, Wiimote or Leap Motion Controller

This is a work-around for there being no way for a browser to report that not all devices support hover, and the complex heuristics required (which all browsers lack) to determine which is the “primary” pointing device on desktop and laptop computers.

The intent of this mode is that tooltips will be shown on focus for devices with touchscreens, regardless of whether they have an auto-rotation sensor.

The side-effects are:

• hovering coarse pointer devices (like the Wiimote and Leap Motion Controller) will also show tooltips on focus, even though they can hover
• traditional-style laptops with touchscreens (ie: not foldable or convertible into a tablet) will also show tooltips on focus, even though using the touchscreen as a primary pointing device is very uncomfortable (because it requires reaching over the keyboard)
• non-hovering fine pointer devices (like basic stylus digitisers) will not show tooltips on focus, even though they can’t hover
• a user primarily using non-pointer (keyboard) input but with at least one fine pointing device connected (such as a laptop with built-in trackpad) will never see tooltips on focus
• Safari doesn’t fire focus events on components on click or touch if it does not accept keyboard input (eg: <a> and <button>)

Never

Never show the tooltip on element focus.

Make sure there is some other way to trigger the tooltip which works on all types of devices and meets users’ preferred input modalities.

Trait Implementations

impl Clone for TooltipFocusTrigger

fn clone(&self) -> TooltipFocusTrigger

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for TooltipFocusTrigger

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for TooltipFocusTrigger

fn default() -> TooltipFocusTrigger

Returns the “default value” for a type.

impl IntoPropValue<TooltipFocusTrigger> for bool

fn into_prop_value(self) -> TooltipFocusTrigger

Convert self to a value of a Properties struct.

impl PartialEq for TooltipFocusTrigger

fn eq(&self, other: &TooltipFocusTrigger) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Copy for TooltipFocusTrigger

impl Eq for TooltipFocusTrigger

impl StructuralPartialEq for TooltipFocusTrigger