Вакансия фронтендера: hh.ru/vacancy/105805840?from=employer&hhtmFrom=employer В основном фронтент пишем на ангуляре, но от кандидатов в первую очередь ждем хороших знаний о вебе. Ангуляр можно изучить уже будучи в штате. Но есть еще и небольшая вакансия на реакте: hh.ru/vacancy/105450865?from=employer&hhtmFrom=employer Также есть много других айтишных вакансий: hh.ru/employer/6591 Телеграм: t.me/howToLearnIT 0:00 В чем суть? 1:11 CSS-переменные как великое благо 1:40 Проблема цветовой палитры 5:10 Компонентные CSS-переменные 6:51 CSS-переменные как связь между JS и CSS 7:27 Кастомный нативный Checkbox 9:10 Кастомный нативный Radio 9:30 Кастомный нативный Toggle 9:52 Кастомный нативный Chip 11:17 Кастомный нативный Input File 12:22 Могущественный :has 13:30 Popover API 15:25 Кастомный нативный Scrollbar 16:38 CSS Scroll Snap 17:00 Position Sticky 17:30 Scroll Driven Animation 17:40 Главный инсайт Ссылки: 1. Гайд: проектируем систему цветов. Всё про styles, tokens, variables: habr.com/ru/articles/781082/ 2. Петр Жемчугов на Holy.js th-cam.com/video/iPorpGwVDws/w-d-xo.html 3. Основные принципы маскирования в CSS habr.com/ru/companies/ruvds/articles/729974/ 4. Ролик о ViewTransition API th-cam.com/video/jeVNN3mFxOA/w-d-xo.html #css #html #frontend #javascript
Я хз откуда столько скептических комментариев, но я полностью поддерживаю тебя, автор! Я задолбался работать с челами, которые не могут в верстку и семантику. Очень крутой выпуск. Все по делу пусть и с некоторой субъективностью, но с основным вектором согласен. Давай больше такого)
Может потому что дебилоиды-манагеры загоняют людей в степь, к которой у них совсем душа не лежит, или просто мозги устроены по-нормальному а грибы они не употребляют?
@@pOdhTNbbI, я не придумал эти правила, а подсмотрел их у мировой элиты разработки web-ориентированного ПО. Просто так совпало, что я с ними полностью согласен)
Интерфейсы усложняются, HTML и CSS развиваются. И действительно, разработчиков, которые хорошо знают HTML, CSS и браузерные API очень мало, что в итоге сказывается на качестве пользовательских интерфейсов. И это я ещё молчу о семантике, валидности и доступности. Например, в видео автор использует атрибут role с несуществующими значениями, не валидный элемент chip и кастомные атрибуты (сори за духоту). Кажется, пора разделять роли UI-разработчика и JS-разработчика. Первые специализируются на HTML, CSS, SVG, UI, доступности, веб-компонентах, браузерных API, тесно работают с дизайном и разрабатывают UI kit. А вторые специализируются на JavaScript, Typescript, фреймворках, стейт-менеджменте, архитектуре, паттернах, API, работают над логикой и не занимаются ненавистной им вёрсткой. Кажется, от этого все только выиграют. Кроме, разве что, работодателей, которые за одну ЗП хотят фуллстека-мастера на все руки.
@@Spider0444 да, где-то такое разделение есть, но в целом практика не распространённая. Многие относятся к верстальщикам скептически, как к чему-то не серьёзному. На мой взгляд пора уйти от термина "верстальщик" к "UI-разработчик" или "UI-инженер". Потому что UI - это не только про вёрстку, это про более широкий круг навыков, которыми неплохо обладать, чтобы делать хорошие интерфейсы.
@@alexnozer Кто и где скептически относится? Зумерки в околопрограммистских пабликах, трушные бородатые программисты? У нас в компании это полноценная роль в этапе разработки. Никому и в голову не придет обозвать верстальщика несерьезным/неполноценным. Я провожу по 2-3 собеседования в неделю по верстке и могу с уверенностью сказать: хорошего верстальщика днем с огнем не сыскать. Зато сколько я вижу недофронтендеров, с гордыми React/Redux в CV, которые не то что гриды, а флексы нормально не знают. Вот к таким отлично подходит определение "неполноценный".
@@Spider0444 рад видеть единомышленников. На самом деле круто, что у вас в компании такой подход, за это респект! Современный фронтенд сильно перекосило в сторону JS и фреймворков, а на знания веб-платформы многие забивают.
да с 2024 нужно возвращать верстальщиков сейчас ещё новые свойства завезут те кто перейдут на верстальщиков будут делать вещи лучше проблема только в том что заказчик нищий и покупает бутстрап а через год узнаёт после аудита за 20к что бутрап юзать было нельзя и к нему целый год небыло трафика из -за бустрапа и пенальти на гугле и теперь нужно все делать заново . работодатель ничего не выигрывает - он создает порожняк и клиенты уходят потом в апатию. Ко мне приходят заказчики после этих контор и там у них отбивает вообще заниматься сайтом. Т.е. шляпа конторы вызывают отток покупателей
role - это специальный атрибут из стандарта ARIA, который создан для расширения HTML и улучшения доступности сайтов и приложений для людей с ограничениями здоровья. "chip" и "toggle" являются не валидными значениями role, это упущение со стороны автора видео. Вместо "toggle" стоило применить валидную и существующую роль "switch", а "chip" не стоило использовать вовсе, семантики чекбокса/радио хватило бы. Элемент в стандартном HTML является не валидным, в названии кастомных элементов должен быть как минимум один дефис, как это показано в . В свою очередь кастомные элементы (веб-компоненты) - это стандарт, который позволяет создавать свои теги и наделять их логикой.
Ну тут стоит разделять стандарт и то как работают браузеры). И уж в в плане HTML и CSS браузеры очень часто отходят от стандарта. Посмотрите к примеру как реализован атрибут autocomplete у инпутов. Спойлер: не по стандарту. В реальности я могу использовать кастомный тег chip во всех современных браузерах и это абсолютно валидно, если я принимаю риск создания в будущем нативного тега chip. В нашем ките мы конечно используем префикс библиотеки через дефис, но мне хотелось подчеркнуть, что можно сделать прям совсем нативно. То же самое с role. Да chip и toggle в списке доступных значений нет, но это не значит, что я не могу задавать то что захочу. Да, пусть скринридеры тут их не считают, но мне это и не нужно. А нужно мне сделать селектор с помощью которого я бы мог чекбокс отличать от тоггла и от чипсы. И тут вы не правы, что семантики чекбокса и радио хватило. Нет не хватило бы) И атрибут role тут просто отлично подходит по своему смыслу: назначать роли элементам. В ките мы конечно разделяем их с помощью директив, но опять таки хотелось показать более нативный вариант
@@Howtogoitкатегорически с вами не согласен. > Ну тут стоит разделять стандарт и то как работают браузеры). А почему мы должны это разлелять? Стандарты для того и пишутся, чтобы разработчики браузеров по ним внедряли фичи. В целом так и происходит. Пример, когда каждый делал как хотел, известный как Браузерные Войны, прекрасно показал, к чему приводит игнорирование стандартов. А проекты вроде Web Platform Tests и Interop идут полным ходом и задача их - совместимость со стандартами у разных браузеров. Да, бывают баги и некоторые расхождения, но в целом базу стараются делать по стандартам. > Посмотрите к примеру как реализован атрибут autocomplete у инпутов. Если вы про значение off и игнорирование браузером, то это по стандарту. Если внимательно смотреть описание, то off не выключает автокомплит как таковой, а выключает определённый тип подсказок и оставляет за браузером право предлагать другие значения. А остальные значения в целом работают как описано. > В реальности я могу использовать кастомный тег chip во всех современных браузерах и это абсолютно валидно Можете. Более того, вы можете делать много чего другого, что будет работать. Но это потому что HTML очень толерантный язык и много чего допускает, а не потому что так можно. Проверьте пример с chip и role в валидаторе. chip будет объектом HTMLUnknownElement в DOM. Ничего не произойдёт, в HTML вряд-ли такой элемент добавят. Но это не правильно. А на мой взгляд профессиональный разработчик уважает стандарты и валидирует разметку. > мне хотелось подчеркнуть, что можно сделать прям совсем нативно Я вашу идею понял. В примере с файловый инпутом вы используете , что валидно и нативно. Я бы ожидал увидеть условный вместо . > То же самое с role. Да chip и toggle в списке доступных значений нет, но это не значит, что я не могу задавать то что захочу. Опять же, да, вы можете. Просто потому что нет механизма, который выдал бы ошибку. Браузер скушает как есть, потому что HTML - это не XML с чёткой схемой. Но по стандарту ARIA атрибут role имеет конкретное назначение, определённый список допустимых значений и правила применения. > Да, пусть скринридеры тут их не считают, но мне это и не нужно Вам не нужно. А пользователям всевозможных ассистивных технологий это очень нужно. Для этого role и предназначен. Вот был кастомный свич чекбоксом, ридеры бы озвучили это, а вы переопределили роль и сломали семантику элемента. Это нарушает сразу несколько критериев WCAG, который закреплён на законодательном уровне во многих странах. > А нужно мне сделать селектор с помощью которого я бы мог чекбокс отличать от тоггла и от чипсы. В HTML для этого предусмотрено несколько механизмов, вы можете использовать их: class, data-*, itemprop и itemscope, rel и Custom Elements. Они именно для безопасного расширения HTML. > И тут вы не правы, что семантики чекбокса и радио хватило. Нет не хватило бы) Говоря о семантике в этом контексте, я имею ввиду встроенную семантику элемента для дерева доступности. Чипсы - это группа элементов, в которой можно выбрать один или несколько элементов. Иными словами, это подвид чекбоксов или радиокнопок. Пользователи, которые столкнутся с таким элементом, поймут, что с этим делать и как работает интерфейс. Ну а специальной роли для чипсов в ARIA нет. Можно попробовать использовать кнопки, aria-pressed и aria-roledescription. Но надо тестить на юзерах. > И атрибут role тут просто отлично подходит по своему смыслу: назначать роли элементам. Давайте так: вы сами решили, что это отлично подходит. Я, проводя аудиты доступности, регулярно сталкиваюсь с тем, что разработчики используют ARIA неуместно. И от этого плохо целевым пользователям. На моём опыте, такое потом приходится долго и больно исправлять в больших системах.
Тогда тут продолжу душнить: обертку лучше переименовать с использованием - (например, ), потому что по спецификации HTML так отличаются пользовательские элементы от стандартных)
Какое-то извращение на 1:40, кто так вообще делает ? Делаешь в папке app>styles>theme файлы по типу dark.scss, white.scss и тд. В каждом файле создаёшь класс в котором будут сss переменные, и важно чтобы в каждом файле название переменных было одинаковое. Далее пишешь просто логику которая тебе класс заменяет и всё, никаких медиа запросов, так ещё и добавить можно тему в 3 клика.
@@sakkarem ты не понял, мы создаём класс с переменными, и т.к. переменные одинаковые, мы используем нужные нам цвета через var() , и просто делаем логику которая меняет класс вместо медиа приколов Типа таких классов : .app_dark_theme { --bg-color: #061300; --inverted-bg-color: #e5f5e1; --primary-color: #04bb04; --secondary-color: #04ff04; --inverted-primary-color: #030; --inverted-secondary-color: #014b01; .app_light_theme { --bg-color: #e5f5e1; --inverted-bg-color: #061300; --primary-color: #030; --secondary-color: #014b01; --inverted-primary-color: #04bb04; --inverted-secondary-color: #04ff04; Это уменьшает количество разных переменных, ускоряет добавление новых тем, так ещё и позволяет не придумывать тысячи названий переменных под каждую тему
Разве придумывание названия для переменных цветов это не задача дизайнера? По-моему это логичнее, что именно он придумал палитру цветов и сразу же названия цветов
@@tebesvet ну вообще это же в интересах самого дизайнера, если ему скажут где-то массово поменять цвета ему проще будет сделать если цвета будут через переменные в фигма заданы
По-хорошему конечно да, но на практике еще нормально названных переменных от дизайнеров не видел. Все же называть переменные это наверное больше программистский скилл
Я вот уже +-6 лет работаю, но изучаю HTML и CSS до сих пор. Появляется что-то новое, устаревает старое, новые подходы к решению старых задач, подводные камни, нюансы. Обучение в разработке - непрерывный процесс. Для базового знакомства хватит пары недель и несколько макетов. Для глубокого понимания нужны годы практики и опыта.
какого хрена там вообще ремы? зачем 1рем равен 16 пикселям? не проще ли было определить что 1рем это один пиксель? долой костыли в цсс программировании!
Есть странные кодовые базы, где люди зачем-то изменяют код так, чтобы 1rem был равен 1px. Так можно сделать, но это выглядит так же странно, как и создание картинок с помощью css, а не графических редакторов...
@@eugeneturenko3946 ну если им прям так хочется использовать ремы то использование одного пикселя в качестве одного рема имеет смысл в том что тебе не приходится высчитывать сколько рёмов в 10 пикселях и не приходится писать длинные дроби чтобы добиться успеха
@@tebesvetа вы попробуйте в настройках браузера изменить размер шрифта на сайте где основной единицей являются "px". А потом примените эти изменения на сайте где вместо "px" основной единицей измерения является "rem". И вы сразу всё увидите.
я посмотрел верстку на реакте с компонентами и глаза мои плакали кровью победив html в прод вышло тысяча спецов которых можно поместить только в мусорную корзину все фреймворки и весь js в 2024 должен работать на сss переменных , поэтому вью и реакт тормоза
Усложнили работу на ровном месте. Написал clr-1, clr-2 и держишь открытый globals при необходимости. А тут в геометрической прогрессии с этой вашей системой переменные начнут расти и все чтобы было удобно 😂
Во-первых, в CSS можно. Во-вторых, сможет ли на текущий момент нейросеть сверстать достойно даже простенький макет из Фигма? Ответ: нет не сможет. Сможет ли она написать CRUD, если ей скормить описание? Да, сможет, причем на любом языке, да еще и интеграционные тесты сразу напишет. Верстальщики - это программисты, но не совсем привычные, они скорее UI-разработчики.
ПСБ - это тот банк, который отжал на оккупированных украинских территориях местный банк, который до этого отжал украинские банки? Вот, что мы называем рекурсией. Ну и чувак, - такая себе реклама банка, если честно :)
дурной тон - это когда на экране постоянно эта кнопка вот google тоже любитель сделать дурной тон и прячет эту кнопку глубоко в меню что тоже является грубой ошибкой
Ты уже выбрал тему своего устройства в системных настройках. Меня вот раздражает, когда приложение раскрашивается само по себе в темную тему, хотя я люблю светлую и мне приходится искать где тему переключить. Я уже выбрал один раз светлую тему и хочу чтобы мне ее везде показывали.
@@Howtogoit т.е. тот случай, когда нравится системная X тема и не нравится как выглядит X тема у конкретного сайта, ты считаешь не реальным? Можно делать по умолчанию системную тему, но еще и дать пользователям выбор
@@dmitrychurkin4077 А ты зачем пишешь это? Тоже чтобы самоутвердиться? Тебе стоит узнать лексическое значение слова "опечатка". Кому то надо подучить русский 😉
Вакансия фронтендера:
hh.ru/vacancy/105805840?from=employer&hhtmFrom=employer
В основном фронтент пишем на ангуляре, но от кандидатов в первую очередь ждем хороших знаний о вебе.
Ангуляр можно изучить уже будучи в штате.
Но есть еще и небольшая вакансия на реакте:
hh.ru/vacancy/105450865?from=employer&hhtmFrom=employer
Также есть много других айтишных вакансий:
hh.ru/employer/6591
Телеграм:
t.me/howToLearnIT
0:00 В чем суть?
1:11 CSS-переменные как великое благо
1:40 Проблема цветовой палитры
5:10 Компонентные CSS-переменные
6:51 CSS-переменные как связь между JS и CSS
7:27 Кастомный нативный Checkbox
9:10 Кастомный нативный Radio
9:30 Кастомный нативный Toggle
9:52 Кастомный нативный Chip
11:17 Кастомный нативный Input File
12:22 Могущественный :has
13:30 Popover API
15:25 Кастомный нативный Scrollbar
16:38 CSS Scroll Snap
17:00 Position Sticky
17:30 Scroll Driven Animation
17:40 Главный инсайт
Ссылки:
1. Гайд: проектируем систему цветов. Всё про styles, tokens, variables:
habr.com/ru/articles/781082/
2. Петр Жемчугов на Holy.js
th-cam.com/video/iPorpGwVDws/w-d-xo.html
3. Основные принципы маскирования в CSS
habr.com/ru/companies/ruvds/articles/729974/
4. Ролик о ViewTransition API
th-cam.com/video/jeVNN3mFxOA/w-d-xo.html
#css #html #frontend #javascript
А что толку постить вакансии, если на том конце все равно сидит рекрутер, который без посторонней помощи java от javascript не отличит?
Я хз откуда столько скептических комментариев, но я полностью поддерживаю тебя, автор! Я задолбался работать с челами, которые не могут в верстку и семантику. Очень крутой выпуск. Все по делу пусть и с некоторой субъективностью, но с основным вектором согласен. Давай больше такого)
Может потому что дебилоиды-манагеры загоняют людей в степь, к которой у них совсем душа не лежит, или просто мозги устроены по-нормальному а грибы они не употребляют?
Может недалекие манагеры заставили заниматься этим людей, у которых мозги под другое заточены?
Как хорошо что На моей работе верстают верстальщики, а я пишу логику
Этот ролик должны увидеть все!!!! Это просто великолепие! Осталось только научиться применять это всё правильно в проектах!
Спасибо огромное!!!!!!
CSS и HTML - это основа, без которой ни один js-разработчик не может по праву назвать себя фронтендером.
@@pOdhTNbbIа этот кит будет писать и поддерживать? Бекендеры?
@@pOdhTNbbI, касаться или не касаться - это зависит от специфики проекта. Но если из набора знаний только JS, то перед вами не front-end разработчик.
@@pOdhTNbbI, я не придумал эти правила, а подсмотрел их у мировой элиты разработки web-ориентированного ПО. Просто так совпало, что я с ними полностью согласен)
@@pOdhTNbbI, "вы просто поверьте, а поймёте потом")
@@pOdhTNbbI говоришь как джун
С возвращением!
Ура))) Вас не хватало!🤩
Красава! Давай ещё🎉
Интерфейсы усложняются, HTML и CSS развиваются. И действительно, разработчиков, которые хорошо знают HTML, CSS и браузерные API очень мало, что в итоге сказывается на качестве пользовательских интерфейсов. И это я ещё молчу о семантике, валидности и доступности. Например, в видео автор использует атрибут role с несуществующими значениями, не валидный элемент chip и кастомные атрибуты (сори за духоту).
Кажется, пора разделять роли UI-разработчика и JS-разработчика. Первые специализируются на HTML, CSS, SVG, UI, доступности, веб-компонентах, браузерных API, тесно работают с дизайном и разрабатывают UI kit. А вторые специализируются на JavaScript, Typescript, фреймворках, стейт-менеджменте, архитектуре, паттернах, API, работают над логикой и не занимаются ненавистной им вёрсткой. Кажется, от этого все только выиграют. Кроме, разве что, работодателей, которые за одну ЗП хотят фуллстека-мастера на все руки.
Так в нормальных конторах есть такое разделение, у нас верстальщики занимаются версткой, а фронтендры программированием, все довольны.
@@Spider0444 да, где-то такое разделение есть, но в целом практика не распространённая. Многие относятся к верстальщикам скептически, как к чему-то не серьёзному. На мой взгляд пора уйти от термина "верстальщик" к "UI-разработчик" или "UI-инженер". Потому что UI - это не только про вёрстку, это про более широкий круг навыков, которыми неплохо обладать, чтобы делать хорошие интерфейсы.
@@alexnozer Кто и где скептически относится? Зумерки в околопрограммистских пабликах, трушные бородатые программисты? У нас в компании это полноценная роль в этапе разработки. Никому и в голову не придет обозвать верстальщика несерьезным/неполноценным.
Я провожу по 2-3 собеседования в неделю по верстке и могу с уверенностью сказать: хорошего верстальщика днем с огнем не сыскать. Зато сколько я вижу недофронтендеров, с гордыми React/Redux в CV, которые не то что гриды, а флексы нормально не знают. Вот к таким отлично подходит определение "неполноценный".
@@Spider0444 рад видеть единомышленников. На самом деле круто, что у вас в компании такой подход, за это респект! Современный фронтенд сильно перекосило в сторону JS и фреймворков, а на знания веб-платформы многие забивают.
да с 2024 нужно возвращать верстальщиков
сейчас ещё новые свойства завезут
те кто перейдут на верстальщиков будут делать вещи лучше
проблема только в том что заказчик нищий и покупает бутстрап
а через год узнаёт после аудита за 20к что бутрап юзать было нельзя и к нему целый год небыло трафика из -за бустрапа и пенальти на гугле и теперь нужно все делать заново .
работодатель ничего не выигрывает - он создает порожняк и клиенты уходят потом в апатию. Ко мне приходят заказчики после этих контор и там у них отбивает вообще заниматься сайтом.
Т.е. шляпа конторы вызывают отток покупателей
Sucsess однозначно!
ну всё, ждем курс по html & css лично от тебя
Как хорошо, что я не фронтендер)
А можно подробнее насчет значений "chip" и "toggle" для аттрибута role? И почему мы используем кастомный тег для обертки вместо div или label?
role - это специальный атрибут из стандарта ARIA, который создан для расширения HTML и улучшения доступности сайтов и приложений для людей с ограничениями здоровья. "chip" и "toggle" являются не валидными значениями role, это упущение со стороны автора видео. Вместо "toggle" стоило применить валидную и существующую роль "switch", а "chip" не стоило использовать вовсе, семантики чекбокса/радио хватило бы.
Элемент в стандартном HTML является не валидным, в названии кастомных элементов должен быть как минимум один дефис, как это показано в . В свою очередь кастомные элементы (веб-компоненты) - это стандарт, который позволяет создавать свои теги и наделять их логикой.
Ну тут стоит разделять стандарт и то как работают браузеры).
И уж в в плане HTML и CSS браузеры очень часто отходят от стандарта. Посмотрите к примеру как реализован атрибут autocomplete у инпутов.
Спойлер: не по стандарту.
В реальности я могу использовать кастомный тег chip во всех современных браузерах и это абсолютно валидно, если я принимаю риск создания в будущем нативного тега chip. В нашем ките мы конечно используем префикс библиотеки через дефис, но мне хотелось подчеркнуть, что можно сделать прям совсем нативно.
То же самое с role. Да chip и toggle в списке доступных значений нет, но это не значит, что я не могу задавать то что захочу.
Да, пусть скринридеры тут их не считают, но мне это и не нужно. А нужно мне сделать селектор с помощью которого я бы мог чекбокс отличать от тоггла и от чипсы. И тут вы не правы, что семантики чекбокса и радио хватило. Нет не хватило бы)
И атрибут role тут просто отлично подходит по своему смыслу: назначать роли элементам.
В ките мы конечно разделяем их с помощью директив, но опять таки хотелось показать более нативный вариант
@@Howtogoitкатегорически с вами не согласен.
> Ну тут стоит разделять стандарт и то как работают браузеры).
А почему мы должны это разлелять? Стандарты для того и пишутся, чтобы разработчики браузеров по ним внедряли фичи. В целом так и происходит. Пример, когда каждый делал как хотел, известный как Браузерные Войны, прекрасно показал, к чему приводит игнорирование стандартов. А проекты вроде Web Platform Tests и Interop идут полным ходом и задача их - совместимость со стандартами у разных браузеров. Да, бывают баги и некоторые расхождения, но в целом базу стараются делать по стандартам.
> Посмотрите к примеру как реализован атрибут autocomplete у инпутов.
Если вы про значение off и игнорирование браузером, то это по стандарту. Если внимательно смотреть описание, то off не выключает автокомплит как таковой, а выключает определённый тип подсказок и оставляет за браузером право предлагать другие значения. А остальные значения в целом работают как описано.
> В реальности я могу использовать кастомный тег chip во всех современных браузерах и это абсолютно валидно
Можете. Более того, вы можете делать много чего другого, что будет работать. Но это потому что HTML очень толерантный язык и много чего допускает, а не потому что так можно. Проверьте пример с chip и role в валидаторе. chip будет объектом HTMLUnknownElement в DOM. Ничего не произойдёт, в HTML вряд-ли такой элемент добавят. Но это не правильно. А на мой взгляд профессиональный разработчик уважает стандарты и валидирует разметку.
> мне хотелось подчеркнуть, что можно сделать прям совсем нативно
Я вашу идею понял. В примере с файловый инпутом вы используете , что валидно и нативно. Я бы ожидал увидеть условный вместо .
> То же самое с role. Да chip и toggle в списке доступных значений нет, но это не значит, что я не могу задавать то что захочу.
Опять же, да, вы можете. Просто потому что нет механизма, который выдал бы ошибку. Браузер скушает как есть, потому что HTML - это не XML с чёткой схемой. Но по стандарту ARIA атрибут role имеет конкретное назначение, определённый список допустимых значений и правила применения.
> Да, пусть скринридеры тут их не считают, но мне это и не нужно
Вам не нужно. А пользователям всевозможных ассистивных технологий это очень нужно. Для этого role и предназначен. Вот был кастомный свич чекбоксом, ридеры бы озвучили это, а вы переопределили роль и сломали семантику элемента. Это нарушает сразу несколько критериев WCAG, который закреплён на законодательном уровне во многих странах.
> А нужно мне сделать селектор с помощью которого я бы мог чекбокс отличать от тоггла и от чипсы.
В HTML для этого предусмотрено несколько механизмов, вы можете использовать их: class, data-*, itemprop и itemscope, rel и Custom Elements. Они именно для безопасного расширения HTML.
> И тут вы не правы, что семантики чекбокса и радио хватило. Нет не хватило бы)
Говоря о семантике в этом контексте, я имею ввиду встроенную семантику элемента для дерева доступности. Чипсы - это группа элементов, в которой можно выбрать один или несколько элементов. Иными словами, это подвид чекбоксов или радиокнопок. Пользователи, которые столкнутся с таким элементом, поймут, что с этим делать и как работает интерфейс. Ну а специальной роли для чипсов в ARIA нет. Можно попробовать использовать кнопки, aria-pressed и aria-roledescription. Но надо тестить на юзерах.
> И атрибут role тут просто отлично подходит по своему смыслу: назначать роли элементам.
Давайте так: вы сами решили, что это отлично подходит. Я, проводя аудиты доступности, регулярно сталкиваюсь с тем, что разработчики используют ARIA неуместно. И от этого плохо целевым пользователям. На моём опыте, такое потом приходится долго и больно исправлять в больших системах.
топчик
Ну так то фронтендеры тоже разные есть. Кто то ui компоненты пилит, а кто то магию на условном канвасе исполняет или на d3js.
не css-переменные, а кастомные свойства, открывайте форточку
Тогда тут продолжу душнить: обертку лучше переименовать с использованием - (например, ), потому что по спецификации HTML так отличаются пользовательские элементы от стандартных)
Кастом порождает еще больший рефакторинг
Вот из-за таких Юай китов разработчики и перестают владеть html, css...
Какое-то извращение на 1:40, кто так вообще делает ? Делаешь в папке app>styles>theme файлы по типу dark.scss, white.scss и тд. В каждом файле создаёшь класс в котором будут сss переменные, и важно чтобы в каждом файле название переменных было одинаковое. Далее пишешь просто логику которая тебе класс заменяет и всё, никаких медиа запросов, так ещё и добавить можно тему в 3 клика.
Зачем, если с переменными гораздо проще?
@@sakkarem ты не понял, мы создаём класс с переменными, и т.к. переменные одинаковые, мы используем нужные нам цвета через var() , и просто делаем логику которая меняет класс вместо медиа приколов
Типа таких классов :
.app_dark_theme {
--bg-color: #061300;
--inverted-bg-color: #e5f5e1;
--primary-color: #04bb04;
--secondary-color: #04ff04;
--inverted-primary-color: #030;
--inverted-secondary-color: #014b01;
.app_light_theme {
--bg-color: #e5f5e1;
--inverted-bg-color: #061300;
--primary-color: #030;
--secondary-color: #014b01;
--inverted-primary-color: #04bb04;
--inverted-secondary-color: #04ff04;
Это уменьшает количество разных переменных, ускоряет добавление новых тем, так ещё и позволяет не придумывать тысячи названий переменных под каждую тему
@@НікітаКорчемний-г4ч то есть класс применяется к корневому элементу страницы? Да, хороший подход, надо будет тоже использовать.
@@sakkarem да, пишем функцию для изменения класса и живём без всего этого дроча с медиа запросами
@@НікітаКорчемний-г4ч космос. Спасибо.
Чо с select? пока костылим?
Ждем поддержки selectmenu.
Пока что-то даже в хроме за флагом(
Разве придумывание названия для переменных цветов это не задача дизайнера? По-моему это логичнее, что именно он придумал палитру цветов и сразу же названия цветов
Не надо свою работу перекладывать на дизайнера ;))
чтобы дизанер ui кит нарисовал это уже нужно чтобы в лесу кит умер
@@WERWOLION ну это да)) но если попадется ответственный, то может и повезти
@@tebesvet ну вообще это же в интересах самого дизайнера, если ему скажут где-то массово поменять цвета ему проще будет сделать если цвета будут через переменные в фигма заданы
По-хорошему конечно да, но на практике еще нормально названных переменных от дизайнеров не видел.
Все же называть переменные это наверное больше программистский скилл
Такой вопрос, кто сколько времени удилял html и css?? ибо в интернете есть тенденция говорить что учить эти темы более месяца это глупость!
@@aminasule8024, учить нужно не месяц или год, а до того момента, как пока не научишься эффективно решать рабочие задачи с помощью этих инструментов.
За месяц ты вполне успеешь выучить их на должном уровне. А с остальными нюансами разберешься, когда начнешь писать свои собственные проекты
что бы хорошо верстать сложные интерфейсы нужны годы практики, не слушай теоретиков про недели-месяцы
Я вот уже +-6 лет работаю, но изучаю HTML и CSS до сих пор. Появляется что-то новое, устаревает старое, новые подходы к решению старых задач, подводные камни, нюансы. Обучение в разработке - непрерывный процесс. Для базового знакомства хватит пары недель и несколько макетов. Для глубокого понимания нужны годы практики и опыта.
@@qwertymegaforce9088 думаю, CRUD'ы можно за неделю выучиться писать. HTML, CSS и хорошо верстать - от года.
На 1С переходите, как все нормальные люди
"HTML-программисты"....
PUG
@@WERWOLIONго..но мамонта
Я сюда деградировать пришёл а не вот это всё
какого хрена там вообще ремы?
зачем 1рем равен 16 пикселям? не проще ли было определить что 1рем это один пиксель? долой костыли в цсс программировании!
Есть странные кодовые базы, где люди зачем-то изменяют код так, чтобы 1rem был равен 1px. Так можно сделать, но это выглядит так же странно, как и создание картинок с помощью css, а не графических редакторов...
rem вообще не нужны. Только em и то не всегда (для адаптивности).
@@eugeneturenko3946 ну если им прям так хочется использовать ремы то использование одного пикселя в качестве одного рема имеет смысл в том что тебе не приходится высчитывать сколько рёмов в 10 пикселях и не приходится писать длинные дроби чтобы добиться успеха
@@tebesvet как раз очень нужны. Суть rem в том, чтобы разом изменить размеры всего на странице.
@@tebesvetа вы попробуйте в настройках браузера изменить размер шрифта на сайте где основной единицей являются "px". А потом примените эти изменения на сайте где вместо "px" основной единицей измерения является "rem". И вы сразу всё увидите.
я посмотрел верстку на реакте с компонентами и глаза мои плакали кровью
победив html в прод вышло тысяча спецов которых можно поместить только в мусорную корзину
все фреймворки и весь js в 2024 должен работать на сss переменных , поэтому вью и реакт тормоза
🤡 🤡 🤡
@@chikenmacnugget очередной хи-хи мен использовал свою супер силу
В плане? Что там с вёрсткой не так?
@@Genorred пиксели и пр бред.
Готовые компоненты.
Бутрап.
Таилвинд где не породя. А таилвинд можно юзать только на проекте от 2500к+
автору 12 лет?
Усложнили работу на ровном месте. Написал clr-1, clr-2 и держишь открытый globals при необходимости. А тут в геометрической прогрессии с этой вашей системой переменные начнут расти и все чтобы было удобно 😂
тут он имеет виду проект где больше 100+ цветов
ну если у тебя 2 цвета в проекте то твой вариант норм)
html это не яхык программирования.
Он не умеет считать (2 нельзя прибавить к двум). Верстальщики не программисты.
--sum: calc(2px + 2px);
Получается язык программирования))
Во-первых, в CSS можно. Во-вторых, сможет ли на текущий момент нейросеть сверстать достойно даже простенький макет из Фигма? Ответ: нет не сможет. Сможет ли она написать CRUD, если ей скормить описание? Да, сможет, причем на любом языке, да еще и интеграционные тесты сразу напишет. Верстальщики - это программисты, но не совсем привычные, они скорее UI-разработчики.
PUG это что?
@@tebesvet нет, в css нельзя
@@Howtogoit блять)
ПСБ - это тот банк, который отжал на оккупированных украинских территориях местный банк, который до этого отжал украинские банки?
Вот, что мы называем рекурсией.
Ну и чувак, - такая себе реклама банка, если честно :)
хрюкни
О, соевый вылез).
2:21 нет, дайте пользователю выбор какую тему включать. Дурной тон забрать у пользователя выбор.
дурной тон - это когда на экране постоянно эта кнопка вот google тоже любитель сделать дурной тон и прячет эту кнопку глубоко в меню что тоже является грубой ошибкой
Ты уже выбрал тему своего устройства в системных настройках.
Меня вот раздражает, когда приложение раскрашивается само по себе в темную тему, хотя я люблю светлую и мне приходится искать где тему переключить.
Я уже выбрал один раз светлую тему и хочу чтобы мне ее везде показывали.
@@Howtogoit т.е. тот случай, когда нравится системная X тема и не нравится как выглядит X тема у конкретного сайта, ты считаешь не реальным?
Можно делать по умолчанию системную тему, но еще и дать пользователям выбор
3:40 кому то надо подучить английский)
Вот всегда найдётся умник, решивший самоутвердиться за счёт опечатки. 😉
@@dlazder3937, "кому-то" пишется через дефис)))
@@dmitrychurkin4077 это не опечатка. Опечатка была бы если бы там стояла буква x. А это банальное незнание как пишется слово success
@@dmitrychurkin4077 А ты зачем пишешь это? Тоже чтобы самоутвердиться? Тебе стоит узнать лексическое значение слова "опечатка". Кому то надо подучить русский 😉
Это вообще скрин из статьи habr.com/ru/articles/781082/
И да это просто опечатка. Вы прям как школьник, нашедший опечатку в учебнике ей богу)
4:08 ._.