Как создать папку css
Перейти к содержимому

Как создать папку css

  • автор:

Организация кода для CSS препроцессоров

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

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

Архитектура?

Одна из самых привлекательных возможностей CSS препроцессоров — подключение файлов. Это позволяет нам разделить код на несколько частей, которые впоследствии будут объединены препроцессором. Таким образом, можно работать с отдельными файлами и не беспокоиться о длинном списке HTTP запросов.

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

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

Создание архитектуры я всегда буду начинать с папки base. В ней будут файлы, которые не следует трогать (например, reset или стили библиотек).

Функциональное распределение

Это структура, которая рано или поздно приходит в голову, если вы новичок в препроцессорах. Распределить функциональность на отдельные файлы и вправду кажется очень логичным. Один файл для всех переменных, один для примесей и т.д. и, наконец, один для текущих стилей. Давайте добавим еще normalize.scss ради реализма.

  • /base
  • _mixins.scss
  • _variables.scss
  • screen.scss
Достоинства
  • Красивый список примесей и переменных
Недостатки
  • Все стили в одном файле
Вывод

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

Распределение «Катана»

Ну, а если, скажем, разделить страницы на части и обозначить стили для каждой части индивидуально?

  • /base
  • /sections
    • _header.scss
    • _content.scss
    • _footer.scss
    • _sidebar.scss
    • _modals.scss
    Достоинства
    • Имеет смысл
    • Вряд ли будут повторяющиеся селекторы (отдельные блоки правил для одного и того же селектора)
    Недостатки
    • Можно запутаться, особенно если у вас много форм представления
    • Файлы стилей могут стать довольно объемными, в частности _content.scss
    Вывод

    К сожалению, с помощью подобной структуры, вы мотивируете себя использовать стили исключительно в определенных областях страниц, и в результате получаете статичный CSS и множество повторяющихся свойств (например border-radius ). Вы можете частично компенсировать этот недостаток используя примеси и переменные. Тем не менее, данный подход может подходит только для малых и средних проектов.

    Шаблонное или страничное распределение

    Если описывать отдельные файлы стилей для каждого шаблона или страницы, то легко найти какой-либо объект, особенно если он носит похожее название.

    • /base
    • /templates
      • _category.scss
      • _footer.scss
      • _header.scss
      • _index.scss
      • _page.scss
      • _single.scss

      Вы можете заметить, что имена шаблонов выглядят очень похожими на имена шаблонов WordPress. Это сделано специально.

      Достоинства
      • Хорошее распределение
      • Легкий поиск
      • Кастомизация каждого шаблона
      Недостатки
      • Мы опять слишком сильно ушли в детализацию
      Вывод

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

      В терминах веб-дизайна

      Я слышал, как Крис Койер (Chris Coyier) описывал эту архитектуру в ролике «Рабочий процесс современного веб-дизайнера». Как и предполагает название, она предназначена для веб-дизайнеров. То есть комфортно ей воспользоваться смогут только люди знакомые как с дизайном, так и с профессиональным сленгом.

      Чего Крис не сделал, так это не использовал папки, а они все же могут понадобиться.

      • _normalize.scss
      • _buttons.scss
      • _footer.scss
      • _grid.scss
      • _header.scss
      • _icons.scss
      • _navigation.scss
      • _typography.scss
      • screen.scss
      Достоинства
      • Имеет смысл (для дизайнеров)
      Недостатки
      • Пугает не-дизайнеров
      • Довольно неряшлива
      • Могут быть повторяющиеся селекторы
      Вывод

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

      Коктейль «Хьюго»

      Чуть ранее в этом году Хьюго (Hugo Giraudel) описал свою Sass архитектуру. Оказалось, это смесь всего того, что мы обсуждали ранее.

      • /base
        • _normalize.scss
        • _typography.scss
        • _buttons.scss
        • _navigation.scss
        • _mixins.scss
        • _variables.scss
        • _grid.scss
        • _header.scss
        • _footer.scss
        • _bootstrap.scss
        • _jquery-ui.scss
        Достоинства
        • Маленькие файлы
        • Выглядит организовано
        Недостатки
        • Слишком много файлов и папок
        Вывод

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

        Дополнение от Игоря Зенича

        Если вы используете БЭМ-методологию, то логичным будет использовать один из БЭМ-вариантов организации файловой системы:

        Обратная БЭМ-иерархия

        В раннем БЭМ, когда Яндекс ещё писал код руками, использовался другой вариант, который за неимением официального названия, я называю «обратная БЭМ-иерархия»: исходники раскладываются на папки по технологиям, а внутри них — разделяются на файлы по блокам:

        scss/ blocks/ input/ # Директория блока input _input_theme_forest.scss # Реализация модификатора theme в значении forest в технологии CSS _input__clear.scss # Реализация элемента clear в технологии CSS _input.scss # Блок input в технологии CSS button/ # Директория блока button _button.scss jade/ _input.jade _button.jade js/ blocks/ input.js # Блок input в технологии JavaScript button.js xml/ xsl/ img/ blocks/ input/ # Директория блока input input__clear.png # Реализация элемента clear в технологии PNG button/ # Директория блока button button.png 
        Достоинства
        • Легко поддерживать вручную
        • Разделяет файлы на отдельные блоки
        Недостатки
        • Нет четких критериев: когда создавать папку под блок, а когда — просто отдельный файл
        • Нельзя использовать bem-tools

        Прямая БЭМ-иерархия

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

        blocks/ input/ # Директория блока input _theme/ # Директория опционального модификатора theme input_theme_forest.css # Реализация модификатора theme в значении forest в технологии CSS __clear/ # Директория опционального элемента clear input__clear.css # Реализация элемента clear в технологии CSS input__clear.png # Реализация элемента clear в технологии PNG input.css # Блок input в технологии CSS input.js # Блок input в технологии JavaScript button/ # Директория блока button button.css button.js button.png 
        Достоинства
        • Легко добавлять и удалять блоки
        • Можно использовать bem-tools — инструменты для сборки проекта из блоков
        Недостатки
        • Если вы, как и большинство разработчиков, не используете полный стек БЭМ-технологий, то поддерживать такую структуру вручную довольно утомительно
        • Неудобно использовать популярные инструменты сборки (Grunt, Gulp) и плагины к ним, т.к. они предполагают что файлы сложены по папкам отдельно: css, js, графика, а не разбросаны вперемешку.
        Вывод

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

        Резюмируя

        Все это — не более чем примеры различных архитектур. Я все еще нахожусь в поиске «той самой», идеальной, архитектуры, если, конечно, она существует. Но, даже если я её и найду, это в любом случае будет моим субъективным мнением.

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

        Webpack: сборка CSS в отдельную папку

        На проекте решил использовать Webpack, и возникла необходимость “сборки” CSS (из SASS) в кастомную папку.
        По умолчанию Webpack диктует нам определенные условия в плане расположения выходных файлов, и в “обычном” случае мы получаем JS и CSS файлы рядом друг с другом, к тому же, подразумевается вызов CSS прямо из JS.

        Для создания внешних CSS файлов официальная документация советует использовать плагин extract-text-webpack-plugin.
        Но в нем есть один существенный минус — нельзя задать свою директорию для сохранения CSS. Можно задать только имя файла.

        Долго копался и все-таки нашел способ, как дать webpack’у понять, что мы собираем разные вещи — JS отдельно, а CSS отдельно. Способ несколько костыльный, более того — он не совсем соответствует логике webpack, но он работает!

        Итак, сразу покажу готовый файл webpack.config.js:

        Как это работает

        Параметр module в принципе не содержит в себе ничего необычного — лоадер babel-loader для работы с ES6 в JS файлах и лоадеры css-loader и sass-loader для возможности работы с SASS (SCSS).

        Ключевое — это параметры entry и output .
        Webpack нам в официальной документации указывает, что формат output может быть только один, но имя файла может содержать в себе placeholder’ы, которые динамически будут подставляться при сохранении файла.
        А различные конфигурации entry нам позволяет входить через один конкретный файл, либо объединять файлы при входе, либо поочередно входить в каждую указанную точку.

        Вот именно третий вариант мы и используем. Как входную точку передаем webpack’у объект вида . При такой подаче конфига webpack поочередно будет входить по указанному пути, и, в дальнейшем, при сохранении файлов на выходе можно использовать имя входной точки с помощью плейхолдера [name] .
        И вот в этом моменте мы используем легкий финт ушами: в качестве имени точки входа мы передаем путь для сохранения, и таким образом при сохранении файла в плейхолдере [name] мы имеем необходимый путь!

        В моем случае это работает так:

        Webpack видит объект entry и берет первую пару: имя js/app.js и путь ./app/src/entry.js , входит по указанному пути, работает, и на выходе составляет имя файла по шаблону output , а именно: __dirname + ‘/build/ + filename , куда вместо filename ставит указанный плейсхолдер [name] , то есть составляет такой путь: __dirname + ‘/build/’ + [name] , и, подставляя наше имя входной точки, мы получаем такой путь: __dirname + ‘/build/’ + ‘js/app.js’ .
        Аналогично поступает с второй входной точкой по имени css/main.css , то есть выходной путь для нее будет выглядеть так: __dirname + ‘/build/’ + ‘css/main.css’

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

        Работа с файлами

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

        Где ваш веб-сайт должен располагаться на вашем компьютере?

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

        1. Выберите место для хранения проектов веб-сайта. Здесь, создайте новую папку с именем web-projects (или аналогичной). Это то место, где будут располагаться все ваши проекты сайтов.
        2. Внутри этой первой папки, создайте другую папку для хранения вашего первого веб-сайта. Назовите её test-site (или как-то более творчески).

        Небольшое отступление о регистре и пробелах

        Вы заметите, что в этой статье, мы просим вас называть папки и файлы полностью в нижнем регистре без пробелов. Это потому что:

        1. Многие компьютеры, в частности веб-серверы, чувствительны к регистру. Так, например, если вы положили изображение на свой веб-сайт в test-site/MyImage.jpg , а затем в другом файле вы пытаетесь вызвать изображение как test-site/myimage.jpg , это может не сработать.
        2. Браузеры, веб-серверы и языки программирования не обрабатывают пробелы последовательно. Например, если вы используете пробелы в имени файла, некоторые системы могут отнестись к имени файла как к двум именам файлов. Некоторые серверы заменяют пробелы в вашем имени файла на «%20» (символьный код для пробелов в URI), в результате чего все ваши ссылки будут сломаны. Лучше разделять слова дефисами, чем нижними подчёркиваниями: my-file.html лучше чем my_file.html .

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

        Какую структуру должен иметь ваш веб-сайт?

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

        1. index.html : Этот файл обычно содержит контент домашней страницы, то есть текст и изображения, которые люди видят, когда они впервые попадают на ваш сайт. Используя ваш текстовый редактор, создайте новый файл с именем index.html и сохраните его прямо внутри вашей папки test-site .
        2. Папка images : Эта папка будет содержать все изображения, которые вы используете на вашем сайте. Создайте папку с именем images внутри вашей папки test-site .
        3. Папка styles : Эта папка будет содержать CSS код, используемый для стилизации вашего контента (например, настройка текста и цвета фона). Создайте папку с именем styles внутри вашей папки test-site .
        4. Папка scripts : Эта папка будет содержать весь JavaScript-код, используемый для добавления интерактивных функций на вашем сайте (например, кнопки которые загружают данные при клике). Создайте папку с именем scripts внутри вашей папки test-site .

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

        Файловые пути

        Для того, чтобы файлы общались друг с другом, вы должны указать файлам путь друг к другу — обычно один файл знает, где находится другой. Чтобы продемонстрировать это, мы вставим немного HTML в наш файл index.html и научим его отображать изображение, которое вы выбрали в статье «Каким должен быть ваш веб-сайт?»

        1. Скопируйте изображение, которое вы выбрали ранее, в папку images .
        2. Откройте ваш файл index.html и вставьте следующий код в файл именно в таком виде. Не беспокойтесь о том, что все это значит — позже в этом руководстве мы рассмотрим структуры более подробно.

        doctype html> html> head> meta charset="utf-8" /> title>Моя тестовая страницаtitle> head> body> img src="" alt="Моё тестовое изображение" /> body> html> 

        Моё тестовое изображение

      • Строка — это HTML код, который вставляет изображение на страницу. Мы должны сказать HTML, где находится изображение. Изображение находится внутри папки images, которая находится в той же директории что и index.html . Чтобы спуститься вниз по нашей файловой структуре от index.html до нашего изображения, путь к файлу должен выглядеть так images/your-image-filename . Например наше изображение, названное firefox-icon.png , имеет такой путь к файлу: images/firefox-icon.png .
      • Вставьте путь к файлу в ваш HTML код между двойными кавычками src=»» .
      • Сохраните ваш HTML файл, а затем загрузите его в вашем браузере (двойной щелчок по файлу). Вы должны увидеть вашу новую веб-страницу, отображающую ваше изображение!
      • A screenshot of our basic website showing just the firefox logo - a flaming fox wrapping the world

        Некоторые общие правила о путях к файлам:

        • Для ссылки на целевой файл в той же директории, что и вызывающий HTML файл, просто используйте имя файла, например, my-image.jpg .
        • Для ссылки на файл в поддиректории, напишите имя директории в начале пути, плюс косую черту (forwardslash, слеш), например: subdirectory/my-image.jpg .
        • Для ссылки на целевой файл в директории выше вызывающего HTML файла, напишите две точки. Например, если index.html находится внутри подпапки test-site , а my-image.png — внутри test-site , вы можете обратиться к my-image.png из index.html , используя ../my-image.png .
        • Вы можете комбинировать их так, как вам нравится, например ../subdirectory/another-subdirectory/my-image.png .

        На данный момент это все, что вам нужно знать

        Примечание: Файловая система Windows стремится использовать обратный слеш (backslash), а не косую черту (forwardslash), например C:\windows . Это не имеет значения, даже если вы разрабатываете веб-сайт на Windows, вы всё равно должны использовать обычные слеши в вашем коде.

        Что должно быть сделано?

        К настоящему моменту структура вашей папки должна выглядеть примерно так:

        A file structure in mac os x finder, showing an images folder with an image in, empty scripts and styles folders, and an index.html file

        Found a content problem with this page?

        • Edit the page on GitHub.
        • Report the content issue.
        • View the source on GitHub.

        This page was last modified on 2 дек. 2023 г. by MDN contributors.

        Your blueprint for a better internet.

        КАК СОЗДАТЬ ФАЙЛ CSS В HTML?

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

        Шаг 1: Создание нового файла CSS
        Первым шагом является создание нового файла CSS. В отличие от файлов HTML, файлы CSS обычно имеют расширение .css. Вы можете создать новый файл CSS с помощью любого текстового редактора или интегрированной среды разработки (IDE), такой как Visual Studio Code или Sublime Text.

        Шаг 3: Написание CSS-кода
        Теперь вы можете начать писать CSS в вашем файле styles.css. CSS состоит из набора правил, каждое из которых состоит из селектора и блока свойств. Селектор указывает, к каким элементам на странице мы хотим применить стили, а блок свойств содержит сами стили. Вот пример:

        /* styles.css */ h2 < color: red; >p

        В этом примере мы указали, что все заголовки первого уровня (h2) должны быть красного цвета, а все абзацы (p) должны иметь размер шрифта 16 пикселей и быть полужирными.

        Є питання? Запитай в чаті з ШІ! ВІДКРИТИ ЧАТ ЗІ ШТУЧНИМ ІНТЕЛЕКТОМ

        1. Какие еще способы подключения стилей CSS к HTML-странице существуют?
        2. Как я могу применить стили только к определенной части HTML-страницы?
        3. Каким образом я могу использовать изображения и шрифты вместе со стилями CSS?
        4. Как я могу создать адаптивный дизайн с помощью CSS?
        5. Какая разница между классами и идентификаторами в CSS и когда их следует использовать?

        Надеюсь, этот учебник помог вам понять, как создать файл CSS в HTML и использовать его для оформления вашей веб-страницы. Удачи в вашем дальнейшем путешествии веб-разработчика!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *