Бывает так, что встречаются инфоповоды, которые на первый взгляд выглядят как выхлоп воспалённого сознания Бена Чанга из сериала «Сообщество». И кураторы, и редакторы новостей Хабра их чаще всего избегают. Но и эти новости, и публикации в других жанрах тоже несут определённую информацию, без которой схема устройства современного мира и технологий выглядит неполной, «недособранной». 

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

Меня зовут Александра, я дизайнер из Ozon в SX — Seller Experience. Сегодня расскажу продуктовую историю о таблицах и дизайн-долге.

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

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

Привет, друзья!

В данной статье мы разработаем простую, но относительно полноценную дизайн-систему для веб-приложения средствами Sass.

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

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

Код проекта на GitHub.

Если вам это интересно, прошу под кат.

Для Figma написан целый легион плагинов на все случаи жизни. Постоянно появляются рейтинги и топ-листы супер-пупер-мега-лучших. Но этот инструмент используют люди разных конфессий, решая разные свои задачки. Рыцари фриланса рисуют лендинги, студийные братья собирают промо-сайты, еретики даже визитки и плакаты пытаются делать в Figma. И для всех есть свои плагины. Поэтому делать общий топ-100 — пустое занятие.

Но можно накидать локальный местечковый топчик для продуктового дизайнера например. В нём не будет плагинов в духе «смотрите, какая любопытная идея» или «если вдруг вам когда-нибудь понадобится заменить все картинки на фото Николаса Кейджа». Только ежедневные трудяги. Я уверен, этот список будет полезен не только UI-дизайнерам и сочувствующим. Что-то полезное найдут для себя и все остальные фанаты Figma.

Привет, Хабр! Меня зовут Анатолий Долгов и я frontend-разработчик международной команды Учи.ру. Сегодня я расскажу, как мы успешно синхронизировали параметры дизайна и кода. Это упростило многие рабочие моменты, уменьшило количество неприятных ошибок и сделало нас ближе к внедрению полноценной дизайн-системы.

Меня зовут Николай, я Frontend-разработчик IT-компании Relog. Хочу рассказать о самых распространённых ошибках в вёрстке современных проектов.

Дело в том, что лишь малая часть современных фронтендеров обращает внимание на работу с HTML и CSS, предпочитая готовые решения, вроде UI-библиотек и систем сеток. Но эти решения неидеальные и приходится дописывать обёртки вокруг них, видоизменять код, переписывать стили и совершать прочие действия для соответствия требованиям проекта. Тут-то и начинаются проблемы: вёрстка местами становится избыточной, стили переназначются через important и с каждым релизом проект всё сложней поддерживать. Я уже не говорю об удобстве использования и доступности. Об этом думают вообще в последнюю очередь.

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

В этой статье я решил поговорить о создании сайтов на базе CMS Drupal. Работаю я с этой системой давно и считаю ее одной из лучших среди существующих «движков» сайтов. За исключением случаев, когда действительно необходимы какие-то узкоспециализированные решения эту CMS я рекомендую и своим клиентам.

Функция :where() помогает писать меньше кода, применять стили ко всему списку и снимает головную боль при использовании CSS reset. В статье разберёмся, как это работает, и посмотрим на примеры использования.

Привет! Меня зовут Сергей Путятинский, в Московском кредитном банке (МКБ), я отвечаю за блок IT, клиентский сервис и бэк-офис. Не так давно мы с коллегами по цеху собирались обсудить тренды в цифровизации, причем было желание поговорить не о сферических цифровых «конях в вакууме», а о реальных ситуациях. Если вам интересны сегодняшние и завтрашние тренды в отрасли, ситуации «ожидание-реальность», что сейчас происходит на рынке труда с людьми, их навыками и зарплатами — этот пост для вас.

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

Mac наступает со своим чипом M1. Новичков в этой экосистеме должно заметно прибавиться. Сам я многие годы с уважением смотрел на эти интерфейсы. Слушая какой же Mac удобный, плавный и интуитивный. Какой там великолепный Trackpad, что даже мышь не нужна и бла бла бла. И вот, после 15 лет работы CAD разработчиком, я решил поменять профиль и стать программистом. А чтобы не терять мотивацию в процессе обучения, выбрал для себя наиболее наглядное направление, как мне показалось — iOS разработка. Сказано — сделано. MacBook Pro 16” уже год мой основной компьютер.

Привет, Хабр!

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

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

- Как сделать таблицу с фиксированной шапкой и скроллом в body?

- Как быть, когда cодержимое таблицы съезжает относительно шапки при появлении скролла? Как избежать использования overflow: 'scroll' в данной ситуации. Установка css-переменной scroll-width.

- Оптимизация и кастомизация скролла: плавность, scroll margin, изменение цвета и формы.

1. Атрибут `loading=lazy`

<img src='image.jpg' loading='lazy' alt='Alternative Text'>  

Эта статья — шпаргалка по HTML-тегам. Поэтому не будем разглагольствовать, сразу к делу.

abbr

Тег abbr определяет аббревиатуру или акроним. Аббревиатура или акроним расшифровываются с помощью атрибута title.

<abbr title="HyperText Markup Language">HTML</abbr> был разработан британским ученым Тимом Бернерсом-Ли приблизительно в 1986—1991 годах.

abbr часто используется совместно с тегом dfn, идентифицирующим понятие или термин:

<p><dfn><abbr title="Cascading Style Sheets">CSS</abbr></dfn> - формальный язык описания внешнего вида документа (веб-страницы).</p>

address

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

Приветствую, уважаемые хабровчане. Это мой первый пост на этой площадке, хотя в качестве читателя с вами уже, наверное, 10 лет. Я не являюсь специалистом в IT, хотя имел отношение к запуску небольшого количества стартапов. Можете называть меня практикующим теоретиком – запускаю продукты, занимаюсь управлением проектами, помогаю компаниям улучшать процессы, внедрять всякие гибкие управленческие штуки, немного преподаю в ВШЭ. Но всё это делаю не столько, чтобы заработать денег, а чтобы удовлетворить собственное любопытство в том, как устроены системы и держать голову в тонусе.

Этот пост был написан пару лет назад на vc.ru, в правилах сообщества не запрещено, публиковать контент с других площадок. С вашего позволения, здесь опубликую его снова, но с небольшими корректировками. Надеюсь, найдёте материал и инструмент, о котором пойдёт речь, полезными.

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