Gesture-Based CSS Selectors
[This is a short, informal proposal of a concept, with a more extensive version in the near future. However, this should be enough for starting discussion on its value/implementation.]
What are Gesture-Based Selectors?
Gesture-based CSS selectors are a combination of the current set of CSS selectors/pseudo-selectors to include new set of gestures currently being used in mobile (tap, tap hold, swipe, etc.). The main goal is to give basic interactivity to elements without JavaScript support.
The closest analog would be the same sort of relationship with CSS3/JavaScript animation. In the current methodology:
- CSS3 – basic/simple animations, removing the need for JavaScript resources
- JavaScript/JavaScript Library via Events – complex animations, requiring more functionality beyond CSS3 animations
Initially, this was just focused to touch gestures. However, this can be also be extended to other "gestures" such as the current JavaScript events "click", "mouse(over/out)", "key(up/down)", etc. This will allow for non-touch gestures → keyboard, voice/speech, inputs from any other devices, etc.
CSS/Gesture Selectors Format
The concept is to have these represented in CSS code by the following selector (in two versions, using the mobile gestures swipe left and tap hold as examples):
- selector:gesture-(gesture name)
Similar to :hover, :focus pseudo-selectors (using current
Examples:
div:gesture-swipeleft { CSS code }
a:gesture-taphold { CSS code } - selector[gesture=”gesture name”]
Similar to attribute selectors, introduced in CSS 2.1 but in use more with CSS3
Examples:
div[gesture=”swipeleft”] { CSS code }
a[gesture=”taphold”] { CSS code }
Constraints/Problems
At this point, three initial problems appear:
- New Devices/Platform w/ Gestures – some sort of path/procedure needed for recognization of new gestures that is open and flexible. I recommend the following for an initial path:
Device/Platform Support → JS event support → CSS/gesture selector available
This will allow for the availibility for selectors mention above. However, there is the problem of device-specific gestures, which could mean that certain selectors will be available for only those devices. Currently, the touch events are only available on touch enable devices. If a [front-end] developer was writing code for a non-touch enabled device, the JS support would be non-existant -> no CSS/gesture support
- Gesture Uniformity – if a gesture gains support across platforms/devices, the related CSS selector should never be prefixed as we currently have for CSS3 features like animations or tranforms, ie "-iphone","-android", etc. I recommend this because unlike CSS3 features, these are OS based issues ("native"). The selectors will be device/platform "neutral" – let platforms/devices be solely responsible for interpretation.
- Computer Processing – if this gets implemented, how does this effect processor/power usage. How does the current set of CSS3 features (transitions/animations) deal with different computer processing power (hardware accelerators?)
If this gets added to the current set – will there be a bigger demand for hardware processing? What would this mean for small, less powerful devices? (the drive behind iPhone design and construction).
Overall – This is an issue that will need to be taken up post-proposal, with people more knowledgeable than me.
In summary,
- Creation of CSS/gesture selectors to allow for basic interactivity, without the need of JS events
- Providing a “path” to allow for more gestures, not just current but for future devices/platforms and be platform/device independent.