Comments 37
:-webkit-details-marker
Очень кроссбраузерно.
И как анимировать?
details[open] .dropdown-menu {
animation: slide .3s ease-in-out;
}
@keyframes slide {
0% {opacity: 0; transform: translate(0, -10px); }
100% {opacity: 1; transform: translate(0, 0);}
}
Очень кроссбраузерно
В лисе (70.0.1) работает.
В сафари тоже.
Автор подлампичить успел, пруфов не будет.
Большая куча -webkit-штук в лисе-таки работает. Например, -webkit-background-clip: text в связке с -webkit-text-fill-color: transparent. Но этому конкретному псевдоэлементу (как и его товарищам по оформлению нативных контролов) не так повезло, да.
Префикс -moz фактически остался только у тех самых деталей реализации (для новых свойств все браузеры дружно отказались от префиксов в пользу флагов), но да, по-видимому всё решает баланс востребованности фичи и легкости реализации. Для стилизации скроллбаров ребята из Мозиллы не поленились написать с нуля целую новую спеку, лишь бы не перенимать ::-webkit-scrollbar и т.п.
Справедливости ради, префикс -webkit- во многих случаях давно перестал быть "вендорским", так что его наличие – еще не показатель некроссбраузерности (нестандартности – пожалуй, да). А с нативными контролами по части CSS-оформления вообще традиционно всё очень плохо, и без браузероспецифичных костылей можно будет обойтись очень нескоро...
Знакомьтесь, <details>
Уже достаточно давно знакомы и активно и плодотворно сотрудничаем :)
Вот недавно статья была на эту же тему: https://m.habr.com/ru/post/465623/
Спасибо большое за статью в любом случае)
И чем плох метод с переключением классов?
Производительность хуже. Вы должны самостоятельно реализовывать функционал который уже встроен в браузеры. То есть лишние стили, лишние скрипты лишняя работа для браузера. В некоторых случаях браузеру сложнее пересчитать шаблон и перерисовать страницу. При использовании встроенного элемента браузер знает о его возможностях и может более эффективно отрисовать страницу.
Реализация не всегда настолько хороша. Скажем, вы задумывались о том, что контрол, по клику на который должен переключиться класс должен реагировать не только на клик мышкой, тап по экрану но и на клавиатуру? Задумывались о том, что он должен быть доступен при проходе табуляцией? Конечно, если для этого использовался
<button>то всё более менее хорошо, но ведь очень часто используют какой-либо другой элемент, который только выглядит как кнопка, скажем
<span class="btn">
И это ужасно. Ведь, если не используете мышь, то вы никогда не сможете использовать этот контрол. При использовании встроенных элементов вам о таких вещах думать не нужно. Об этом позаботятся браузер и ОС.
Семантика и контекст. Если вы воспринимаете страницу не визуально (как это делают многие люди и абсолютно все боты и программы) то для вас крайне важно понимать контекст. Для вас
<div>или<span>не говорят ничего. Даже<button>— это просто кнопка без привязки к чему либо.<details>же указывает на то, что это интерактивный элемент, у которого есть оглавление и при желании можно раскрыть детали. Конечно есть aria-атрибуты, но далеко не многие разработчики об этом задумываются. Даже мои примеры сделаны не лучшим образом с точки зрения семантики. На эту тему советую посмотреть доклад "Семантика для циников, Вадим Макеев"
Производительность хуже.
Давайте конкретнее. Производительность хуже если одновременно открывать и закрывать 1 000 000 html элементов? на обычных сайтах это будет незаметно.
То есть лишние стили, лишние скрипты лишняя работа для браузера.
То же самое я вижу и в вашем примере. Лишние стили чтобы взаимодействовать с иконкой.
details[open] summary:before {
content: '\f146';
}
и опять же чем тогда данный CSS селектор будет отличатся от .details.open? :)
Задумывались о том, что он должен быть доступен при проходе табуляцией?
Семантика и контекст.
В обоих случая согласен. Есть важна семантика то данный тег отлично вписывается.
Говоря про производительность я говорю вот про что.
Возьмём для примера простой код:
<div class="details">
<span class="summary">Details</span>
<p class="hidden">Lorem ipsum dolor sit amet consectetur adipisicing elit. Optio temporibus aliquam at tempora repellat consectetur eos voluptate facilis tempore obcaecati laborum animi sunt, rem quis. Dolore, ipsa. Tempora, soluta quaerat!</p>
</div>document.querySelector('.summary').onclick = () =>
document.querySelector('.details > p').classList.toggle('hidden')Браузер должен:
- Скачать несколько байт JavaScript кода.
- Спарсить его.
- Скомпилировать.
- Найти элемент .summary в дом дереве.
- Повесить на него обработчик событий.
- Держать его в памяти.
- По клику найти в дом дереве целевой элемент .details.
- Изменить в нем набор классов.
- Пересчитать для этого элемента стили.
- Пересчитать стили для всей страницы.
- Заново отрисовать страницу.
В случае использования встроенных элементов, браузеру нужно всего-то
- Пересчитать для этого элемента стили.
- Пересчитать стили для всей страницы.
- Заново отрисовать страницу.
Я понимаю, что разница мизерная. Но Великое берёт начало с малого.
Ну и, понятное дело, что если вы используете какой-нибудь react или vue — в вашу сторону за такие «навешивания» будут коситься.
Нативное решение для достаточно популярного элемента интерфейса — это всегда лучше чем пусть и проверенные временем костыли.
Спасибо, полезно
Что вы имеете в виду? С точки зрения CSS это абсолютно стандартный html тег.
Как выяснили выше в комментах, "для разных браузеров" они и не нужны, только для Chrome и Safari. В Firefox треугольник у summary – обычный маркер списка, и убирается штатно через list-style: none или display: block (вместо дефолтного list-item).
К сожалению, оформление встроенных браузерных контролов ("виджетов", как их называют в спеке) – всё еще одна из самых больных тем в верстке. Но есть надежда, что в обозримое время это изменится...
Спасибо! Очень полезная штука!
Знакомьтесь, <details>