Заметки о фронтенде

Блог Виталия Зюзина

Инспекция и причёсывание CSS

Предыстория

Однажды мы решили сделать в Академии кодгайд. Кодгайд нам стал нужен для контроля над собственным кодом HTML/CSS и кодом учебных проектов студентов, которые у нас проходят интенсивный курс.

Сам по себе кодгайд — хорошая, но нестрогая штука. Команда ознакомилась с ним и взяла на вооружение: загрузили правила кодгайда в мозг, собственный и ученический код стали проверять методом «пристального взгляда».

У такого подхода есть очевидный минус — человеческий фактор. Можно запросто забыть или упустить что-то из правил. Чтобы контролировать собственный CSS-код, мы сделали конфигурацию для CSSComb и как-то справлялись автоматическим «причёсыванием» кода. Это конечно хорошо для производительности: написал CSS, запустил «расчёску», а она тебе сама поправит все недочёты и ошибки. Но совсем не подходит для целей обучения студентов или новичков в команде: человек будет полагаться на автоматическое «причёсывание», вместо того, чтобы самому научиться писать красивый единообразный код.

Поэтому я задумался об автоматизированной инспекции кода.

Линтинг

Решений для инспекции CSS на самом деле оказалось не так много. Да и захотелось ещё проверять не только CSS, но и PostCSS, на котором у нас написан новый фронтенд.

CSSLint немного устарел (последний релиз 15 августа 2013), и в нём не так много возможностей для тонкой конфигурации.

SCSS-Lint подходит только для SCSS, кроме того требует Ruby, что более проблематично, чем Node.js (который уже есть в проектах).

А вот Stylelint отлично себя зарекомендовал:

  • большие возможности тонкой настройки «из коробки»;
  • возможность кастомизации;
  • работает с PostCSS и поддерживаемыми им препроцессорными синтаксисами (CSS, SCSS, LESS…).

Stylelint можно запускать из консоли, из Node.js, из таск-раннера или прямо в редакторе. Я сейчас использую его преимущественно из Атома.

Всё, что Stylelint умеет проверять «из коробки», можно условно разделить на группы:

  • проверка форматирования кода;
  • «цензура» кода;
  • нахождение и предотвращение ошибок.

Всего на момент написания статьи конфигурация Stylelint содержит около 150 правил. Все правила досконально описывать в этой статье не имеет смысла, так как они подробно разобраны в документации.

Проверка форматирования кода

Основное, что я жду от линтера — проверка соответствия кодгайду. То есть отступы, табуляция, единицы измерения, отбивка — вот это всё. Вот, к примеру, условно «правильный» код:

Пример «правильного» кода

Отступление от описанного в конфиге форматирования сигнализирует об ошибке. Проверяется много чего:

  • написание цветов (color-hex-case, color-hex-length, color-named, color-no-hex);
  • написание шрифтов (font-family-name-quotes, font-weight-notation);
  • пробелы и табуляция (тут очень много правил: пробелы можно проверять до и после практически любых конструкций в CSS);
  • кавычки (function-url-quotes, string-quotes);
  • переносы в CSS-правилах и списках правил (тут тоже много правил относительно разных конструкций CSS);
  • регистр букв в селекторах, свойствах и значениях (unit-case, value-keyword-case,property-case и другие);
  • двоеточия (selector-pseudo-element-colon-notation);
  • и ещё много других моментов.

Пример ошибок в коде:

Пример кода с неправильным форматированием

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

«Цензура» кода

Кроме базовой проверки стиля кода, Stylelint можно использовать для тотальной «цензуры». Есть возможность вполне безобидного запрета !important (declaration-no-important), стилизации по #id или имени тега (selector-no-attribute, selector-no-id). А можно ввести танки списки запрещённых или наоборот только разрешённых свойств (property-blacklist, property-whitelist), значений (property-value-blacklist, property-value-whitelist), CSS-функций (function-blacklist, function-whitelist), единиц измерения и даже содержимого комментариев.

Эта возможность хорошо подходит для формирования набора правил, по которым будет обучаться новичок. Например, в интенсивных курсах HTML Academy по вёрстке для начинающих мы запрещаем пользоваться !important и расставлять вендорные префиксы вручную:

Пример кода с использованием !important Пример кода с вендорными префиксами

Проверку кода можно проводить перед пушем в учебный репозиторий.

Нахождение и предотвращение ошибок

Ну хорошо. Если всё вышеизложенное можно отнести к стилю кода, то возможности Stylelint по нахождению ошибок и потенциально «опасных» мест в ваших стилях — приятный бонус линтера.

Опишу несколько правил Stylelint, которые находят и предотвращают ошибки.

Правило color-no-invalid-hex находит недопустимые символы в шестнадцатеричном представлении цвета:

Пример кода с неправильным значением цвета

Правило no-duplicate-selectors найдёт одинаковые селекторы:

Пример кода с дубликатом селектора

Правило declaration-block-no-shorthand-property-overrides предотвратит бессмысленное переопределение свойств внутри правил:

