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

Почему CSS-фреймворки — это кошмар

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

Встроенный стиль

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

Интернационализация — довольно обширная идея, о которой стоит подумать; поэтому я оставил ссылку, если вы хотите проверить это.

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

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

!important (Написание пользовательских стилей)

Вы когда-нибудь работали над проектом с использованием CSS-фреймворка и ловили себя на том, что пишете !important в конце почти каждой строки? Пользовательские стили являются основой большинства современных веб-приложений. Существует множество шаблонов проектирования, которым мы обычно следуем при разработке приложения, и в этом случае — мы можем предположить, что использование CSS-фреймворка ускорит процесс — до тех пор, пока нам не понадобится индивидуальный стиль. Да CSS расшифровывается как Каскадные таблицы стилей, что означает, что рабочий процесс похож на поток воды — мы можем просто включить наш пользовательский CSS после импорта фреймворка CSS, однако даже тогда мы пишем многословный CSS , так как нам, возможно, даже придется сузить нашу точность CSS. Чаще всего эти CSS-фреймворки часто используют много !important , что полностью искажает природу CSS (каскадирование).

Но CSS сложный

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

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

Это проблема, CSS-фреймворки используются для унификации дизайна; для обеспечения согласованности, а скорее используются для ускорения разработки, что впоследствии приводит к техническому долгу.

Почему CSS сложный

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

  • Начните с организованности, затем обленитесь и начните писать CSS повсюду.
  • Начните с дезорганизации и продолжайте с дезорганизацией.

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

Как использовать SASS для написания организованных стилей

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

<!-- other content -->
<main>
  <h1>Apples</h1>
  <p class="some-sub-title">The apple is the pomaceous fruit of the apple tree.</p>
  
  <article>
    <h2>Red Delicious</h2>
    <p>These bright red apples are the most common found in many
    supermarkets.</p>
    <p>... </p>
    <p>... </p>
  </article>
<article>
    <h2>Granny Smith</h2>
    <p>These juicy, green apples make a great filling for
    apple pies.</p>
    <p>... </p>
    <p>... </p>
  </article>
</main>
<!-- other content -->

Что должно выглядеть примерно так:

Написание скелета в SASS

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

// oursass.scss
/*
main {
   h1 {
   }
   p.some-sub-title {
   }
   article {
      h2 {
      }
      p {
      }
   }
}
*/

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

Я вставлю пример мобильного подхода ниже:

// Less than 600px
main {
   h1 {
   }
   p.some-sub-title {
   }
   article {
      h2 {
      }
      p {
      }
    }
}
/* Larger than mobile (default point when grid becomes active) */ @media (min-width: 600px) {
   main {
      h1 {
      }
      p.some-sub-title {
      }
      article {
         h2 {
         }
         p {
         }
       }
   }
}
/* Larger than phablet */
@media (min-width: 900px) {
   main {
      h1 {
      }
      p.some-sub-title {
      }
      article {
         h2 {
         }
         p {
         }
       }
   }
}
/* Larger than tablet */
@media (min-width: 1200px) {
   main {
      h1 {
      }
      p.some-sub-title {
      }
      article {
         h2 {
         }
         p {
         }
       }
   }
}
// I will usually put my skeleton code here in a comment so I can always refer to an empty version of it in case I still somehow get confused about the structure of my styles.

Вы можете посмотреть на это и сказать, что не будете использовать изменение определенного стиля для определенного размера экрана — тогда какой в ​​этом смысл?

На самом деле, давайте попробуем изменить ~это~ вместо этого.

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

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

Да, я думаю, это довольно организованно, но как насчет производительности?

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

Подведение итогов

Это точно не ракетостроение, и я думаю, что есть разработчики, которые предпочитают писать свои стили таким образом. Однако, работая над проектом в команде, я часто обнаруживаю, что большинство разработчиков по-прежнему склоняются к использованию фреймворков CSS, хотя на самом деле написание собственного чистого, организованного ванильного решения более перспективно, поскольку мы не полагаемся ни на кого, кроме себя.

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

Чао!