Support "hover" and "active" styles for features

[kkaefer]

When building the geometry buffer, we should store the position where we encode every individual feature so that later on, we can render individual features differently from the rest of the herd, e.g. for highlighting a feature.

[mourner]

https://github.com/mapbox/mapbox-gl-js/compare/feature-interaction — are we going to do this before public release @ansis?

[ansis]

@mourner I don't think this will be ready before the release, and I don't think it should block

[jfirebaugh]

I've been thinking about this in terms of pseudo-classes. Imagine you can define a style layer like:

{
  "id": "pois",
  "type": "symbol",
  "paint": {
    ...
  },
  "paint:hover": {
    ...
  },
  "paint:active": {
    ...
  }
}

[Insert handwaving about how pseudo-class state for a given feature would be determined (mouseover for :hover, click for :active).]

[mourner]

@jfirebaugh I like it. This separates styling interactive features and actual behavior (which would be defined in JS), while also being less cumbersome than defining classes.

[tristen]

Very interested in this feature. With what @jfirebaugh sketched above would it be possible to programmatically disable pseudo class state? I'm thinking about draw tools with modes like "draw" where you don't want to trigger a hover or active state of an existing feature unless you are in "edit".

[jfirebaugh]

Stacking classes with pseudo classes would allow that level of control:

"paint.edit-mode:hover": {
  ...
}

[maletor]

Is something like this still planned?

[lucaswoj]

@maletor Still planned. No timeline yet (sadly).

[knutole]

👍

[dpieri]

+1 would love to see this implemented. Also a :selected pseudo class would be great. The code I've written to emulate this behavior is very fragile and ugly.

[elliotleelewis]

Please implement this! Would be so useful for my work project! :)

[1ec5]

“Hover” and “active” are concepts that don’t exist on mobile platforms (except when assistive technologies are enabled). Regarding the proposal in #200 (comment), it doesn’t seem appropriate to introduce platform-specific concepts into a file format that up to now has been largely platform-agnostic (see also #5545).

[andrewharvey]

I think active works for mobile too, it's just a feature that the user has selected.

Agree that hover is inherently linked to desktop where you have a cursor.

[kkaefer]

@1ec5 you can hover with the Apple Pencil 😛, or you could use regular/force touch3D touch to discriminate between the two. Mobile Safari uses :hover as the first "stage" when interacting with an element.

[1ec5]

Haha, a stylus is the perfect match for feature querying!

Mobile Safari uses :hover as the first "stage" when interacting with an element.

That’s true, but the user would probably find a tap-twice requirement for selecting a marker to be highly inconvenient, especially if they’re already used to tapping once to select a feature on a native map. A developer would be inclined, then, to make :hover work like :selected, but would need to limit that behavior to mobile platforms. That goes back to my original point that gestures are too platform-specific to be a good fit for a map style language.

Perhaps if the style defines semantic states of some sort – “classes”? – then it could be up to the SDK or application developer to map these states to platform-specific concepts like tapping or hovering.

[jfirebaugh]

→ #6021 / #6022

[dollysingh3192]

Any Update, would be great to have this one.

[asheemmamoowala]

@dollysingh3192 This issue has been closed - and the requests are being tracked in the tickets mentioned in #200 (comment). We'll post updates on those issues when we start working on them. For now, these are not in our near term roadmap.