Пример кода с бессмысленным переопределением свойства

Правило no-descending-specificity обнаружит бессмысленное переопределение правил более специфичными селекторами.

Пример кода с бессмысленным переопределением правила

Правило no-indistinguishable-colors предупредит о похожих цветах, заданных в CSS:

Пример кода с похожими цветами

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

«Причёсывание»

В некоторых случаях хочется или нужно «причесать» стили автоматически.

Как я говорил раньше, мы пользовались CSSComb для причесывания стилей. Но, к сожалению, бывало, он глючно работал с нестандартным синтаксисом вроде Sass, вовсе не работал с PostCSS и в целом приостановился в развитии.

Так что пришлось искать ему замену. И приятной находкой оказался stylefmt, который работает с понимаемыми PostCSS синтаксисами и принимает правила конфигурации Stylelint.

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

  • переносы и пробелы перед и после открывающих скобок (block-opening-brace-newline-after, block-opening-brace-newline-before, block-opening-brace-space-after, block-opening-brace-space-before);
  • отступы (indentation);
  • пробелы до и после комбинаторов (selector-combinator-space-after, selector-combinator-space-before);
  • переносы и пробелы перед и после запятых в селекторах (selector-list-comma-newline-after, selector-list-comma-newline-before, selector-list-comma-space-after, selector-list-comma-space-before).

Остальное по-прежнему придётся править руками. Или можно помочь сообществу и запилить недостающую функциональность.

Сортировка свойств в CSS-правилах

Чем ещё был хорош CSSComb, так это автоматическая сортировка свойств внутри CSS-правил.

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

А stylefmt пока что не умеет автоматически наводить порядок в очерёдности свойств.

Что делать?

На помощь пришёл замечательный инструмент PostCSS Sorting. Он умеет сортировать свойства в правилах синтаксисов, которые понимает PostCSS. Этот инструмент вдохновлён CSSComb, и у него аналогичный конфиг. Запускать его можно тоже таск-раннером или из редактора.

Логично предположить, что рано или поздно stylefmt и PostCSS Sorting станут каким-то образом связаны, и их можно будет использовать как один инструмент.

Итого

Я составил и обновляю по мере необходимости конфигурации для Stylelint и для PostCSS Sorting. Их можно просто использовать или переопределить.

Держите свой код в порядке!

Баги в браузерах. Кто виноват и что делать?

В апреле ездил в Екатеринбург на ДАМП. Рассказывал про баги в браузерах. Вот и видео выступления с конференции подоспело.

Презентация прилагается.

Техника помидора

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

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

Вкратце

Техника работает. Не отвлекаясь по мелочам всю неделю работал более эффективно. Сделал боьше, чем обычно, за то же время. Рекомендую!

Что ещё за помидоры

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

Спринты идут следующим образом:

  1. 25 минут работы;
  2. 5 минут перерыв;
  3. 25 минут работы;
  4. 5 минут перерыв;
  5. 25 минут работы;
  6. 5 минут перерыв;
  7. 25 минут работы;
  8. 15 минут перерыв.

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

Это всё теория, а …

На практике

… получается следующим образом. В начале рабочего дня я начинал разбирать разные мелкие задачи и дела, не включая счётчик помидоров. С прошлого дня накапливаются незавершённые мелочи, рандомные коммуникации, идеи, которые надо быстро разрешить и проверить. Этот предварительный этап у меня длился от 1 до 2 часов. Дальше разбирал задачи на сегодня из общего туду-листа.

Затем я включал счётчик, выключал уведомления и начинал работать уже по помидорам. До большого перерыва получалось сделать от 4 до 6 помидоров.

В большой перерыв я шёл на обед, который занимает около часа.

После обеда получалось сделать от 7 до 12 помидоров.

Итого примерно так:

  1. 1−2 часа без помидоров, рандом, подготовка;
  2. 2−3 часа работы;
  3. 1 час большой перерыв;
  4. 3.5−6 часов работы.

Итого, в среднем за прошедшую неделю получалось от 5 до 8 часов «чистой» работы в день. И это действительно эффективная работа, когда ты полностью погружаешься и входишь в состояние потока. Плюс 1−2 часа на предварительный рандом и подготовку.

Инструменты

Я использовал бесплатный Pomodoro One для мака. Это приложение простое и понятное, выдаёт окошко на передний план и звук, когда заканчивается или начинается следующий период. Ещё рекомендовали веб-версию Tomato Timer и платное приложение для мака Tadam, но я не пробовал.

Итог

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

Кнопка

Потихоньку реализую элементы будущего дизайна HTML Academy. Вот, к примеру, кнопка с эффектом по наведению или фокусу.

See the Pen Эффект кнопки by juwain (@juwain) on CodePen.

Отступы фонового изображения

Простой способ добавить отступы фоновому изображению:
background-position: center и background-size: calc(100% - Npx).

See the Pen zGawGV by juwain (@juwain) on CodePen.