CSS-live.ru

Главная страница CSS-live.ru

Голограммы, пленочные засветки и шейдеры на чистом CSS

6

Перевод статьи Holograms, light-leaks and how to build CSS-only shaders с сайта robbowen.digital для css-live.ru, автор — Робб Оуэн

Может, я чуть преуменьшаю, но WebGL — это нечто. За пять минут на любом из сайтов, отмечающих лучшие примеры веб-дизайна наградами, можно увидеть, как сайты один за другим полностью полагаются на мощь canvas. Инструменты вроде threejs привносят в браузер мощь 3D и GLSL-шейдеров, а с ними — совершенно новый уровень визуальных эффектов.

Но тут я задумался: почему всё веселье должно доставаться JS? Сейчас, когда браузеры наконец широко поддерживают mix-blend-mode, многие из типовых приемов шейдинга стали доступны и в CSS. С правильным подбором картинок и тщательным их наложением можно создавать удивительно качественные эффекты без нужды в каких-либо JS-зависимостях.

Взглянем на пример. По мере скроллинга картинки ниже солнечный свет вспыхивает тёплым оранжевым, прежде чем уйти в холодную голубизну. На миг вы увидите еще и размытые блики объектива (боке).

CSS-выражения от контейнера для дизайнеров

5

Перевод статьи CSS Container Queries For Designers с сайта ishadeed.com, опубликован на CSS-live.ru с разрешения автора — Ахмада Шадида

При работе над дизайном для веба приходится иметь дело с макетами для разных размеров экрана. Опираясь на эти макеты, разработчик определяет ширину или высоту окна браузера медиазапросами, а затем, исходя из этого, меняет макет. Именно так мы верстали веб последние 10 лет, и вот-вот всё станет еще лучше. У меня для вас хорошие новости.

CSS-выражения от контейнера — долгожданная для веб-разработчиков фича — скоро появится в CSS и с ней уже можно поэкспериментировать в Chrome Canary. В этой статье мы познакомимся с этой фичей поближе, и узнаем, как она повлияет на вашу работу как дизайнера, и не только. Неважно, пишете ли вы код или нет, если увидите какой-то незнакомый CSS, то можете полностью игнорировать его и идти дальше.

Хватит слов, перейдём к делу!

Почему у !important в CSS восклицательный знак в начале?

2

Непостижимые алгоритмы Твиттера принесли мне в ленту занятный вопрос Саймона Хойберга, автора нескольких книг про JavaScript:

Почему ‘!important’ перекрывает значения в css? 🤔

Для меня это читается как «not important», т.е. «не важно», и я ждал бы от него обратного 😅

Действительно, для программистов, привыкших обозначать знаком ! операцию отрицания (инверсии), эта запись выглядит очень нелогично. Ее даже включили в список ошибок, допущенных при проектировании CSS (последний пункт).

И мне вдруг пришел в голову неожиданный ответ на этот вопрос, которым я хочу поделиться. Предупреждаю: это ни разу не официальное определение из спецификации, а скорее полушуточный мнемонический прием, поясняющий эту «странность» и, как мне кажется, помогающий лучше понять и запомнить ее логику.

Не боритесь с каскадом, управляйте им!

3

Перевод статьи Don’t Fight the Cascade, Control It!
с сайта css-tricks.com для css-live.ru. Автор — Мадс Стуманн
.

Если делать всё правильно и использовать наследование, которое даёт CSS-каскад, то конечного CSS нужно будет писать меньше. Но поскольку часто мы загружаем CSS из разных мест — из-за чего его бывает сложно структурировать и поддерживать, — каскад может сильно расстроить, и CSS из-за него окажется больше, чем нужно.

Несколько лет назад Гарри Робертс придумал ITCSS — умный способ структурировать CSS.

В сочетании с БЭМ ITCSS стал популярным способом написания и организации CSS.

Но даже с ITCSS и БЭМ иногда возникают большие трудности с каскадом. К примеру, я уверен, что вам приходилось делать @import внешних CSS-компонентов в определённом месте, чтобы ничего не сломать, или прибегать к жуткому !important.

«Запашки» кода React-компонентов

0

Перевод статьи React component code smells с сайта antongunnarsson.com, опубликован на CSS-live.ru с разрешения автора — Антона Гуннарсона

Это не окончательный вариант статьи, могут быть новые дополнения.

Растущая коллекция того, что я считаю «запашками» кода React-компонентов.

Что такое «запашок» кода? «Запашок» кода — что-то такое, что вроде бы и не ошибка, но может быть признаком более серьезной проблемы в коде. Больше информации в Википедии.

Запашки 💩

Тёмная сторона CSS: выходим за рамки и взрываем звезды с border-image и градиентами

1

Как вы думаете, сколько CSS-градиентов нужно, чтобы нарисовать каждую из этих фигур?

скриншот примера
Один! 🤯 Причем его даже не надо дублировать: достаточно указать один раз в одном-единственном свойстве. Таким примером в CodePen на днях поделился Темани Афиф, автор занятного и познавательного проекта css-challenges.com.

