#статья дня
#js #esnext

Леа Веру (Lea Verou) рассказала о своём опыте рефакторинга большой кодовой базы с приходом опциональной последовательности (опциональный доступ к атрибутам, optional chaining) в широкий доступ.

Если коротко, это безумно удобно, как всегда присутствуют парочка неочевидных трюков, но отстрелить себе ногу тоже весьма просто.

https://lea.verou.me/2020/06/refactoring-optional-chaining-into-a-large-codebase-lessons-learned/

#статья дня
#css

И снова на сцене Ахмад Шадид (Ahmad Shadeed). На сей раз с “нетипичными” CSS-свойствами.

Сразу скажу, на мой взгляд все свойства более чем типичны. Дело тут в другом: они почему-то оказались в тени модных фишек или просто по какой-то причине прошли мимо (как object-fit, некоторым сложно составить правильный поисковый запрос, чтобы узнать о нём).

https://ishadeed.com/article/uncommon-css/

Вообще, хороший автор. Видно, что он в начале очень эффективного пути.

#css

Наглядное отличие алгебры от теории алгоритмов.

На КДПВ — паттерн и его алгебраическое решение.

В тексте ниже — аналогичный CSS:

li:nth-child(6n+4),
li:nth-child(6n+5),
li:nth-child(6n+6) {
color: red;
}

Выводов не будет, в тред приглашаются математики :)

Статья переехала 👇

#css #fonts #шрифты

Очень часто в коде многих верстальщиков я наблюдаю примерно следующее:

font-weight: normal;
font-family: BrutalType-Bold, sans-serif;

Кажется, не все люди понимают, что же такое @font-face и с чего начать подключение шрифтов. Давайте разбираться.

Статья слишком длинная для канала, поэтому прочесть её можно на Телеграфе: https://telegra.ph/CHto-takoe-font-face-07-16

#js #es #esnext #webpack #twitter

Отличный тред Андрея Ситника о том, что же не так в мире ES-модулей и почему радоваться рано.

Коротко для фронтенда: реализация модулей в Webpack отличается от стандарта, поддержка браузерами чистых модулей ещё не совсем достаточна, а когда она будет достаточна — встанет проблема доставки до потребителя и генерации карт исходного кода. В общем, от бандлеров избавиться удастся совсем не скоро, а скорее всего — никогда. Но это и не нужно.

https://twitter.com/andrey_sitnik/status/1229753395961044993

#фишка дня
#color

Telegram стал показывать в бета-версии цвет рядом с HEX-представлением, как в большинстве современных IDE и редакторов. Если нет — у вас или старая версия, или X. Ждите обновлений!

#FF33FF

