В #296 я рассказал, как я кастомизировал блок menu под себя при реализации своего меню.
При попытке использовать его же для списка подсказок для поля типа 'autocomplete' снова столкнулся с проблемой.
Дело в том, что при навигации с помощью курсорных стрелок выделенному пункту устанавливается модификатор hovered.
Этот же модификатор используется и при наведении на пункт меню курсором мыши.
При этом, чтобы добиться выделения пункта курсорными клавишами независимо от временного визуального эффекта при наведении придётся снова переопределять несколько методов, скопировав их практически полностью в проект (свою библиотеку) и изменив всего пару строчек в каждом.
См. поле ввода URL/поиска в Хроме в качестве примера:
Возможно ли запросить более гибкую реализацию методов у блока menu, которые позволят это делать без копипаста кода библиотеки?
Или я один хочу такого странного?
Идея шагать клавишами хорошая, мы пока этого не делали, но планируем. Не знаю как синхронизировать наработки комьюнити и bem-team. @tadatuta что нам делать? Было бы не плохо выкладывать наработки блоков куда-то на ревью и суд. Дабы вместе делать хорошо)
@Guria Главный вопрос, который тут возникает: а зачем это нужно?
@verybigman делитесь проектами в https://github.com/bem-incubator и заказывайте ревью на форуме. Не могу обещать скорую реакцию, но по возможности попробую посматривать.
@tadatuta а дайте права кому-нить, плиз)
@verybigman you've got an email ;)
Thanks!
пока мы специально считали, что это странное поведение и оставили только один ховер
Пока?
@tadatuta Тож хочу на все, что там есть, и что новое будет подписаться. Это только через участие? Тогда запрашиваю тож ;-)
@zxqfox you've got the power!
:battery: !!
@tadatuta тоже не против поучаствовать
По основной теме — я за отдельное состояние типа selected, но не уверен, что это должно быть в
menu. Может быть вmenu_selectable?@Guria отправил инвайт @zxqfox хочу реальных жизненных примеров, зачем оно нужно
@tadatuta Для того же, для чего и tabIndex. Не у всех есть модный маковский тачпад или мышка. Да и если набираешь на клавиатуре в поиске что-то, тебе вываливается список подсказок — рука самопроизвольно тянется на клавиатуре выбрать (точнее, она там и находится, и до мышки тянуться не хочет). Но это не ховер, это выделение. Но, опять же, если это мультиселект — совсем очевидно становится, что selected могут быть несколько, а ховер — только один, текущий. Но это не совсем меню, это некий список для выбора, а у нас для этого меню используется. Не скажу, что меню — плохое название, но может быть путает. UX мать иво.
@zxqfox зачем в описанной тобой ситуации сохранять ховер? какую задачу это решит?
@tadatuta Я выбрал нужны пункт на клавиатуре, рука дернулась, мышка проехалась по списку, выбранный пункт съехал, :rage2:, UX :hankey:
@zxqfox этот же сценарий можно читать в другую сторону — я заховерил конец списка, хотел «подтюнить» стрелками, а оказался в начале списка, :rage2:, UX :hankey:
@tadatuta Нет ;-) если заховерил, а потом начал двигать клавиатурой — у тебя селектед должен идти от ховера (а изначально от фокуса инпута), а после, если ты дернешь мышкой, у тебя как раз все собъется. В любом случае, мы должны исходить из фокуса пользователя и его удобства — и если он после набора текста для поиска на клавиатуре взял мышь и подвинул её до списка, а после опять на клавиатуре пытается выбрать, а после опять берет мышь — это самый сложный случай, но он больше вписывается в то, что я предложил изначально, потому что в этом случае он может щелкнуть кнопкой, тем самым поменять и ховер, и селектед. А когда ховер === селектед — мы не сможем отличить эти две ситуации, и на клавиатуре в принципе будет сильно менее удобно управлять, если что-то вдруг дернется. Банально, можно подвигать на клавиатуре, взять кружку чая, испить глоток, поставить — мышь дернется от вибраций, ховер переместится назад под курсор. :rage4: и все такое ;-)