Comments 38
Сам принцип минимального обращения к JS довольно здравый (т.к. так можно уменьшить количество зависимостей), но судя по caniuse,
summary не поддерживается в Safari
datalist лишь частично поддерживается в Firefox
анимации и переходы в селекторе ::before не поддерживаются в Safari.
Вместе с тем компоненты в модных графических фреймворках могут предоставлять полифилы, немного повышающие шансы, что фича будет работать в различных браузерах.
В отличие от JS с его императивностью, HTML и CSS декларативны. Вы говорите браузеру, что делать, а не как это делать. Это значит, что браузер сам выбирает, как это делать, и может сделать это наиболее эффективным образом.
Не вполне согласен с формулировками. Декларативный язык описывает интерпретатору "что должно получиться", т.е. результат. Императивный язык описывает процесс.
Звучит очень противоречиво. JS явно понятнее среднему человеку, чем очень редкие детали HTLM/CSS. Это сильно бьёт по поддерживаемости. Другой программист может не знать деталей и сделать много косяков или попросту потратить непропорционально много времени.
Я и вправду такое замечал, но не у "средних людей", а у "средних фронтендеров", которые прошли курсы по JS и React после вуза или вместо него и очень боятся, что кто-то напишет что-то не на языке программирования, а на этих верстальщиских странностях типа HTML или CSS.
Гипотеза "JS явно понятнее среднему человеку, чем очень редкие детали HTLM/CSS." Звучит ещё более противоречиво. Тут Многообразие популярных фреймворков против двух линек спецификаций.
Регулярно сталкиваюсь с веб-программистами, которые используют фреймворки, но не могут оперировать даже html в версии 4 и CSS в версии 2.
В итоге даже моих базовых знаний js оказывается достаточно, чтобы понять отсутвие качества в их поделках.
Личные "Уникальные" Или бездумно спертые из выдачи поисковика решения на js и безоглядное использование фреймворков бьют по поддерживаемости решения намного сильнее.
Это согласен, ChatGPT ещё этому помогает.
Недавно наткнулся на использование css-переменной isMobile по ширине 768(вроде). Чтоб потом каждую секунду из JS считывать эту переменную и добавить класс .col-md(да, в этой странице уже был bootstrap, который сам все это умеет на чистом css). Я прежде чем это вырезать, долго сидел в фейспалме.
Говорят людей можно собеседовать. Ещё вроде можно вместо очередной задачи с литкода спросить про специфику проекта в виде требования хорошо знать HTML/CSS
А потом сайт с отключенными скриптами даже не прогружается...
В CSS несколько сотен различных свойств (не считая специфичных применений), а их возможных комбинаций на среднестатистической странице - больше числа атомов во вселенной. Плюс (точнее это минус) глобальная область видимости. Плюс (минус) нюансы поддержки в разных браузерах. Мне понятно почему нормальные люди это недолюбливают.
С другой стороны CSS даёт возможность менять стили сразу для множеств элементов на странице, а не по одному как в JS/DOM. Поэтому там, где нужна консистентность обновлений, альтернатив особо нет.
На практике выбор между CSS и JS не бинарный. Это всегда набор каких-то компромиссов.
Звучит здорово, но ещё нужно дождать полной поддержки у всех основных бровзеров, а потом ещё с годик-полтора, пока большинство обновится (главная боль здесь, конечно, сафари)
А до тех пор, продолжаем костылять css-modules, вьюшные scoped-стили, styled-components и чёрт знает что ещё...
Ну не знаю... По-моему, тут ситуация как и с JS - со временем на эти технологии начинают наваливать задачи, под которые они совершенно не задумывались. И соответственно "допиливать" эти технологии.
Откуда вдруг возникла потребность язык оформления превратить в полноценный ЯП? Ну что за современная привычка из всего лепить комбайны?
Я пишу на Вью. Но я никогда не использую изолированные стили. Я не вижу в этом никакого профита, наоборот - только бессмысленное усложнение. Все стили у меня хранятся... в папке /css. Только не начинайте про "переиспользование компонентов"))
Точно такая же история была с препроцессорами - сколько же я холиварил на эту тему, сколько в меня тухлых овощей летело. Ну вот вроде истерия/мода потихоньку пошла на спад. Внезапно оказалось, что "ванильного css" хватает за глаза))
CSS-in-JS - та же фигня!..
БЭМ - вот тут есть здравое зерно, но почему-то начисто было отброшено понятие "специфичности" и почти отброшено понятие "каскада".
Основная трудность освоения CSS - это то, что технология на первый взгляд кажется слишком примитивной чтобы глубоко в неё вникать. Ну, например, многие даже не понимают такую основополагающую концепцию как "поток". Ну и в итоге "ай... в этом чёрт ногу сломит, лучше на js значение посчитаю".
Плюс (точнее это минус) глобальная область видимости.
БЭМ спасает.
Согласен с вами, но справедливости ради, CSS - сам по себе вызывает facepalm у настоящего программиста. Как можно было там сразу не сделать переменные? Явное наследование? Зачем сгородили свой синтаксис, а не взяли JSON или хотя бы XML? И многое другое. Я уже более 10 лет в веб-разработке, до сих пор CSS страшно бесит.
"Гладко было на бумаге, но забыли про овраги" (с)
appearanceприказывает браузеру не делать этого.
*рекомендует
И, собственно, на этом главу про стилизацию элементов форм можно заканчивать))
CMV: это штука работает до тех пор пока нам не надо сделать шаг влево/вправо.
Например не понятно как этот datalist (который у меня в фф не заработал, кстати) предполагает загрузку опций с сервера при открытии окна.
Или вот жульничанье с диалоговыми окнами - по факту автор говорит нам заменить часть технологий в фиче на другую технологию просто ради... чего? Если мы уже используем жс, то проще на нем и сделать это окно и иметь полный контроль над ним, нежели создавать франкенштейна, нет?
---
В программировании очень много усилий тратится на то, чтобы подстелить себе соломки для будущих изменений. Мы выносим из кода константы, пишем универсальные функции вместо специфичных - всё, чтобы поднять кастомизируемость кода. И привязка к АПИ браузеров выглядит как шаг назад.
Модальные окна тоже можно без Javascript, посмотри DaysiUI способ с label + checkbox. Есть только один недостаток: если при загрузке страницы модальное окно будет помечено сразу открытым, то оно появится с небольшой задержкой, собственно поэтому DaysiUI объявили его legacy и используют метод с js.
Всё из этой статьи плюс HTMX, и мы получаем непобедимый стек для большинства проектов
Мысли правильные, но это всё ломается об реалии продуктовой разработки.
Используя нативные решения вы создаете себе зависимость от браузера, и как только вы упретесь в новые продуктовые требования, или новый дизайн, и браузера на это не хватит, вам придется или вводить продуктовые ограничения, или полностью изменять решение.
Поэтому там где можно, да, можно использовать, но надо анализировать риски возникновения технических блокеров об нативные механики.
А смысл этого, когда все гиганты используют свистоперделки в виде jQuery, Nodejs, питон и тд и тп?
Хоть как сделай, все равно сайты будут использовать js, если только чистый свой сайт делать, но смысл, когда один твой сайт будет ракета, а остальные все равно же тоже надо грузить
Этот быстрый сайт(сайты) будет как капля в океане
Чтобы сделать диалог с формой тоже не нужен жс
.mydialog{display: none; position: fixed}
.mycheckbox:checked + .mydialog{display: block}Первый пример просто не соответствует спецификации:
см. разрешенный контент https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#technical_summary
для недоверчивых см. Content Model https://html.spec.whatwg.org/multipage/input.html#the-input-element
и древнючий вопрос https://stackoverflow.com/questions/2587669/can-i-use-a-before-or-after-pseudo-element-on-an-input-field
Но в целом поддерживаю, я в таких случаях скрываю инпут и за ним кладу span или svg и селектором + контролю его
"Всё шло хорошо, пока за день до сдачи проекта, менеджер не попросил вот здесь добавить вот такой слайдер..."
Ну вот при вменяемой "архитектуре лэйаута" (я так это называю) с этим не будет вообще никаких проблем.
А вот когда вы будете с одной стороны ограничены бустраповским margin: 0 -30px !important; а с другой инлайновыми стилями из JS - да, проблемы могут начаться))
Помните картинку про MS Word - "Нахрена вот это всё?" :)))
А известный мем про "теперь у нас 15 стандартов"? :)))
Вот это вот именно про то. У нас и так HTML+JS+CSS+<надцать высокостандартизованных фремворков>
Я вижу предложение "добавить ещё один стандарт" :D
P.S. Замечу, что первые три компонента ДО СИХ ПОР не полностью унифицированы по браузерам :D
Это конечно хорошо и прекрасно, только как мне взаимодействовать с сервером на CSS?
А вот еще один доклад ровно на ту же тему
Вам не нужен для этого JavaScript