it-swarm.dev

CSS: najedź kursorem na urządzenie mobilne lub inne jako przełączanie

Wykonuję prostą okładkę wsuwaną :hover, jak pokazano na zdjęciu, powinna ona przesuwać się w formancie „ulubionego artykułu”, który użytkownik może następnie kliknąć, aby ulubić ten element.

Chociaż działa dobrze na pulpicie za pomocą kursora myszy i kliknięcia, nie jestem pewien, czy można go użyć jako skutecznej kontroli na urządzeniu mobilnym lub innym (np. Kliknij, aby przełączyć, a następnie kliknij ponownie na ulubiony element).

Jeśli dobrze rozumiem, przynajmniej w systemie iOS (Safari) i Android (Chrome), domyślnym zachowaniem przeglądarki jest emulowanie dotyku jako hover i click. Ale czy jest to standard ? na przykład.

  • Czy Windows Phone lub Wii U zrobi to samo?
  • Czy click zostanie zwolniony około 300ms po hover, więc może pojawić się problem z kliknięciem ducha?

Z pewnością mogę powiązać zdarzenie click/touch na tym elemencie, zastanawiając się tylko, czy css :hover jest obecnie wystarczający.

Aby wyjaśnić : Nie pytam o obsługę :hover, która tworzy zmysły tylko w środowisku sterowanym wskaźnikiem. Pytam, czy urządzenia mogą i powinny obsługiwać element najeżdżający, gdy użytkownicy klikają/pukają (tak jak robią to iOS/Android)

enter image description here

19
bitinn

Twoje pytanie nie jest całkowicie jasne i nie mogę zrozumieć, czy pytasz „Czy mogę używać :hover na wszystkich urządzeniach?” lub „Czy :hover zachowuje się tak samo na wszystkich urządzeniach?” lub „Czy :hover jest standardowym elementem w sieci?”

Również w dużej mierze zależy od twojej koncepcji „wszystkich urządzeń”, jeśli myślisz o aktualnie używanych urządzeniach lub bierzesz również pod uwagę mniej znane i używane urządzenia.

Przytoczę ci następujące słowa, ale jestem pewien, że przeczytałeś już:

Interaktywne aplikacje użytkownika czasami zmieniają renderowanie w odpowiedzi na działania użytkownika. CSS zapewnia trzy pseudoklasy dla typowych przypadków:

Pseudo-klasa: hover ma zastosowanie, gdy użytkownik wyznacza element (z niektórymi urządzeniem wskazującym), ale go nie aktywuje. Na przykład a wizualny agent użytkownika może zastosować tę pseudoklasę, gdy kursor (wskaźnik myszy ) znajdzie się nad ramką wygenerowaną przez element. Aplikacje użytkownika nie obsługa mediów interaktywnych nie musi obsługiwać tej pseudoklasy . Niektóre zgodne z wymaganiami aplikacje użytkownika obsługujące media interaktywne mogą nie być w stanie obsługiwać tę pseudoklasę (np. a urządzenie piszące). The: active pseudoklasa ma zastosowanie, gdy element jest aktywowany przez użytkownika . Na przykład między czasami naciśnięcia przycisku myszy i uwalnia to.

CSS nie określa, które elementy mogą być w powyższych stanach, ani jak stany są wprowadzane i opuszczane. Skrypty mogą zmienić, czy elementy reagować na zdarzenia użytkowników lub nie, i inne urządzenia i aplikacje klienckie mogą mieć różne sposoby wskazywania lub aktywowania elementów.

5.11.3 Dynamiczne pseudoklasy:: hover,: active i: focus http://www.w3.org/TR/CSS2/selector.html#dynamic-pseudo-classes

Jak widać na specyfikacji W3C, twierdzi ona, że ​​pseudo-klasa :hover nie jest wymagana dla nieinteraktywnych agentów użytkowników mediów, a także niektóre interaktywne programy użytkownika mediów . Dlatego można założyć, że :hover to nie zawsze obsługiwane.

Aby się głęboko zastanowić, przeczytaj poniższą specyfikację dla Safari Mobile:

Ponadto Safari na użytkownikach iOS współdziała z twoją zawartością internetową bezpośrednio palcami, a nie za pomocą myszy. To tworzy nowe możliwości interfejsów dotykowych, ale nie działa dobrze ze stanami hover. Na przykład wskaźnik myszy może najechać kursorem na element strony internetowej i wywołanie zdarzenia; palec na ekranie Multi-Touch nie może. Z tego powodu zdarzenia myszy są emulowane w Safari na iOS . W rezultacie elementy, które polegają tylko na przesuwaniu myszy, najechaniu myszą, na myszy lub pseudoklasa CSS: hover nie zawsze zachowuje się zgodnie z oczekiwaniami na urządzenie z ekranem dotykowym, takie jak iPad lub iPhone.

