У меня такое было (не ростелеком) через пару дней после покупки, мне кажется это проблемы самого гитхаба, похоже из-за массового импорта проектов в гитлаб и прочие.
Ещё с ebay помню что так делают когда товара нет в наличии чтобы не убирать лот с площадки (там какие-то заморочки вроде как на эту тему есть), возможно в случае с али та же самая ситуация. Может быть дело ещё в поисковом индексировании.
Сайт автора определит, что у меня работает ховер, и я со своим тачскрином обламаюсь в нормальном использовании сайта.
Сильно зависит от того как стили используются. Я хотел про это написать да вылетело из головы.
Если стили hover перекрывают стили под тач и ломают сенсорную работу то это само собой не нормально.
Моя мысль в том, что hover должен быть не основным инструментом, а дополнительным
Если уйти за рамки статьи то тут двоякая ситуация. Двоякость в том что интерфейс можно строить двумя способами:
1. заточенный сугубо под тот или иной вид взаимодействия (довольно сильно отличается от другого). Тут hover в одном случае будет как основной инструмент, в другом он вовсе будет отсутствовать. Но на деле различий будет сильно больше (те же разные размеры кнопок, наличие или отсутствие свайпов и т. д.)
2. компромиссный, где в среднем угождают всем, мудрят с адаптивностью и есть вспомогательные элементы разметки для focus событий (пример ссылки с всплывающей подсказкой, где под сенсорные устройства есть отдельный значок-кнопка т.к. по ссылке происходит переход). Тут грубо говоря и hover и focus рядом соседствуют и всё как-то усреднено.
В первом случае приоритет даётся основному назначению устройства, но в случае с 2-в-1 это не всегда возможно определить. Поэтому обычно всегда есть возможность переключиться в другой режим.
Во втором никакого приоритета не существует всё и так работает всегда.
Можно ещё скрестить эти два подхода и сделать морфирующийся интерфейс (плавное переключение на лету от поведения пользователя), но он всё равно не до конца решит проблему — в начале пользователь видит определённый вид интерфейса и думает что раз нет больших кнопок то надо тянуться к мышке (заветного тач события не происходит). То есть всё равно придётся в начале предлагать ему переключение чтобы он понял что интерфейс это вообще умеет.
Ну выше речь была только про вариант pointer:coarse от которого автор отказался в пользу варианта hover+костыли.
Вариант с hover+костыли более правильный, устройства 2-в-1 на любых обозревателях будут работать нормально.
А вот pointer:coarse сломает сенсорную часть на IE и Firefox: caniuse.com/#feat=css-media-interaction
Эти правила просто не выполнятся.
Угу, у меня вот ноут есть с сенсорным экраном, могу и так и сяк использовать.
По мне должны работать и стили hover и стили для сенсорных устройств одновременно или же переключаться на лету через JS.
Ну как нет, если на юнити точно так же выбираешь платформу Android и вместо красивых размытых динамических теней мы получаем «лесенки». Unity точно так же выдает картинку, которая будет на девайсе, вплоть до того, что можно эмулировать Open GL ES 3.0/2.0 + бегать между Shader Hardware Tier 1/2/3.
должен предупредить, не стоит по части шейдеров слишком сильно на этот режим эмуляции надеяться, сталкивался с ситуацией когда в нём всё норм, а на итоговой сборке шейдер глючит.
Как у анрила хз.
Вся эта xml-ная гадость в html-коде (впрочем, и не только в нём) раздражает.
О чём речь?
Да и какое вам до него дело, пользовались бы дальше костыльным HTML5.
Эти два стандарта развивались не мешая друг другу.
Одно в XHTML точно плохо это то что при нём обозреватель не рисует на лету разметку и пока документ не догрузится до конца страница не отобразится, отчего на больших страницах при плохой связности это большая проблема.
XHTML2 вероятно бы эту модель унаследовал, но в целом XHTML2 заметно чище и продуманнее, он мог бы дать толчок к очистке от груза всех остальных устаревших технологий и архитектурных ошибок. Тем более учитывая куда идёт веб (одностраничные веб-приложения), эта особенность XHTML уже не столь ощутима.
Есть ещё такие способы: https://css-tricks.com/fighting-the-space-between-inline-block-elements/ но каждый из них несёт свои проблемы.
Я нашёл вроде бы безпроблемный:
codepen.io/aaronbarker/full/MeaRmL
Форк с улучшениями:
gist.github.com/SahAssar/53a796f9aa5f89f9f16c92ca2607cdf6
+ по мелочи:
gist.github.com/frenkel/709d6d54d638f419e9ff2d148ee53287
Но гриды всё ещё молодая технология, поэтому надо учитывать ЦА ресурса.
В целом неплохо написано тут: developer.mozilla.org/ru/docs/Web/CSS/CSS_Grid_Layout/Relationship_of_Grid_Layout
Если стили hover перекрывают стили под тач и ломают сенсорную работу то это само собой не нормально.
Если уйти за рамки статьи то тут двоякая ситуация. Двоякость в том что интерфейс можно строить двумя способами:
1. заточенный сугубо под тот или иной вид взаимодействия (довольно сильно отличается от другого). Тут hover в одном случае будет как основной инструмент, в другом он вовсе будет отсутствовать. Но на деле различий будет сильно больше (те же разные размеры кнопок, наличие или отсутствие свайпов и т. д.)
2. компромиссный, где в среднем угождают всем, мудрят с адаптивностью и есть вспомогательные элементы разметки для focus событий (пример ссылки с всплывающей подсказкой, где под сенсорные устройства есть отдельный значок-кнопка т.к. по ссылке происходит переход). Тут грубо говоря и hover и focus рядом соседствуют и всё как-то усреднено.
В первом случае приоритет даётся основному назначению устройства, но в случае с 2-в-1 это не всегда возможно определить. Поэтому обычно всегда есть возможность переключиться в другой режим.
Во втором никакого приоритета не существует всё и так работает всегда.
Можно ещё скрестить эти два подхода и сделать морфирующийся интерфейс (плавное переключение на лету от поведения пользователя), но он всё равно не до конца решит проблему — в начале пользователь видит определённый вид интерфейса и думает что раз нет больших кнопок то надо тянуться к мышке (заветного тач события не происходит). То есть всё равно придётся в начале предлагать ему переключение чтобы он понял что интерфейс это вообще умеет.
Конечно ещё есть мобильный ие и мобильная лиса, они будут обрабатываться как 2-в-1 даже если у них нет hover.
Вариант с hover+костыли более правильный, устройства 2-в-1 на любых обозревателях будут работать нормально.
А вот pointer:coarse сломает сенсорную часть на IE и Firefox:
caniuse.com/#feat=css-media-interaction
Эти правила просто не выполнятся.
По мне должны работать и стили hover и стили для сенсорных устройств одновременно или же переключаться на лету через JS.
https://engineering.instagram.com/sharding-ids-at-instagram-1cf5a71e5a5c у инстаграма было как минимум так.
А вот на тему статьи ютубных идов, есть давно библиотека hashids о которой почему-то не упомянули.
должен предупредить, не стоит по части шейдеров слишком сильно на этот режим эмуляции надеяться, сталкивался с ситуацией когда в нём всё норм, а на итоговой сборке шейдер глючит.
Как у анрила хз.
Понятно.
С примерами сложно ибо не видел пока прямо удачных компаний.
А так вспоминается: WebExtension, flexbox, CSS Grid, SPDY.
+ о чём уже сказал lexxpavlov
Да и какое вам до него дело, пользовались бы дальше костыльным HTML5.
Эти два стандарта развивались не мешая друг другу.
Одно в XHTML точно плохо это то что при нём обозреватель не рисует на лету разметку и пока документ не догрузится до конца страница не отобразится, отчего на больших страницах при плохой связности это большая проблема.
XHTML2 вероятно бы эту модель унаследовал, но в целом XHTML2 заметно чище и продуманнее, он мог бы дать толчок к очистке от груза всех остальных устаревших технологий и архитектурных ошибок. Тем более учитывая куда идёт веб (одностраничные веб-приложения), эта особенность XHTML уже не столь ощутима.