CSS：トグルとしてのモバイルまたは他のデバイスのホバー
単純な:hoverスライドインカバーは、図に示すように、「お気に入りの記事」コントロールでスライドすることになっています。このコントロールをクリックすると、このアイテムをお気に入りに追加できます。
デスクトップでマウスをホバーしてクリックするとうまく機能しますが、モバイルや他のデバイスで効果的なコントロールとして使用できるかどうかはわかりません（つまり、クリックして切り替え、もう一度クリックしてお気に入りの項目に移動します）。
私が正しく理解している場合、少なくともiOS（Safari）とAndroid（Chrome））では、ブラウザのデフォルトの動作は、タッチをhoverとclickの両方としてエミュレートすることです。しかし、それは標準ですか？例.
- Windows PhoneやWii Uでも同じことができますか？
clickはhoverの約300ミリ秒後に発生するため、ゴーストクリックの問題が発生する可能性がありますか？
この要素にクリック/タッチイベントを確実にバインドできます。css:hoverは今日では十分です。
明確にするため：:hoverサポート。これは、ポインター駆動環境でのみ意味があります。ユーザーがクリック/タップしたときにデバイスがホバリング可能な要素を処理できるかどうか、また処理する必要があるかどうかを確認します（iOS/Androidと同様）
質問が完全に明確ではなく、「すべてのデバイスで:hoverを使用できますか？」または「:hoverはすべてのデバイスで同じように動作しますか？」または「:hoverはWeb上の標準要素ですか？」
また、現在最も使用されているデバイスを念頭に置いている場合、またはあまり知られていない、使用されているデバイスも考慮に入れている場合は、「すべてのデバイス」の概念に大きく依存します。
私はあなたに以下を引用しますが、あなたはすでにそれを読んだことと思います：
インタラクティブなユーザーエージェントは、ユーザーの操作に応じてレンダリングを変更することがあります。 CSSは、一般的なケースに3つの疑似クラスを提供します。
：hover疑似クラスは、ユーザーが要素（ポインティングデバイスを使用）を指定している間は適用されますが、アクティブ化しません。たとえば、視覚的なユーザーエージェントは、要素によって生成されたボックスの上にカーソル（マウスポインター）を置くと、この疑似クラスを適用できます。 インタラクティブメディアをサポートしないユーザーエージェントは、この疑似クラスをサポートする必要はありません。インタラクティブメディアをサポートする一部の準拠ユーザーエージェントは、この疑似クラスをサポートできない場合があります（例：ペンデバイス ）。 ：active疑似クラスは、ユーザーが要素をアクティブ化しているときに適用されます。たとえば、ユーザーがマウスボタンを押してから放すまでの間。
CSSは、上記の状態になる可能性のある要素、または状態の開始方法と終了方法を定義しません。スクリプトは、要素がユーザーイベントに反応するかどうかを変更する場合があり、デバイスやUAによって、要素をポイントしたりアクティブ化したりする方法が異なる場合があります。
5.11.3動的擬似クラス：：hover、：active、および：focus http://www.w3.org/TR/CSS2/selector.html#dynamic-pseudo -クラス
W3C仕様で確認できるように、:hover疑似クラスは非インタラクティブメディアユーザーエージェントとsomeインタラクティブメディアユーザーエージェント。したがって、:hoverは常にサポートされているとは限りません。
問題について深く掘り下げるには、Safari Mobileに関する次の仕様を読んでください。
さらに、iOSユーザーのSafariは、マウスを使用するのではなく、指で直接Webコンテンツを操作します。 これにより、タッチ対応インターフェイスに新しい機会が生まれますが、ホバー状態ではうまく機能しません。たとえば、マウスポインターをWebページ要素の上に置くと、イベントがトリガーされます。マルチタッチ画面上の指はできません。このため、マウスイベントはiOSのSafariでエミュレートされます。その結果、mousemove、mouseover、mouseout、またはCSS疑似クラス：hoverのみに依存する要素は、iPadやiPhone。
DOM Touchイベントのtouchstart、touchmove、touchend、およびtouchcancelを使用して、タッチを直接処理するか、iOSのSafariで高度なジェスチャーを検出することもできます。 エミュレートされるマウスイベントとは異なり、DOMタッチイベントはタッチインターフェイスで動作するように特別に設計されているため、その動作は信頼性が高く、期待されています。
5。タッチインターフェイスの準備 https://developer.Apple.com/library/content/technotes/tn2010/tn2262/_index.html
Appleはここで、タッチジェスチャーでポインターをエミュレートする傾向があることを明確に述べていますが、:hover疑似クラスはタッチデバイスで同じように動作しないため、使用しないことを明確に提案しています。
さらに掘り下げて、地球上に存在する各ユーザーエージェントのすべてのドキュメントを取得することもできますが、前の2つで十分です。
- 非インタラクティブデバイスは
:hoverをサポートする必要はありません - インタラクティブデバイスは疑似クラスをサポートできます（ただし、これは必須ではなく、スクリーンリーダーや点字画面など、無視できます）。
- ポインターがない場合のApple touchデバイスは
:hoverをエミュレートします - 現在のタッチデバイスも
:hoverをエミュレートすると想定しても安全です - 他のブラウザ/デバイスは、それらのインターフェースによっては必ずしも
:hoverをサポートする必要がないと想定しても安全です。 - 最近のブラウザはすべて
:hoverをサポートする可能性が非常に高いです。
したがって、上記で想定したすべての質問に答えるために：
「
:hoverはWebの標準要素ですか？」
ホバーは標準のW3Cであり、実際にはポインターイベントによってトリガーされる必要がある、but一部のインターフェースでは必要ありません。
「すべてのデバイスで
:hoverを使用できますか？」
はいおそらくできます。 ：hoverをサポートしないデバイスは、おそらくメインのターゲットではないデバイス/ユーザーです。 「誰が私の製品のエンドユーザーになるのですか？」彼らがモバイルユーザーのみ、または視覚障害者のみ、またはニンテンドーを使用して閲覧したい人々のみの場合DS次に、:hoverイベントを使用しないでください。それ以外の場合は使用してください。
「
:hoverはすべてのデバイスで同じように動作しますか？」
いいえ、Appleがデバイスに記載されているため、デスクトップと同じように動作しません。おそらく、ポインタのないすべてのデバイスで同じ動作を反映しています。
ホバー状態によるユーザーアクションを計画している場合は、実行しないでください。これは一般に悪い習慣であり、デスクトップデバイスを含め、どのような場合でも避けるべきです。ホバーは行動を促すフレーズではなく、クリックです。ホバーは「トグル」として扱われるべきではなく、クリックされた場合にアクションをトリガーするその要素をユーザーに理解させるための視覚的なヘルパーのようなものです。
私があなたのアプリケーションを理解したなら、ホバーは信頼できません、そしてあなたの特定のケースでは、あなたはそれがどのように機能するべきかを再考する必要があります。より信頼性の高い方法を使用する（およびユーザーから期待される）
マウスとキーボードでブラウジングする場合、カーソルをWebページ要素の上に置くのが一般的なアクションですが、タッチベースのブラウジングでは同等のアクションはありません。このトピックでは、aria-haspopup Document Object Model（DOM）プロパティを使用して、Windows 8上のInternet Explorer 10でタッチ対応デバイスのホバーをシミュレートする方法を示します。
この動作は、Windows 7のInternet Explorer 10（aria-haspopupによるホバーシミュレーションをサポートしていない）またはWindows 8.1のInternet Explorer 11（組み込みのタッチホバーサポートがある）には適用されません。
タッチシナリオでは、タッチされている要素にホバーが適用されます。ただし、要素をタップすると、リンクのナビゲートなど、要素をアクティブにすることもできます。事実上、タップは1つのアクションでホバーとアクティブ化の両方です。これにより、タッチユーザーはホバーの後ろに隠されたインタラクティブコンテンツにアクセスできなくなります。インタラクションモデルは完全に異なり、ページ要素の上にカーソルを置くことに類似したタッチはありません。
ベストプラクティスは、ユーザーが操作できるコンテンツを非表示にするためにホバーを使用しないことです。代わりに、onclickイベントを使用して表示を切り替えることを検討してください。
この質問の一部、つまり「ホバー」に関連するWindows Phoneの実際の動作はまだ答えられていないようです。明確にするために：
'ホバー'がオブジェクトに適用されるスタイルを変更するように、CSSマークアップが存在するデスクトップ/マウス用に記述されたWebページを考えます。 iPhoneまたはAndroid（Android $ ====）でそのページを表示し、オブジェクトをタップすると、スタイルの変更が発生します（つまり、オブジェクトにスタイルを変更するonClick（）イベントハンドラーがあるかのように動作します）。同じことがWindows Phoneでも起こりますか？
少なくともWin 8.1を実行しているNokia Lumia 630については、その質問に答えることができます。
いいえ。タップの最初の部分で指で押し下げると、スタイルの変更が発生しますが、タップの最後で指を離すと、スタイルが元に戻ります。 （これはおそらくタッチの「ホバー」のより有効な解釈ですが、それが実際に役立つかどうかは別の問題です。）
IPhone/Safariのホバーの解釈にも「オフ」状態があると付け加えておきます。これは、別のオブジェクトをタップするとトリガーされます。
これを表示し、さまざまなデバイス/ブラウザーでのテストを可能にするために、デモページを www.davidleader.net/mobiledemo.html に設定しました。これはonClick（）、onMouseover（）および：hoverを実装して画像の不透明度を変更し、下にある別の不透明度を表示します。 （したがって、不透明度のサポートに依存しますが、これはしばらく前からあります。）iPhoneのホバーの終わりを示すためにクリックする「ダムのグラフィック」もあります。
要約すると、モバイルデバイスのホバーの解釈に関するde jure標準がないだけでなく、deもありません。 factoのいずれか。したがって、モバイルをターゲットにしている場合は、「ホバー」を避けてください。
現時点では、モバイルの：hover状態を適切にサポートするものはありません
私はモバイルでModernzr.jsを使用していませんが、ブラウザーがタッチイベントをサポートしているかどうかを検出できると記載されているため、ユーザーがモバイルデバイスを使用している場合は、基本的にHTMLタグに「.touch」クラスを追加します。
したがって、このように使用します。たとえば、
.touch a:active{ /*css code here */ }
うまくいけば、これは何らかの形で役立つでしょう
携帯電話に関しては、標準があるとは思えません。はい、タッチデバイスがタッチされているときにホバー状態を適用することは非常に一般的ですが、ユーザーがホバー状態を異なる方法で解釈する可能性のある任意の数のブラウザーを使用していたかどうかはわかりません。
私はあなたの最善の策は、最も低い共通の分母を狙って撃つことであり、すべてのタッチデバイスがタッチアクションにのみ応答できると仮定することです。
もちろん、その答えは、メディアクエリやJavaScriptを記述して、ブラウザに希望どおりの動作をさせることです。
それだけの価値があるので、それは私の個人的な哲学にすぎません。