Możesz obsługiwać dotknięcia bezpośrednio lub nawet wykrywać zaawansowane gesty w Safari w systemie iOS, korzystanie z zdarzeń dotykowych DOM Touch, touchmove, dotknij i anuluj. W przeciwieństwie do zdarzeń myszy, które są emulowane, DOM Zdarzenia dotykowe są specjalnie zaprojektowane do współpracy z interfejsami dotykowymi więc ich zachowanie jest wiarygodne i oczekiwane.

5. Przygotuj się na interfejs dotykowy https://developer.Apple.com/library/content/technotes/tn2010/tn2262/_index.html 

Apple wyraźnie stwierdza, że ​​mają tendencję do emulowania wskaźnika za pomocą gestów dotykowych, jednak wyraźnie sugerują, aby unikać używania pseudo-klasy :hover, ponieważ nie zachowuje się tak samo na swoim urządzeniu dotykowym.

Moglibyśmy zagłębić się głębiej i pobrać każdą dokumentację dla każdego agenta użytkownika istniejącego na ziemi, ale dwa poprzednie wystarczą, aby przyjąć następujące założenia:

  • Urządzenia nieinteraktywne nie muszą obsługiwać :hover
  • Urządzenia interaktywne mogą obsługiwać pseudoklasę (ale nie jest to obowiązkowe i mogą je zignorować, na przykład czytniki ekranu lub ekrany brajlowskie)
  • Urządzenia Apple Touch w przypadku braku wskaźnika emulują :hover
  • Można bezpiecznie założyć, że obecne urządzenia dotykowe również emulują :hover
  • Można założyć, że każda inna przeglądarka/urządzenie nie musi obsługiwać :hover w zależności od interfejsu.
  • Prawdopodobnie wszystkie najnowsze przeglądarki będą obsługiwać :hover, ponieważ jest to wizualna pomoc dla użytkownika.

Aby odpowiedzieć na wszystkie pytania, które założyłem powyżej:

„Czy :hover jest standardowym elementem w sieci?”

Hover jest standardowym W3C, w rzeczywistości twierdzi, że must jest wyzwalane przez zdarzenie wskaźnika, ale nie jest wymagane dla niektórych interfejsów.

„Czy mogę używać :hover na wszystkich urządzeniach?” 

Tak, prawdopodobnie może. Urządzenia, które nie obsługują: hover bardzo prawdopodobne są urządzenia/użytkownicy, którzy prawdopodobnie nie są twoim głównym celem. Lepiej zadaj sobie pytanie „Kto będzie końcowym użytkownikiem mojego produktu?” jeśli są to tylko użytkownicy mobilni lub tylko osoby niewidome lub tylko ludzie, którzy lubią przeglądać za pomocą Nintendo DS, nie używaj zdarzeń :hover, w przeciwnym razie.„Czy :hover zachowuje się tak samo na wszystkich urządzeniach?”.

Jeśli planujesz akcję użytkownika za pomocą stanu najechania, nie rób tego. Jest to na ogół zła praktyka i należy jej unikać w każdym przypadku, w tym urządzeń biurkowych. Najechanie nie jest wezwaniem do działania, kliknij. Najechanie nie powinno być traktowane jako „przełączanie”, ale raczej jako pomocnik wizualny dla użytkownika, który rozumie, że element, po kliknięciu, uruchamia akcję.

Jeśli zrozumiałem twoją aplikację, to nie powieść się w sposób niezawodny iw twoim konkretnym przypadku powinieneś przemyśleć, jak powinna działać Użyj bardziej niezawodnej metody (i oczekiwanej od użytkownika).

If you plan to have an user action via a hover state don't do it. This is generally bad practice and it should avoided in any case, including desktop devices. Hover is not an call to action, click is. Hover should not be treated as a "toggle" but more like a visual helper for the user making him/her understand that element, if clicked, triggers an action.

If I understood your application then hover isn't reliable and in your specific case you should rethink on how it should work.Use a more reliable method (and expected from your user)

20
MacK

Najechanie kursorem na element strony internetowej jest typowym działaniem podczas przeglądania za pomocą myszy i klawiatury, ale nie ma odpowiednika, jeśli chodzi o przeglądanie dotykowe. W tym temacie pokazano, jak użyć właściwości modelu obiektów (aria-haspopup) do symulowania najechania na urządzenia z obsługą dotyku za pomocą programu Internet Explorer 10 w systemie Windows 8.

