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

Support "hover" and "active" styles for features #200

Closed
kkaefer opened this Issue Nov 25, 2013 · 16 comments

Comments

Projects
None yet
@kkaefer
Copy link
Contributor

kkaefer commented Nov 25, 2013

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.

ansis added a commit that referenced this issue Feb 21, 2014

add source.removeFeature()
Eventually for #200. Currently only works for fills
@mourner

This comment has been minimized.

Copy link
Member

mourner commented Jun 24, 2014

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

@mourner mourner modified the milestone: future Jun 24, 2014

@ansis

This comment has been minimized.

Copy link
Member

ansis commented Jun 24, 2014

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

@jfirebaugh

This comment has been minimized.

Copy link
Contributor

jfirebaugh commented Feb 19, 2015

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

This comment has been minimized.

Copy link
Member

mourner commented Feb 19, 2015

@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

This comment has been minimized.

Copy link
Member

tristen commented Apr 18, 2015

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

This comment has been minimized.

Copy link
Contributor

jfirebaugh commented Apr 18, 2015

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

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

@jfirebaugh jfirebaugh removed this from the future milestone Jun 15, 2015

@tristen tristen referenced this issue Aug 31, 2015

Open

Better feature design #14

0 of 5 tasks complete
@maletor

This comment has been minimized.

Copy link

maletor commented Nov 30, 2015

Is something like this still planned?

@lucaswoj

This comment has been minimized.

Copy link
Contributor

lucaswoj commented Dec 1, 2015

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

@knutole

This comment has been minimized.

Copy link

knutole commented Feb 27, 2016

👍

@lucaswoj lucaswoj removed the rendering label Mar 10, 2016

@dpieri

This comment has been minimized.

Copy link

dpieri commented May 1, 2016

+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

This comment has been minimized.

Copy link

elliotleelewis commented Jul 14, 2016

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

lucaswoj pushed a commit that referenced this issue Jan 11, 2017

@lucaswoj lucaswoj changed the title Add :hover and :active "pseudo-classes" Allow "hover" and "active" styles for features Feb 21, 2017

@lucaswoj lucaswoj changed the title Allow "hover" and "active" styles for features Support "hover" and "active" styles for features Feb 21, 2017

@1ec5

This comment has been minimized.

Copy link
Member

1ec5 commented Jan 26, 2018

“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

This comment has been minimized.

Copy link
Collaborator

andrewharvey commented Jan 26, 2018

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

This comment has been minimized.

Copy link
Contributor Author

kkaefer commented Jan 26, 2018

@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

This comment has been minimized.

Copy link
Member

1ec5 commented Jan 26, 2018

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

This comment has been minimized.

Copy link
Contributor

jfirebaugh commented Feb 14, 2018

#6021 / #6022

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment