Comments 17
1) не проще было не делать display: none кнопке, а оставить её visibility:hidden и запреть фокусироваться на неё через tab-index?
2) Я правильно понял, что описанное решение использует ультра последние технологии и поэтому ближайшие несколько лет представляет только теоретический интерес? (пока там все актуальные версии сафари начнут его поддерживать)
3) jquery? зачем?
описанное решение использует ультра последние технологии
Вот этот вопрос тоже всегда беспокоит. Я на это смотрю, как на то, как я буду делать через 2-4 года, пока точно все браузеры на несколько версий назад будут поддерживать эти каттинг-эдж фичи, ибо далеко не все поддерживают браузеры в актуальном состоянии. Особенно на мобильных устройствах. Десктопные как-то вроде сами могут обновляться, а вот на мобилках смотрю иногда у людей на число в красном кружочке на АппСторе и понимаю, что там точно allow-keywords не прокатит :)
не проще было не делать display: none кнопке, а оставить её visibility:hidden и запреть фокусироваться на неё через tab-index?
А если у вас там целая форма? Надо будет перебирать все элементы? Я вообще предпочитаю универсальные решения: когда что-то схлопнулось, оно должно перестать отображаться. Тогда будет меньше сюрпризов. Какой, например, сюрприз может ждать нас в случае вашего подхода? Вы, возможно, не сталкивались с тем, что браузер не даёт вам 100% управления табабильностью (tabbable) через tab-index, а я сталкивался. Когда вы подписываетесь на события из списка ['focusin', 'focusout'], умный Хром решает, что вы хотите обидеть тех, кто плохо работает с мышью, и делает элемент tabbable насильно. Глубину проблемы я не знаю (для всех ли элементов так устроено, или только для тех, с которыми я работал), но я знаю, что этих (и других) проблем можно избежать, если не заменять универсальные решения костылями.
Я правильно понял, что описанное решение использует ультра последние технологии и поэтому ближайшие несколько лет представляет только теоретический интерес? (пока там все актуальные версии сафари начнут его поддерживать)
Во-первых, это зависит от вашей области. Если вы, например, как и я, часто пользуетесь CEF, этот вопрос становится неактуальным.
Во-вторых, что случится, если все эти «ультра последние технологии» не поддерживаются? Панель будет скрыта мгновенно. «На этот риск я готов пойти». Я читал, некоторые жалуются, что семёрочные ESR-браузеры не дают зайти в личный кабинет из-за того, что дизайнеры не добавили слой совместимости (конкретно — .groupBy() к Object) — а вот так, всё-таки, делать, наверно, не стоит. Хотя, может, разрабы посмотрели, и увидели, что из ста тысяч юзеров только один сидит на ESR. Жестокий бизнес жесток, и исключать подобное нельзя.
В-третьих, пока вы прочитаете, пока попробуете, «ультра последние технологии» уже станут повседневными.
И в-четвёртых, можно для совместимости какое-то время выставлять height из скрипта, а потом убрать этот код.
jquery? зачем?
Затем, что jQuery — это квази-язык, этакий DSL для декларативного описания DOM-преобразований. Как SQL. Как LINQ в дотнете. Лично меня крайне печалит, что вместо того, чтобы добавить стрингитайзеры для синтаксического контроля селекторов (вместо $('div.myclass') — $(div.myclass) с проверкой хотя бы того, что выражение имеет вид селектора), W3C пошёл по императивному пути переменных и циклов. Впрочем, это не единственная претензия к W3C.
И, между нами, был такой случай, когда человек написал какой-то трёхстраничный кошмар с пачками бойлерплейта (в том числе для установки всех CSS-свойств), а когда его спросили, не хочет ли он переписать в терминах jQuery и сократить код в десять раз, он очень смешно ответил: «Ну да, ну да, буду я ещё свой код говнякать применением jQuery». Я бы дал ссылку, но человек ещё обидится, пожалуй. И такой случай не единичен! Боюсь, тут есть какая-то связь.
jQuery может быть может упростить код, но это дополнительная зависимость, которая может прекратить свое существование и придется его потом усердно выпиливать. Я бы не стал тащить его в новые проекты.
Есть два типа программистов. Одни тащат библиотеку для определения, является ли число чётным. (Между прочим, в ноябре их набралось два миллиона). Для них, наверно, это будет большой удар, если их библиотека «прекратит своё существование».
А у других ружьё. А другие берут jQuery в качестве отправной точки, и аккуратно обрабатывают напильником. Вы думаете, jQuery идеален? Вовсе нет. Самый простой пример: допустим, вам надо обновить свойство элемента. В этом случае ортодоксальный jQuery требует кеширования предыдущего значения в переменной, что разрывает chaining (не говоря о введении ненужной переменной). А всё потому, что .data()/.attr()/.prop()/.val() не поддерживают лямбды. Это досадное упущение (и десятки других) для выразительности кода обязательно нужно исправить.
По сути, jQuery для меня не столько библиотека, сколько стандарт. От него мне нужны стандартные имена (чтобы люди, читающие мой код, видели привычные функции и понимали, что происходит) и дух (декларативность преобразований).
Поэтому, на вопрос, что я буду делать, если вдруг jQuery «прекратит своё существование», я могу ответить, что буду продолжать делать то, что делаю сейчас: и дальше развивать свой jQuery. Для меня мало что изменится.
На этом разрешите тему jQuery закрыть.
Честно не знал, что про jquery ещё так мыслят (что это стандарт и отправная точка).
Я без подкола, реально думал что такой подход умер лет 7 назад.
Спасибо за информацию, что такой взгляд существует. (повторяю, я без подкола)
Честно не знал, что про jquery ещё так мыслят (что это стандарт и отправная точка).
Более удачно было бы сказать, что это язык. Собственно, так я тоже сказал.
Я тоже думал, что некоторые вещи умерли много лет назад. Например, императивщина (переменные, циклы и прочее) там, где декларативный DSL рулит со страшной силой. Но как видите — нет.
Если человек будет делать
const id = sql.execute('SELECT id FROM Users WHERE Name == "Vasya"');
const phone = sql.execute('SELECT phone FROM Contacts WHERE User == {id}', id);
все же сразу скажут, что это извращение.
А с DOM'ом почему-то считается нормальным один запрос на преобразование раскидывать по куче циклов и переменных. Я так думаю, это потому, что SQL-сервер может висеть в Гвадалахаре на стокилобитным проводке, и все понимают, что гонять все данные туды-сюды — не очень хорошая идея. А DOM — он всегда тут, рядышком. Но дело ведь в выразительности. Выразительность страдать не должна.
Кроме того, дело тут не только в выразительности. И переменные, и циклы в данном случае приводят к проблемам. Начнём с переменных. Они нарушают DRY. Представьте себе, что вы закешировали результат запроса к DOM в переменной const toolbar = document.querySelector('div.toolbar'). Если разметка поменяется, и тулбар станет панелью с кнопками, вы поменяете селектор на div.toolpane, и всё заработает. А не должно! Потому что переменную вы забыли переименовать, и тот, кто будет работать с кодом, очень удивится, почему там тулбар, если договорились заменить его панелью. jQuery для кеширования предлагает chaining, в результате чего непосредственно селектор выступает в роли переменной, и дублирования не происходит. (Ещё обратите внимание, что слово «запрос» я использую в двух разных смыслах — запрос, который выполняет браузер, если передать ему селектор, и запрос, аналогичный запросу SQL или LINQ — цепочечное выражение на jQuery, которое описывает желаемое нами преобразование DOM).
Далее, циклы. Явные циклы исключают неявные циклы [в терминологии jQuery — implicit iteration], не так ли? А значит, такой подход провоцирует вас явно прописывать, ожидаете ли вы один узел или много. Соответственно, будут возникать ситуации, когда изначально вы ожидали один элемент, соответствующий селектору, и добавление в разметку второго (или больше) потребует и изменения кода: в него придётся добавлять явный цикл. Это та же самая проблема, что и с паттерном «Синглтон», когда предполагается, что элемент некого типа у вас один, но потом оказывается, что на самом деле их много. Или что, вы всегда пишете цикл руками «на всякий случай»?
Заметьте: я ничего не говорю о том, что jQuery — самая популярная библиотека в 2024-м году и и заруливает остальных со страшной силой. Для меня массовость — не аргумент. Мне не важно, сделан ли на ней весь Интернет, или её используют три с половиной анонимуса. Аргумент — это польза от инструмента. Выше я объяснил, в чём она.
Если вам нужны преобразования DOM, значит есть смысл описывать их на специальном языке, а не на универсальном ЯП, да ещё с элементами императивщины (то есть, Javascript'е).
.data()/.attr()/.prop()/.val() не поддерживают лямбды.
Пардон, только .data(). Это уж мои заморочки, что я их все одинаково переделал.
А если у вас там целая форма?
можно навесить аттрибут inert на форму
Во-первых, это зависит от вашей области.
Это очевидно, но автору стоило как-миниму упомянуть что его решение на момент написания не очень кроссбраузерно. а как максимум предложить полифилы/альтернативы
И, между нами, был такой случай, когда человек написал какой-то трёхстраничный кошмар с пачками бойлерплейта (в том числе для установки всех CSS-свойств), а когда его спросили, не хочет ли он переписать в терминах jQuery и сократить код в десять раз
Можно пример, как jquery уменьшает код в 10 раз?
везде используется jQuery
Он еще жив?
Скрытие элемента через его нулевую высоту не самый лучшый вариант. Но оставим его как имеющийся, ок.
А вот про display: none я бы предложил более кроссбраузерный вариант через кейфреймы:
.collapsed{ animation: hide var(--fast) ease forwards; overflow: hidden; } @keyframes hide { 99% { height: 0px; } 100% { display: none; } }
Проблема в том, что для этого нам нужно как-то найти время анимации.
Кажется эту проблему ещё можно решить с помощью метода document.startViewTransition и псевдокласса ::view-transition-old. Как-то так:
my-element.style.viewTransitionName = 'name-of-my-keyframe-animation';
document.startViewTransition(() => {
// удаляем элемнт из дом-а
});@keyframes name-of-my-keyframe-animation {
to {
transform: scale(0, 0);
}
}
::view-transition-old(name-of-my-keyframe-animation) {
animation: 0.3s name-of-my-keyframe-animation;
}
обычно если это некоторый цикл статей в начале каждой статьи размещают ссылки на все
Вы всё ещё устанавливаете display:none по таймауту? Тогда мы идём к вам