По этому поводу давайте вспомним, что когда-то в вебе был определён набор “безопасных” цветов в количестве 216 оттенков (https://www.artlebedev.ru/colors/). Сейчас, конечно, это не имеет никакого смысла, лишь как артефакт эпохи.

Вот некоторые из них:

#FF0000
#FF6600
#FFFF00
#00FF00
#0099FF
#0000FF
#9900FF

Кстати, не будет лишним напомнить, что все “безопасные” цвета могут быть записаны в трёхзначном, а не только шестизначном формате:

#09f

Вот только Telegram, к сожалению, пока такой формат не поддерживает.

#статья дня #html #js

Разработчики #Google выкатили статью о том, что же изменилось в атрибуте loading для “ленивой” подгрузки изображений с момента первого релиза.

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

https://web.dev/native-lazy-loading/#improved-data-savings-and-distance-from-viewport-thresholds

#статья #css #img

Опрос показал, что тема проклятого отступа внизу изображений волнует многих.

Итак, встречайте вторую статью в нашем Телеграфе: Загадка дыры.

Рассмотрим несколько решений, от плохого к прекрасному, и полностью раскроем причину происходящего. Немного погрузимся в инлайновый контекст форматирования, что пригодится и в других задачах.

Особая благодарность Виталию из канала Просто: разработка за идею и редактуру.

#статья дня
#css #inline #layout

На CSS-Tricks вышла статья про статус inline-block в 2020 году.

Что такой inline-block? Это значение свойства display, которое позволяет строчным элементам иметь свои собственные размеры, отступы, поля.

Раньше оно часто использовалось для формирования сеток, но приходом flexbox-модели это стало не нужно и про inline-block многие вообще забыли.

Статья рассматривает варианты, когда оно всё ещё может быть полезным:

1. Для трансформации inline-элементов в строке, поскольку иначе к ним трансформацию применить нельзя

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

3. Помогает быстро и лаконично сделать список горизонтальным.

Остальное, а также примеры плохого использования, читайте тут: https://css-tricks.com/when-do-you-use-inline-block/

Нелишним будет упомянуть и статью на прекрасном ресурсе css-live.ru, повествующую об интересных примерах использования inline-block с гораздо большим погружением в тему: https://css-live.ru/articles-css/udivitelnyj-i-neizvestnyj-inline-block.html

#фишка дня
#css #keyframes #animation

Чтобы задать анимацию появления какого-либо элемента на экране при загрузке страницы, добавлении элемента или обновлении DOM совсем не нужно городить сложных конструкций.

Достаточно проделать следующий трюк:

@keyframes appear {
from {
…whatever
}
}

Это анимирует объект в момент его появления из положения, заданного в анимации, в то, что указано в стилях.

Пример на CodePen: https://codepen.io/alinaki/pen/XWXORzM

Попробуйте обновить страницу и поиграться со значениями.

Спасибо Twitter-банде https://twitter.com/keyframers за эту находку.

#статья дня
#css #w3c

На сайте increment.com вышла отличная статья о том, почему CSS получился… таким.

Технический директор W3C Крис Лиллей (Chris Lilley) рассказывает о причинах некоторых неожиданных, необычных и откровенно странных решений, которые привели CSS к тому виду, что мы имеем сейчас.

https://increment.com/frontend/ask-an-expert-why-is-css-the-way-it-is/

Испытываю невыносимое желание ввести рубрику “#codepen дня” для интересных находок. Но таких находок в течение дня может быть столько, что проще ввести “#codepen недели”.

Вы только посмотрите, как это, буквально, свёрстанное радио начинает проигрывать музыку!

https://codepen.io/ricardoolivaalonso/pen/ExPpgqG

Была бы вам интересна такая рубрика в перерывах между статьями? А заодно, хотели бы вы узнать больше о процессе создания подобных вещей?

Господа, ну вы поняли.

Очень приятно, что вас уже 300 человек. Дальше — больше.

На подходе статья о весьма неожиданном решении одной очень раздражающей проблемы. Оставайтесь на связи.

#заметка дня
#css #flex #ie #float #flexbugs

По какой-то неведомой мне причине в профильных чатах очень часто, волнами, появляются люди, которых (как они заявляют) учат верстать на float.

Мол, сначала блоки, потом float, потом flex и потом grid. Это, конечно же, полный бред. Никакого порядка изучения нет, есть лишь разные модели раскладки контента.

Более того, я заметил это в паре книг, но сейчас не о них.

Часть из этих людей утверждает, что им приходится верстать на float потому что нужна поддержка Internet Explorer 11, который, будто бы, не поддерживает flexbox.

Господа, я не знаю, кто вас заставляет так считать. Всё прекрасно работает, даже без -ms-префиксов. Проблем на самом деле намного больше и они везде.

Как всегда, залог успешной вёрстки — это простая гигиена и знание справочников. В отношении flexbox она такова:
никогда не используйте короткую запись (flex: 1 0 auto и т. п), пишите конкретные правила; не надо полагаться на значения по-умолчанию.

Эта гигиена, кстати, вообще касается многих сложносоставных правил.

А чтобы быть уверенным, всегда держите в закладках замечательную подборку багов с решениями, которая так и называется: Flexbugs.

https://github.com/philipwalton/flexbugs

Ну и эта статья с расшифровкой от прекрасного канала @defront слишком хороша, чтобы её не репостнуть.

Амелия Ваттенбергер написала интерактивную статью про использование процентов в CSS — "What does 100% mean in CSS?".

В статье есть хорошие интерактивные примеры и краткое описание поведения процентов для разных свойств:
- для height процент высчитывается относительно высоты родителя
- для width — относительно ширины родителя
- для top — относительно высоты родителя
- для left — относительно ширины родителя
- для margin-top — относительно ширины родителя
- для margin-left — относительно ширины родителя
- для padding-top — относительно ширины родителя
- для padding-left — относительно ширины родителя
- для translate-top — относительно высоты элемента
- для translate-left — относительно ширины элемента

Очень прикольная статья. Советую почитать всем, кто хочет разобраться с процентами в CSS.

#css

https://wattenberger.com/blog/css-percents

#статья дня
#html #css #px #em #rem #vw #vh

Лето и отпуск не лучшие помощники в написании новых статей, но ничто не забыто.

Тем временем великолепная Йоксель (https://twitter.com/yoksel) выпустила крайне подробную статью о единицах измерения в CSS.

Рассмотрены даже не самые популярные единицы вроде ex и ch, даны разъяснения об их вычислении и приведены наглядные примеры.

Единственное, не сказано о том, что v-единицы не реагируют на масштаб в браузере. Надо бы сообщить. (см. Upd.)

Читаем и не забываем подписываться на Йоксель в твиттере.

Upd. О важности взаимодействия с авторами. В статье появилось упоминание, что v-единицы не реагируют на масштаб. Никогда не стесняйтесь сообщать авторам статей о всём, что считаете нужным.

https://css.yoksel.ru/size-units/

#статья дня

Чему senior-разработчики могут поучиться у начинающих: https://stackoverflow.blog/2019/12/19/what-senior-developers-can-learn-from-beginners/

Она немного выбивается из общей сути канала статья, но всё же о буднях.

Случилось вот что: мы в шесть глаз просмотрели глупейшую опечатку.

В очень старом коде было повторяющееся условие проверки включения элемента в массив настроек:

settings.indexOf(“COMBINE_RESULTS”) !== -1

…и обратное к нему (=== -1).

Очевидно, было принято решение заменить его на переменную shouldCombineResults и использовать везде.

И в этот момент и была допущена ошибка: заменив инверсное условие, мы забыли поставить оператор отрицания: “!”. И на ревью никто не заметил этого.

Почему? Потому что иногда лучше быть чётким в своих условиях, пусть даже код и выглядит странно. Очевидно, решение было плохим, но оно хотя бы было прямолинейным и чётко описывало условие. Раз три человека это пропустило, значит, и подход к рефакторингу был неверным изначально.

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