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

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

Теперь поговорим непосредственно о самой структуризации стилей.
Держать все стили в одном файле неразумно, со временем в нем довольно сложно становится ориентироваться. Плюс на каждой странице используются около 10% правил из этого файла, а весит он не мало.
Гораздо оптимальнее разделять стили по логическим блокам сайта.

Так же к проекту необходимо подключить библиотеку для работы с css (LESS, SASS, SCSS). Нам понадобится работа с переменными, функциями.
Для уменьшения запросов на сервер необходима сборка файлов. Файлы должны склеиваться по специальной конструкции, можно, например, использовать стандартную констукцию css - import . Здесь возможно потребуется помощь разработчика для редактирования исходников выбранной вами библиотеки css.
Плюс, для уменьшения объема, файлы должны приходить клиенту сжатые. dotLess , например, сжимает файлы при значении в web.config.

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

/css
/sources - папка для ресурсов, не выкладывается на сервер
/global-vars - файлы данной папки подключаются в каждый css-файл сборщик по мере необходимости
locals.css - глобальные переменные
functions.css - глобальные функции
/common
reset.css - думаю, объяснять не нужно, понятно, что за стили
utils.css - стили типа.clearfix
/content
base.css - основные стили для контента, а именно - h1-h6, p, буллиты для списков (ul.text, ul.dashed и т.д.), dl, dd, dt, изображения и панели в тексте (обтекание текстом), текстовые колонки и т.д.
panels.css - различные панели
tables.css - стили для таблиц в контенте (th, черезполосица)
/controls
buttons.css - виды кнопок
forms.css - общие стили для input-полей (к примеру, внутренняя тень, фокус (рамка), оформление валидационных сообщений и их скрытие по умолчанию)
tabs.css - табы, вкладки
system-notifications.css - системные сообщения, как правило бывают 3-х типов: success (зеленые), failure (красные) и info (серые, синие)
pager.css - пейджер
banners.css - баннеры на сайте
balloons.css - всякие баллуны, всплывающие подсказки, кастомные тултипы и т.д.
/member
thumb.css - аватарка пользователей
card.css - карточка пользователя (аватарка, имя, краткие данные)
cards-list.css - например, грид с карточками
profile.css - профиль пользователя
/modules - различные модули к сайту
search.css
news-list.css
gifts.css
games.css
/not-auth - для неавторизованных пользователей
login.css - форма авторизации
registration.css - форма регистрации
/auth - для авторизованных пользователей
my-account.css
mail-system.css - inbox сообщения, outbox и т.д.
auth-menu.css - меню навигации в авторизованной зоне
my-profile.css - просмотр своего профайла, редактирование
/layouts
common.css
header.css
top-menu.css
footer.css
overlay.css - например, все всплывающие поверх слои будут с затемнением 0.5
main.css - основной сборщик, линкуется на всех мастер-страницах
/layouts
default.css - основной layout сайта, собирает файлы из папки /layouts, подключается на мастере с основным layout"ом
popup-windows.css - стили для popup’ов, подключается на мастер-страницах для popup окон
not-auth.css - собирает стили из папки /sources/not-auth/
auth.css - собирает стили из папки /sources/auth/
/themes - различные тематики сайта
new-year.css
st-valentine.css
/%section-name% - какой-нибудь новый раздел сайта, «сайт в сайте», характерный наличием своего подменю и т.д.
/css
%section-name%.css
layout.css
/sources
menu.css

Конечно же для каждого проекта своя уникальная структура. Важен принцип разделения файлов.

Дополнительное описание к некоторым файлам:

main.css - собирает файлы из папок:
/sources/global-vars
/sources/common
/sources/content
/sources/controls
/sources/member
/sources/modules

functions.css - содержит глобальные функции, типа:

.rounded-corners(@radius)
{
border-radius: @radius;
-moz-border-radius: @radius;
-webkit-border-radius: @radius;
* behavior: url (/libs/progressive-IE.htc ) ;
}

sources/layouts/common.css - глобальные стили по layout"у:

.columns-wrapper
{
display : table;
* zoom: 1 ;
}
.columns-wrapper .column
{
display : table-cell ;
* float : left ;
}

Подключение файлов not-auth.css и auth.css зависит от состояния авторизации пользователя. Например, в asp.net это будет выглядеть так:

