Вакансия фронтендера: 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 ruclips.net/video/iPorpGwVDws/видео.html 3. Основные принципы маскирования в CSS habr.com/ru/companies/ruvds/articles/729974/ 4. Ролик о ViewTransition API ruclips.net/video/jeVNN3mFxOA/видео.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; Это уменьшает количество разных переменных, ускоряет добавление новых тем, так ещё и позволяет не придумывать тысячи названий переменных под каждую тему
Я вот уже +-6 лет работаю, но изучаю HTML и CSS до сих пор. Появляется что-то новое, устаревает старое, новые подходы к решению старых задач, подводные камни, нюансы. Обучение в разработке - непрерывный процесс. Для базового знакомства хватит пары недель и несколько макетов. Для глубокого понимания нужны годы практики и опыта.
Разве придумывание названия для переменных цветов это не задача дизайнера? По-моему это логичнее, что именно он придумал палитру цветов и сразу же названия цветов
@@tebesvet ну вообще это же в интересах самого дизайнера, если ему скажут где-то массово поменять цвета ему проще будет сделать если цвета будут через переменные в фигма заданы
По-хорошему конечно да, но на практике еще нормально названных переменных от дизайнеров не видел. Все же называть переменные это наверное больше программистский скилл
какого хрена там вообще ремы? зачем 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
ruclips.net/video/iPorpGwVDws/видео.html
3. Основные принципы маскирования в CSS
habr.com/ru/companies/ruvds/articles/729974/
4. Ролик о ViewTransition API
ruclips.net/video/jeVNN3mFxOA/видео.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к что бутрап юзать было нельзя и к нему целый год небыло трафика из -за бустрапа и пенальти на гугле и теперь нужно все делать заново .
работодатель ничего не выигрывает - он создает порожняк и клиенты уходят потом в апатию. Ко мне приходят заказчики после этих контор и там у них отбивает вообще заниматься сайтом.
Т.е. шляпа конторы вызывают отток покупателей
А можно подробнее насчет значений "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 неуместно. И от этого плохо целевым пользователям. На моём опыте, такое потом приходится долго и больно исправлять в больших системах.
ну всё, ждем курс по html & css лично от тебя
Sucsess однозначно!
Ну так то фронтендеры тоже разные есть. Кто то ui компоненты пилит, а кто то магию на условном канвасе исполняет или на d3js.
не css-переменные, а кастомные свойства, открывайте форточку
Тогда тут продолжу душнить: обертку лучше переименовать с использованием - (например, ), потому что по спецификации 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;
Это уменьшает количество разных переменных, ускоряет добавление новых тем, так ещё и позволяет не придумывать тысячи названий переменных под каждую тему
@@НікітаКорчемний-г4ч то есть класс применяется к корневому элементу страницы? Да, хороший подход, надо будет тоже использовать.
@@sakkarem да, пишем функцию для изменения класса и живём без всего этого дроча с медиа запросами
@@НікітаКорчемний-г4ч космос. Спасибо.
Чо с select? пока костылим?
Ждем поддержки selectmenu.
Пока что-то даже в хроме за флагом(
Такой вопрос, кто сколько времени удилял html и css?? ибо в интернете есть тенденция говорить что учить эти темы более месяца это глупость!
@@aminasule8024, учить нужно не месяц или год, а до того момента, как пока не научишься эффективно решать рабочие задачи с помощью этих инструментов.
уйдет неделя, максимум 2 недели
За месяц ты вполне успеешь выучить их на должном уровне. А с остальными нюансами разберешься, когда начнешь писать свои собственные проекты
что бы хорошо верстать сложные интерфейсы нужны годы практики, не слушай теоретиков про недели-месяцы
Я вот уже +-6 лет работаю, но изучаю HTML и CSS до сих пор. Появляется что-то новое, устаревает старое, новые подходы к решению старых задач, подводные камни, нюансы. Обучение в разработке - непрерывный процесс. Для базового знакомства хватит пары недель и несколько макетов. Для глубокого понимания нужны годы практики и опыта.
Вот из-за таких Юай китов разработчики и перестают владеть html, css...
Разве придумывание названия для переменных цветов это не задача дизайнера? По-моему это логичнее, что именно он придумал палитру цветов и сразу же названия цветов
Не надо свою работу перекладывать на дизайнера ;))
чтобы дизанер ui кит нарисовал это уже нужно чтобы в лесу кит умер
@@WERWOLION ну это да)) но если попадется ответственный, то может и повезти
@@tebesvet ну вообще это же в интересах самого дизайнера, если ему скажут где-то массово поменять цвета ему проще будет сделать если цвета будут через переменные в фигма заданы
По-хорошему конечно да, но на практике еще нормально названных переменных от дизайнеров не видел.
Все же называть переменные это наверное больше программистский скилл
Кастом порождает еще больший рефакторинг
какого хрена там вообще ремы?
зачем 1рем равен 16 пикселям? не проще ли было определить что 1рем это один пиксель? долой костыли в цсс программировании!
Есть странные кодовые базы, где люди зачем-то изменяют код так, чтобы 1rem был равен 1px. Так можно сделать, но это выглядит так же странно, как и создание картинок с помощью css, а не графических редакторов...
rem вообще не нужны. Только em и то не всегда (для адаптивности).
@@eugeneturenko3946 ну если им прям так хочется использовать ремы то использование одного пикселя в качестве одного рема имеет смысл в том что тебе не приходится высчитывать сколько рёмов в 10 пикселях и не приходится писать длинные дроби чтобы добиться успеха
@@tebesvet как раз очень нужны. Суть rem в том, чтобы разом изменить размеры всего на странице.
@@tebesvetа вы попробуйте в настройках браузера изменить размер шрифта на сайте где основной единицей являются "px". А потом примените эти изменения на сайте где вместо "px" основной единицей измерения является "rem". И вы сразу всё увидите.
я посмотрел верстку на реакте с компонентами и глаза мои плакали кровью
победив html в прод вышло тысяча спецов которых можно поместить только в мусорную корзину
все фреймворки и весь js в 2024 должен работать на сss переменных , поэтому вью и реакт тормоза
🤡 🤡 🤡
@@chikenmacnugget очередной хи-хи мен использовал свою супер силу
В плане? Что там с вёрсткой не так?
@@Genorred пиксели и пр бред.
Готовые компоненты.
Бутрап.
Таилвинд где не породя. А таилвинд можно юзать только на проекте от 2500к+
автору 12 лет?
На 1С переходите, как все нормальные люди
"HTML-программисты"....
PUG
@@WERWOLIONго..но мамонта
Усложнили работу на ровном месте. Написал 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 ._.