To zachowanie nie dotyczy przeglądarki Internet Explorer 10 w systemie Windows 7 (która nie obsługuje symulacji najechania za pomocą aria-haspopup) ani Internet Explorer 11 w systemie Windows 8.1 (która ma wbudowaną obsługę hoverów dotykowych).

W scenariuszach dotykowych najechanie jest stosowane do elementu podczas jego dotykania. Jednak dotknięcie elementu może również aktywować element, taki jak nawigacja po łączu. W efekcie dotknięcie jest aktywowane w jednej akcji. To sprawia, że ​​interaktywne treści ukryte za zawisaniem są niedostępne dla użytkowników dotykowych. Model interakcji jest zupełnie inny i nie ma dotykowego analogu do najechania kursorem na element strony.

Najlepszą praktyką jest nieużywanie kursora w celu ukrycia treści, które użytkownik może współdziałać z. Zamiast tego rozważ użycie zdarzenia onclick do przełączenia widoczność.

3
mohamedrias

Wydaje mi się, że nie udzielono jeszcze odpowiedzi na to pytanie, a mianowicie na faktyczne zachowanie telefonów z systemem Windows w odniesieniu do „zawisu”. W celu wyjaśnienia:

Rozważmy stronę internetową napisaną dla użycia pulpitu/myszy, w której znajduje się znacznik css, dzięki czemu „zawisanie” zmienia styl zastosowany do obiektu. Jeśli ktoś obejrzy tę stronę na iPhonie lub Androida i dotknie obiektu, nastąpi zmiana stylu. (tj. zachowuje się tak, jakby obiekt miał procedurę obsługi zdarzenia onClick (), aby zmienić styl). Czy to samo dzieje się na Windows Phone?

Mogę odpowiedzieć na to pytanie, przynajmniej w przypadku Nokia Lumia 630 z Win 8.1:

Nie. Po naciśnięciu palcem w początkowej części kranu następuje zmiana stylu, ale po zwolnieniu palca na końcu stuknięcia styl powraca do oryginału. (Jest to zapewne bardziej poprawna interpretacja „zawisania” dla dotyku, chociaż to, czy ma jakiekolwiek praktyczne zastosowanie, to inna sprawa.)

Dodam, że interpretacja hovera na iPhone/Safari ma także stan „wyłączony”. Jest to wyzwalane po dotknięciu innego obiektu.

Aby to pokazać i umożliwić testowanie na różnych urządzeniach/przeglądarkach, utworzyłem stronę demonstracyjną na www.davidleader.net/mobiledemo.html . Realizuje on onClick (), onMouseover () i: hover, aby zmienić krycie obrazu, odsłaniając inny pod spodem. (Dlatego zależy to od obsługi krycia, ale trwa to już od jakiegoś czasu.) Istnieje również „głupia grafika”, która pozwala na pokazanie końca hovera na iPhonie.

Podsumowując, podobnie jak nie ma standardów de jure dla interpretacji zawisu na urządzeniach mobilnych, nie ma też żadnych de facto. Dlatego jeśli kierujesz telefony komórkowe, unikaj „zawisania”.

2
David

W tej chwili nie ma dobrego wsparcia dla: hover state w mobile 

Zobacz powiązane pytanie na ten temat

Nie używałem Modernzr.js dla urządzeń mobilnych, ale mówi, że może wykryć, czy przeglądarka obsługuje zdarzenia dotykowe, więc zasadniczo dodaje klasę „.touch” do znacznika HTML, jeśli użytkownik korzysta z urządzenia mobilnego.

więc użyjesz go w ten sposób, np

.touch a:active{ /*css code here */ }

miejmy nadzieję, że to pomoże

1
arnold

Jeśli chodzi o telefony komórkowe, wątpię, czy istnieje jakikolwiek standard. Tak, bardzo często zdarza się, że urządzenie dotykowe stosuje stan zawisu podczas dotykania, ale nigdy nie wiadomo, czy użytkownik może używać dowolnej liczby przeglądarek, które mogą inaczej interpretować stan zawisu.

Powiedziałbym, że najlepszym rozwiązaniem byłoby strzelanie do najniższego wspólnego mianownika i założenie, że każde urządzenie dotykowe może reagować tylko na akcje dotykowe.

Odpowiedzią na to jest oczywiście pisanie zapytań o media i/lub javascript, aby zmusić przeglądarki do działania w pożądany sposób.

To tylko moja osobista filozofia, za co warto.

0
Grapho