При ховере на кнопку "Сохранить на яндекс.диск" , на неё вешается класс "button2_hovered_yes" и через него меняется бэкграунд на псевдоэлементе before, почему сделанно имеено так, а не на css ? Если бы это не был яндекс, можно было бы списать всё на разработчика, но в данном случае, предположу, причина иная.
Можете не искать подвоха, его нет. Всё очень просто и прозаично — это их родной БЭМ в его чистейшей интерпретации. Они же используют полный стек БЭМа, а не только нотацию имен классов. Любой стиль определяется только классом. Каждый компонент лежит в отдельной папке, внутри js/css/img, стили разбиты еще на файлы — стили блока/элемента/модификатора в отдельных файлах. Всё это собирается чудо-машиной БЭМ.js.
Владимир Проскурин, ну они то же самое написали — Его Величество БЭМ =)
Когда блоки определяются в bem-json это удобнее, потому что полностью вписывается в идеологию бэма.
eugenekazakov, тонны причин. может быть не впадают в крайности, делают так, как удобнее в конкретных обстоятельствах, может немного по разному настроен процесс сборки, может легаси осталось, может …
Ну на мобильниках нет ховера - это главный вариант, а состояние кнопки нужно
БЭМ опять таки.... стили то - не главное, если js сказал ishovered, сss ответил - есть. т.е. в цсс просто прописывается состояние
Владимир Проскурин, там есть :focus activ - 'процесс нажатия, но не суть.
речь не о самом ховере а о состоянии на разных устройствах вот и подставляют стили, а когда состояние возникает - это другой вопрос.
Froggyweb, первый раз такое слышу. Если устройство умеет "наводить" мышкой, то оно будет вызывать :hover обязательно, если срабатывает mousemove на элементе, то и hover будет. Мне кажется, тут что-то сложнее или специфичнее.
блин. неважно есть мышка или нет.
просто название созвучно с событиями мыши. Может быть isCool-yes просто этим они обозначают что вид элемента зависит от каких то факторов.
Остальные стили - статичны.
зы button2_hovered_no как реализовать мышкой и css?
Froggyweb, я спорю о том, что зачем устанавливать класс, допустим .hover, и применять на него стиль, если есть :hover. Пока это выглядит тупо как костыль по незнанию. Нет повода так делать. Если нужно отслеживать наведение, зачем трогать классы? Следили бы спокойно, и оставили :hover.
зы button2_hovered_no как реализовать мышкой и css?
Зачем ставить такой класс по наведению? Вот в чем суть вопроса. Ставить просто так, чтобы было - глупо. Это либо костыль, либо специфичные механизмы.
Владимир Проскурин, в совеременной фронтенд-разработке не пишут на CSS и HTML, считай эту "неоптимальность" издержками проецирования состояния клиента на DOM в конкретном фреймворке (в данном случае, как уже заметили - BEM).
Froggyweb, можно использовать медиа-запросы @pointer: coarse/fine или @hover: none/hover для определения сенсорного экрана или полноценной поддержки :hover'a :))
Зачем ставить такой класс по наведению? Вот в чем суть вопроса. Ставить просто так, чтобы было - глупо. Это либо костыль, либо специфичные механизмы
Владимир Проскурин, ..... нет слов.
Во первых такой класс может ставится как при наведении так и при фокусе на вон тот инпут. по-моему мы говорим на разных языках
Froggyweb, я не понимаю, чего вы от меня хотите. Главный вопрос у меня в том, что они вместо использования :focus ставят модификатор focused_yes, вместо :hover ставят hovered_yes. Вы мне говорите про button2_hovered_no, хотя там такого нет. Конкретно на той странице, нет ничего такого, что заставило бы вместо использования стандартных селекторов, создавать классы. В посте на хабре уже ответили, это i-bem, без весомых причин.
Яндекс огромен, и они все соки высасывают из своей же методологии БЭМ. Цепляют модификаторы, так как обычный ховер не умеет изменять классы. А так различные причины могут быть, прицепить класс одна из них.
Простой