< asp:LoginView runat ="server" >
< AnonymousTemplate >
< link href ="/css/not-auth.css" rel ="stylesheet" type ="text/css" />

< LoggedInTemplate >
< link href ="/css/auth.css" rel ="stylesheet" type ="text/css" />

* This source code was highlighted with Source Code Highlighter .

Хочу привести концепцию, которой, я считаю, следует держаться.
Новые страницы должны строиться из компонентов, «кирпичиков» - css классов. Некоторые неверно понимают данную концепцию и строят страницу из классов типа mar-bottom-15 , float-left или pad-20 , что тоже является большой ошибкой.
На всем сайте должен сохраняться единый стиль элементов, т.е. заголовок h1 на одной странице должен выглядеть так же, как и h1 на другой. Заголовки, абзацы, списки, панели, табы, пейджеры, контентные таблицы и т.д. по дизайну должны соблюдать единый стиль.
Перед тем как писать стили для новой страницы сайта следует проанализировать уже существующие css-файлы проекта, возможно там уже есть необходимые стили. Css файл не должен увеличиваться без необходимости.

В заключении скажу, что все описанное выше так же актуально и для JS.

Адрес ссылки может быть как абсолютным, так и относительным. Абсолютные адреса должны начинаться с указания протокола (обычно http://) и содержать имя сайта. Относительные ссылки ведут отсчет от корня сайта или текущего документа.

В примере 8.2 показано создание абсолютной ссылки на другой сайт.

Пример 8.2. Использование абсолютных ссылок

Изучение HTML

При указании в качестве ссылки каталога сайта (например, http://сайт/css/), отображается индексный файл . Это файл, который загружается по умолчанию при обращении к каталогу без явного указания имени файла. Обычно в качестве индексного файла выступает документ с именем index.html .

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

Ссылки относительно текущего документа

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

1. Файлы располагаются в одной папке (рис. 8.4).

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

2. Файлы размещаются в разных папках (рис. 8.5).

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

Две точки в данном случае означают выйти из текущей папки на уровень выше.

3. Файлы размещаются в разных папках (рис. 8.6).

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

Ссылка

Аналогично обстоит дело с любым числом вложенных папок.

4. Файлы размещаются в разных папках (рис. 8.7).

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

Ссылка

Заметьте, что никаких дополнительных точек и слэшей перед именем папки нет. Если файл находится внутри не одной, а двух папок, то путь к нему записывается так.

Ссылка

Ссылки относительно корня сайта

Иногда можно встретить путь к файлу относительно корня сайта, он выглядит как "/Папка/Имя файла" со слэшем вначале. Так, запись Курсы означает, что ссылка ведет в папку с именем course, которая располагается в корне сайта, а в ней необходимо загрузить индексный файл.

Учтите, что такая форма записи не работает на локальном компьютере, а только под управлением веб-сервера.

Всем привет, друзья. Сегодня отвечу на простейший вопрос: “как подключить таблицу стилей css к html-страничке?”
Видео-версия статьи:

Для этого в содержимое тега нужно вставить следующую строку:

Поясняю: Тег link позволяет подключать к странице внешние файлы. Атрибут rel = “stylesheet” дает инструкции, что подключаемым файлом является именно таблица стилей. Href – это путь к файлу стилей. Как правило его значение “style.css” если таблица стилей называется именно так и лежит в одной папке с html-страничкой, для которой она подключается.

Как прописать путь к файлу

Соответственно, если css-файл лежит где-то в другом месте, то путь к нему прописывается по другому. Примеры, чтобы вам было понятней:
Файл table.css лежит в папке styles , которая находится в той же папке, что и html-страница: href = “styles/table.css”
Файл fonts.css лежит в папке styles , которая находится в папке css , а та в свою очередь находится там, где и html-страница: href = “styles/css/fonts.css”

Две точки позволяют в указании пути вернуться назад от изначального места (от места, где находится наша html-страничка). Так что дотянуться можно так:
Href = “../style.css” – файл лежит на один уровень выше html-файла.
Href = “../../style.css” – на два уровня выше.
Href = “../../../css/style.css” – на три уровня выше + сам файл стилей лежит еще и в папке css.
Надеюсь, этих простых примеров вам понятно, чтобы полностью разобраться с тем, как задать путь к файлу.

Устаревший атрибут

Раньше при подключении таблицы стилей нужно было также указывать в теге link атрибут type = “text/css” , но сегодня это уже не является обязательным требованием – браузеры и так прекрасно все понимают. Впрочем, для полноценной поддержки в старых браузерах можно перестраховаться и все же дописать его.

Дата публикации: 2018-03-27

От автора: работа над большими проектами сопряжена со сложностью работы с большим кодом в большой команде. Слишком часто я ловил себя на том, что не следую главным принципам разработки ПО типа DRY (не повторяться), KISS (все должно быть до глупости просто) и YAGNI (вам это не понадобится).

Учитывая эти проблемы, я начал использовать самые распространенные системы: OOCSS, SMACSS, ITCSS, ACSS и БЭМ - с их помощью создается приемлемая архитектура CSS.

На самом деле, я ценю все CSS архитектуры по некоторым причинам и не хочу искать идеальную. Я пришел к выводу, что лучшее то решение, которое реально работает для всех людей, работающих над ним. Решению далеко до human-friendly, если в нем есть слабости. Иногда мы легко теряемся в техниках и забываем, что за каждой строкой кода стоит человек. То, как мы пишем и организуем код, должно быть важным средством передачи полезной информации другим разработчикам, а не только техническим решением проблемы.

Из этого я делаю вывод, что установки соглашений уже недостаточно. Нужно также принять соглашение, ориентированное на пользователя. Все это значит:

Избегайте избыточной сложности

Объясняйте и делайте синтаксис класса легкочитаемым

Следуйте порядку и соблюдайте чистоту

Попробуйте создать гибкую модель, способную изменяться и развиваться, когда людям это потребуется

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

Как расшифровывается UFOCSS?

Несмотря на схожесть названия, UFOCSS расшифровывается как User Friendly Oriented CSS. Это не методология пришельцев и не новый способ представления масштабируемой и модульной CSS архитектуры. Это попытка сосредоточиться на самой «человеческой» части того, что мы уже ценим. К чему это ведет? Давайте разбираться!

Мне кажется, что здесь нужно работать над крупным веб-проектом, где в разработке используются SCSS и PostCSS. Так CSS код можно разбить на категории и организовать в маленькие логические единицы, разделив код по множеству папок и файлов, которые ссылаются друг на друга через директиву @import. Далее билд система использует файлы и скомпилирует их в один файл стилей для продакшена и сохранит его в папку назначения.

В общем, каталог стилей может быть таким:

Как видите, код разбит на 2 главные папки: abstracts и modules. Это помогает поддерживать структуру папок в чистоте и порядке, не создавая дополнительные папки, которые не так уж и нужны.

Названия папок можете выбрать какие угодно (т.е. tools для abstracts и patterns или layers для modules). Я использую соглашение о сортировке папок в алфавитном и числовом порядке. Такое соглашение действительно полезно при работе с языками, в основе которых лежит каскадирование и принципы наследования.

Упорядочение файлов и папок в алфавитном и числовом порядке дает пользователям четкий визуальный индикатор того, что в коде идет первым, что, в свою очередь, определяется принципами специфичности.

Если представить проект, как слоёный бисквит, то:

вы не можете делать верхние слои, если нет первого

когда все ингредиенты используются в равном количестве, лучше всего ощущаются ингредиенты на верхнем слое пирога (каскадирование)

если в нижнем слое использовать много шоколадной крошки, то все остальные слои не так ощутимы, шоколад будет перебивать остальные вкусы! (специфичность)

Папка abstract: здесь живут инструменты

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

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

Abstracts – это ингредиенты и инструменты, необходимые для старта и ускорения разработки, как переменные, функции и миксины. Они не влияют на внешний вид и вкус пирога, но определяют способ создания и поддержки. Никому они не нужны кроме вас и вашей команды!

Все файлы abstracts говорят сами за себя. Просто учтите, что я беру все, что нужно широко использовать из файла _variables – цвета, шрифты, grid и z-index. Я считаю, так всем легче понять, какие инструменты нам нужны.

Например, файл z-index управляет вертикальным порядком элементов. Хорошая практика управления z-index в сложных макетах – установка нескольких Sass списков, в которых описано, в каком порядке мы хотим выводить элементы, от низшего к высшему.

Учтите, что для создания нового контекста стека необходимо модальное окно. Можно просто создать новый Sass список в файле z-index:

$modal-elements: fields, form-controls, alerts, autocomplete-dropdown;

$ modal - elements : fields , form - controls , alerts , autocomplete - dropdown ;

Этот Sass список – просто инструмент, помогающий безопасно управлять порядком стека элементов, он не генерирует CSS правила.

Использовать этот инструмент, получить значение z-index и присвоить его всем элементам можно через Sass функцию index() внутри корректного файла module, как показано ниже:

Modal-alerts { z-index: index($modal-elements, alerts); .... }

Modal - alerts { z - index : index ($ modal - elements , alerts ) ; . . . .

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

Папка modules: здесь живут слои

Принцип действия в соответствии с уровнями возрастающей сложности и специфичности позволяет нам добавить второй кирпичик в стену CSS – это определение слоев CSS.

Слой abstracts, рассмотренный ранее, можно считать нулевым. После создания всех необходимых инструментов и «ингредиентов» можно начать писать стили нашего проекта через прогрессивные слои абстракции (о них ниже).

Определение слоев абстракции поможет нам систематически создавать модульные стили, которые будут оставаться единообразными, масштабируемыми и обслуживаемыми по мере роста проекта и его изменения со временем. Поэтому я сгруппировал их в папке modules, как в SMACSS. Это дает идею коллекции шаблонов, некие части лего с разной областью применения, которые можно использовать повторно. Модули представляют собой набор правил, которые можно повторно применять в проекте – повторяющиеся и стандартизированные единицы. Они представляют реальной ядро проекта, так как именно с них начинается вывод реальных CSS правил.

Использование префиксов для простого определения области применения класса – хорошая практика, которую принимают главные системы архитектуры CSS типа SMACSS и ITCSS. Детально о соглашении об именовании я расскажу в следующей статье, а сейчас просто учтите, что я также буду использовать префиксы в названиях файлов. Это можно достичь:

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

Все точно знают, для чего используется файл

Используемые префиксы отсортированы в алфавитном порядке. То есть они показаны в том порядке, в котором импортированы, что подчиняется принципу специфичности (сначала идет основа, затем макеты, объекты, утилиты и вендорные слои)

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

Я пытаюсь упростить структуру папок, уменьшив и переименовав слои, представленные ITCSS: Settings, Tools, Generic, Elements, Objects, Components and Trumps.

Мне удобно сгруппировать переменные, функции и миксины в один слой Abstracts, а не разбивать их между Settings и Tools

Generic и Elements можно объединить в слой Base, так как оба включают самые базовые и низко специфичные классы

Я предпочитаю переименовывать слой Objects в Layout – самый понятный слой, так как он используется для некосметических классов

Components я переименую в Objects, так как этот слой можно использовать также для более атомных элементов

Trumps используется для утилит, поэтому я просто назову слой Utility

Если есть необходимость, вам никто не запрещает добавить дополнительный слой типа templates. Этот слой можно использовать для правил, которые уникально применяются в каких-то шаблонах. Я бы в таком случае использовал префикс _t_. Или же можно использовать следующие слои.

Слой bases

Это первый слой, который генерирует реальные CSS правила. Здесь располагаются стили reset или normalize, глобальные правила типа box-sizing и стили для текстовых HTML тегов. Я также думаю, что на этом уровне моно разместить некоторые хелпер-классы, строго относящиеся к HTML тегам типа.h1, .small, .mark – это пригодится, когда между стилем и семантикой нет соответствия.

Здесь можно разместить правила шрифтов, как показано ниже:

h1, .h1-like { font: { family: $font-primary; weight: bold; size: 2rem; } text-transform: uppercase; ...... }

h1 , . h1 - like { font : { family : $ font - primary ; weight : bold ; size : 2rem ; text - transform : uppercase ; . . . . . .

Я бы включил эти правила в файл _b_typography.scss. Префикс _b_ расшифровывается как base.

Слой layouts

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

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

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

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

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

Представьте, что ваш клиент хочет разместить до 6 блоков в строке. Это никак не относится к дизайну всех элементов, поэтому можно создать файл _l_columns.scss, который работает только с размещением определенных блоковых элементов.

$min-cols: 2; $max-cols: 6; .l_columns-1 { display: grid; grid-row-gap: 30px; grid-column-gap: 30px; } @for $i from $min-cols through $max-cols { .l_columns-#{$i} { @extend .l_columns-1; grid-template-columns: repeat($i, 1fr); } }

$ min - cols : 2 ; $ max - cols : 6 ; L_columns - 1 { display : grid ; grid - row - gap : 30px ; grid - column - gap : 30px ; @ for $ i from $ min - cols through $ max - cols {

Продолжаем тему прошлого урока, где мы немного попытались понять, что же такое CSS. Прежде всего, нам необходимо создать файл со стилями, и сохранить его рядом с нашим файлам HTML. Но поскольку, в процессе создания сайта файлов, с расширением CSS может быть несколько, то лучше создать, для них отдельную папку. И так открываем ту папку, где хранится наш файл index.html, в открытой папке создаём папку и называем её «CSS», так нам легче будет понять, что здесь хранится. Далее открываем редактор «Notepad++» Файл > Новый, и сохраняем документ под именем «STYLE» с расширением «CSS», то есть должно получиться вот так, style.css. И у нас появляется две папки и один индексный файл.

Рисунок № 1.

Подключаем CSS к HTML.

Для того что бы наш фай style.css смог взаимодействовать с файлом index.html, необходимо меду тегами «HEAD» разместить, код вот такой строки:

Первым что мы видим это тег который переводится как «канал связи», то есть мы говорим браузеру сейчас будет произведено подключение документа, далее атрибут rel (relation- отношение) и stylesheet (стилям). То есть данный канал связи имеет отношения к стилям. Затем «type», то есть тип документа "text/css" и завершающим ответственным этапом здесь является сама ссылка на подключаемый файл, href="css/style.css", где указываем имя созданной папки со стилями и сам стилевой файл.

Рисунок № 2.

Переносим стили с HTML в CSS.

На предыдущих занятиях, мы с вами практически создали стили, на всей нашей странички HTML. Теперь эти готовые стили нам необходимо перенести в файл style.css, и начнём с тега BODY, где у нас указан фон нашего шаблона. В файле CSS пишем следующее body{}, где BODY является селектором тегов, а фигурные скобки это то место где будут размещаться стилевые правила для данного тега. Теперь в файле index.html, где после тега BODY идёт атрибут style, копируем всё то содержимое что идёт между двойных кавычек и вставляем в css. Немного подровняв, должно получиться вот так:

Body{ background-image: url("images/fon.jpg"); background-attachment: fixed; }

В файле index.html удаляем лишний код в теги BODY, что бы он остался вот таким чистым , как будто мы его только создали. Сохраняем изменения в документе и идём к просмотру в браузере. Если всё сделали правильно, то фон нашей страницы должен исчезнуть, произошло это, потому что браузер не может найти путь к изображению. Давайте найдём причину ошибки. Обратите внимание на верхний код, браузер заходит и читает, что фон должен быть изображением, далее url, то есть путь и он видит. Что в папке, в которую он вошёл, должна быть папка images и в ней файл fon.jpg, вроде всё правильно. Но всё дело в том, что браузер вошёл в папку CSS а в этой директории у нас нет никакой папки images и мы должны сказать браузеру начинай поиск с корневой папки, то есть основной. Для этого следует указать браузеру отступ на один шаг назад, вот таким образом (../) две точки, и косой слеш. Если бы наш файл style.css находился ещё глубже на одну папку то пришлось бы указать возврат на две директории, то есть продублировать (../../). В общем, постарайтесь это понять и запомнить, чтобы отличать пути для файлов и документов, как прямые и вложенные. В данном случае файл style.css вложенный и не может иметь прямых путей, для документов.

Body{ background-image: url("../images/fon.jpg"); background-attachment: fixed; }

После исправления этого пути, всё должно заработать и наш фон появится. На этом я предлагаю закончить данный урок, а вы в качестве домашнего задания протестируйте, моменты вложенности папок и пути к файлам. То есть создайте ещё одну папку, например с именем «STYLES» вложите туда папку «CSS» вместе с документом style.css и задайте правильный путь к изображению, что бы всё заработало.

А я жду вас в следующем уроке «Простая вёрстка в HTML + CSS. Урок №11», где мы займёмся переносом всех оставшихся стилей и сравним разницу и преимущество «CSS», при его использование.

Обслуживание