Эта «магия» — заслуга свойства border-image. У нас уже есть статья о нем и его возможностях. Увы, громоздкий синтаксис и неинтуитивное поведение — особенно с градиентами — до сих пор мешают ему стать популярным. Сам Афиф в Твиттере признал, что «border-image принадлежит к тёмной стороне CSS»: очень уж трудно представить себе наглядно, как масштабируются, нарезаются и потом опять масштабируются части картинки. И многие даже не пытаются разобраться в нем. А зря!

Как читать W3C-спецификации

1

Перевод статьи How to Read W3C Specs с сайта alistapart.com для css-live.ru. Автор — Джей Девид Эйсенберг.

(Примечание редакции CSS-live.ru: оригинал статьи написан более 20 лет назад. Не удивляйтесь, это не баг, а фича. Иногда полезно оглянуться назад и увидеть за калейдоскопом новинок какие-то неизменные основы. Или лучше понять ход прогресса технологий и порадоваться ему еще больше. В любом случае, многое в статье актуально по сей день, и уж точно стоит обсудить. Приятного чтения и приобщения к суперсиле спецификаций!)

Консорциум Всемирной паутины — это хранитель спецификаций по всем технологиям в вебе. Как веб-разработчик, вы могли заходить к ним на сайт в поиске ответа на вопрос про XHTML или чтобы узнать больше о новой технологии, такой как «Объекты форматирования XSL» или «Масштабируемая векторная графика»

Итак, вы обращаетесь к спецификации и практически тут же оказываетесь в замешательстве. Это невозможно читать, думаете вы. Но, на самом деле, это читаемо, если учесть один ключевой момент. Но всё проясняется, если учесть одну важную вещь:

Псевдокласс :has() — не только «родительский селектор»

0

Браузер Safari часто ругают за редкое обновление и задержку внедрения новинок, но есть у него «любимые» области, в которых он опережает всех. Например, CSS-селекторы 4 уровня. Псевдоклассы :matches() — теперь это :is(), :not() с несколькими селекторами и :nth-child()/:nth-last-child() c добавочным параметром of <что угодно> он поддерживает с 2015 года. И именно в его экспериментальной сборке появилась первая реализация долгожданного псевдокласса :has()!

О :has() часто говорят как о «родительском селекторе». Но он может быть не только селектором любого предка, но и селектором предыдущего соседа. О его непростой судьбе — задержке из-за проблемы с производительностью, странном ее «решении» (буквально по анекдоту «чтоб игрушки дольше не ломались, не давайте их детям»:) и его отмене, и первых попытках реализовать — распространяться не будем. Лучше сразу посмотрим…

Примеры использования

Укрощаем режимы наложения: difference и exclusion

3

Перевод статьи Taming Blend Modes: `difference` and `exclusion` с сайта css-tricks.com, переведено для css-live.ru с разрешения автора — Аны Тюдор.

До самого 2020-го я не особо увлекалась режимами наложения, во многом потому, что крайне плохо представляла себе будущий результат до того, как попробовать. И этот подход «попробуй и посмотри, что выйдет» почти всегда оставлял меня в ужасе перед тем безобразием, что невольно получалось у меня на экране.

Эта проблема вытекала из незнания механизма их работы. Почти все попадавшиеся мне статьи на эту тему строились на примерах, сравнениях с Фотошопом или многословных художественных описаниях. Примеры бывали великолепны, но без понимания, как работает механизм всего этого, реализация своей творческой задумки путем переделки чужого красивого примера превращается в долгое, мучительное и в конечном итоге бесплодное приключение. А аналогии с Фотошопом практически бесполезны для людей инженерного склада, без дизайнерского опыта. Длинные художественные описания же для меня вообще выглядели каким-то птичьим языком.

Момент просветления случился у меня, когда я наткнулась на спецификацию и нашла в ней математические формулы, по которым работают режимы наложения. Благодаря этому я наконец смогла понять, как это всё работает «под капотом» и где оно может пригодиться. И теперь, узнав это лучше, я поделюсь этим знанием в серии статей.

Сегодня мы рассмотрим, как вообще работает наложение, затем рассмотрим два в чем-то похожих режима наложения — difference и exclusion — и, наконец, доберемся до главной части этой статьи, где разберем несколько классных примеров использования вроде вот таких.

Версия для слабовидящих? А можно не надо? [расшифровка доклада]

2

Всем привет, меня зовут Лена. Сейчас я делаю фронтенд в компании AISA и борюсь за вёрстку кнопок кнопками. В сообществе могу быть известна пока что только тем, что модерирую чат Веб-стандартов в Телеграме. В свободное время катаюсь на разных досках. Ну, и погнали к докладу.

Знаком ли вам такой диалог?

— А вы поддерживаете доступность на своём сайте?
— Да, у нас есть версия для слабовидящих.

Я не один раз встречала подобный ответ в своей практике. Почему-то очень распространено мнение, что чтобы сайт был доступным, нужно внедрить в него версию для слабовидящих.

Нет. Не нужно.

CSS COLORS

1

Диклеймер: в статье нет ничего про браузеры и поддержку, только теория. Статья представляет собой неполный перевод спецификации c некоторыми дополнениями.

Глоссарий

Факт 1: цвет — это не характеристика излучения, это характеристика реакции человеческого мозга на излучение. То есть два излучения с разным спектром могут иметь один цвет с нашей точки зрения.

Факт 2: далеко не все цвета, которые видит среднестатистический человек, можно воспроизвести аппаратными средствами, в том числе с помощью вашего монитора.

Чтобы быть впереди веба, веб-стандартам нужно бежать в два раза быстрее

4

Не секрет, что в последние годы веб развивается крайне стремительно. Периодически выходят новые библиотеки, фреймворки и другие полезные для нас инструменты. Всё это безусловно помогает нам решать повседневные задачи. Но в погоне за популярными новинками мы совсем не обращаем внимание на истоки. Многие начинающие разработчики начинают знакомство с кодом именно с инструментов, а не с фундаментальных вещей. Обычно это связывают с тем, что сегодня подавляющее большинство вакансий для фронтенд-разработчиков напичканы «модными» и «хайповыми» словечками вроде «React», «Vue», «styled-components», и множеством других. Поэтому разработчикам важно изучать именно эти вещи, чтобы не остаться без работы. Но разве причина только в этом? Именно поэтому разработчикам не важны основы? Думаю, что только отчасти.

А в чём, собственно, проблема, и она точно есть?

Убираем сдвиги в верстке наложением в CSS Grid

4

Перевод статьи Prevent layout shifts with CSS grid stacks с сайта www.hsablonniere.com для css-live.ru, автор — Юбер Саблоньер

Люди используют CSS Grid по двум причинам:

  1. CSS — это потрясающе! Факт, как ни крути.
  2. Гриды — отличный инструмент для создания сложных двумерных макетов.

У меня иногда бывает третья причина использовать CSS Grid: предотвратить сдвиги в верстке. Я пытался придумать для этого приема прикольное сокращение, но у меня получилось лишь АСПНГ: «АнтиСдвиговый Прием с Наложением в Гридах». Вряд ли у меня получится похвастаться мастерством в «изобретении технических терминов» в резюме на LinkedIn, так что жду ваших предложений получше.

Давайте я объясню прием на реальных примерах. В этой статье я покажу:

  • Реальную проблему сдвигов в верстке, с которой я столкнулся в работе над одним компонентом.
  • Ограничения решения с абсолютным позиционированием.
  • Преимущества решения с гридом.

Погодите, о каких вообще сдвигах идет речь?

Безумие на чистом HTML + CSS

2

Играми на «чистом CSS» (т.е. без JS) нас уже давно трудно удивить. Но британскому дизайнеру Джейми Коултеру, пожалуй, удалось. Его недавняя работа в Codepen — полноценный квест с сюжетом, в котором игроку нужно выбраться из мрачного подвала то ли больницы, то ли лаборатории, где накануне произошло что-то ужасное. И заодно узнать шокирующую разгадку… в общем, то, что надо на Хэллоуин!

Игрок может перемещаться между локациями и взаимодействовать с окружающими предметами. В некоторых предметах бывает спрятано что-то нужное для дальнейшего прохождения (например, ключ), некоторые — скажем, записки на стенах — содержат полезные подсказки, а ещё есть просто приятные «пасхалки» (например, логотип Codepen и аватарки многих «звезд» фронтенда:). Некоторые предметы совмещают всё вышеперечисленное. И такая проработка мелочей, да и вся атмосфера игры, весьма впечатляет.

Но завсегдатаев Codepen — и нашего сайта — не меньше разгадки сюжета игры занимает другой вопрос:

Как же это сделано?

Несбывшиеся надежды веб-компонентов

12

Перевод статьи The failed promise of Web Components с сайта lea.verou.me, опубликован на CSS-live.ru с разрешения автора — Лии Веру

Веб-компоненты обещали так много новых возможностей для HTML, с ними веб-разработка должна была стать намного доступнее для непрограммистов и легче для программистов. Помните тот восторг от каждого новёхонького HTML-элемента, который реально что-то делал? Помните, как было здорово, когда стало можно делать слайдеры, палитры для выбора цвета, диалоговые окна, раскрывающиеся виджеты прямо в HTML, без необходимости подключать какие-либо библиотеки?

От веб-компонентов ждали такого же удобства, но для намного более широкого спектра HTML-элементов, и гораздо быстрее, поскольку никому не нужно было бы ждать весь цикл стандартизации и реализации. Просто подключим скрипт, и бац — в нашем распоряжении стало еще больше элементов!

По крайней мере, так задумывалось. В какой-то момент пространство успели заполонить фанатики JS-фреймворков, балдеющие от сложных API, заумных процессов сборки и графов зависимостей, похожих на корни дерева баньян.


Вот как выглядят корни дерева баньян. Фото Дэвида Стенли на Flickr (лицензия CC-BY).