Sa post na ito ay magbibigay ako ng isang halimbawa kung paano ayusin ang mga estilo sa isang tipikal na proyekto.

Isang maikling panimula, susubukan kong ipaliwanag ang kaugnayan ng problema at kung bakit ito kinakailangan.
Isaalang-alang natin ang sitwasyong ito. Ang developer ay binibigyan ng gawain ng pagpapatupad ng susunod na pag-andar sa site. Kabilang dito ang pagdaragdag ng mga bagong seksyon, mga bloke, mga elemento. Kadalasan ay hindi nagtitiwala ang mga developer sa code ng ibang tao, at kapag nakarating na sila sa layout, makakahanap sila ng css file na may pangalan tulad ng main.css at idinagdag ang kanilang mga bagong istilo sa dulo.
Lumipas ang ilang oras, dumating ang isang bagong developer, binibigyan siya ng katulad na gawain, kahit na sinusubukan niyang maunawaan ang mga estilo, nakikita niya na walang pattern doon, at inuulit ang ginawa ng mga nauna.
Ang pamamahala ay nagtatakda ng mga deadline, parami nang parami ang mga bagong pag-andar ay binuo, at ang proyekto ay lumalaki. Bilang resulta, nagiging basurahan ang mga css file, mas matagal mag-load ang site, mas maraming depekto ang lalabas, atbp.
Sa tingin ko maraming tao ang pamilyar dito.

Ngayon ay direktang pag-usapan natin ang tungkol sa pagbubuo ng mga estilo mismo.
Ito ay hindi matalino upang panatilihin ang lahat ng mga estilo sa isang file sa paglipas ng panahon, ito ay nagiging medyo mahirap na mag-navigate. Dagdag pa, gumagamit ang bawat pahina ng humigit-kumulang 10% ng mga panuntunan mula sa file na ito, at medyo tumitimbang ito.
Mas mainam na paghiwalayin ang mga istilo sa mga lohikal na bloke ng site.

Kailangan mo ring ikonekta ang isang library para sa pagtatrabaho sa css (LESS, SASS, SCSS) sa proyekto. Kakailanganin nating magtrabaho kasama ang mga variable at function.
Upang bawasan ang mga kahilingan sa server, kailangan ang pagpupulong ng file. Ang mga file ay dapat na nakadikit nang magkasama gamit ang isang espesyal na konstruksiyon, halimbawa, maaari mong gamitin ang karaniwang css - pag-import ng konstruksiyon. Dito maaaring kailanganin mo ang tulong ng isang developer upang i-edit ang mga pinagmumulan ng css library na iyong pinili.
Dagdag pa, upang mabawasan ang lakas ng tunog, ang mga file ay dapat na maihatid sa kliyente na naka-compress. Ang dotLess, halimbawa, ay nag-compress ng mga file kapag nakatakda sa sa web.config.

Ang bawat lohikal na bloke ay magkakaroon ng hiwalay na css file. Ginagawa nitong mas madaling suportahan, hanapin ang mga tamang istilo, at sa pangkalahatan ay mag-navigate sa mga file. Ang lahat ng mga file na ito ay mga mapagkukunan, ilalagay namin ang mga ito sa /css/sources/ folder. Ang mga natitirang css file ay mga collectors, sila ay naka-link sa mga page at kinokolekta sa pamamagitan ng pag-import ng mga source code.
Sabihin nating ang proyektong isinasaalang-alang ay isang uri ng social network, batay dito maaari nating makilala ang sumusunod na istraktura:

/css
/sources - folder para sa mga mapagkukunan, hindi na-upload sa server
/global-vars - Ang mga file sa folder na ito ay kasama sa bawat css file ng kolektor kung kinakailangan
locals.css - mga pandaigdigang variable
functions.css - mga pandaigdigang pag-andar
/karaniwan
reset.css - Sa tingin ko hindi na kailangang ipaliwanag, malinaw kung ano ang mga istilo
utils.css - mga istilo tulad ng .clearfix
/nilalaman
base.css - mga pangunahing istilo para sa nilalaman, ibig sabihin - h1-h6, p, mga bala para sa mga listahan (ul.text, ul.dashed, atbp.), dl, dd, dt, mga larawan at mga panel sa text (text wrapping), text speaker, atbp .
panels.css - iba't ibang mga panel
tables.css - mga istilo para sa mga talahanayan sa nilalaman (ika, may guhit)
/kontrol
buttons.css - mga uri ng mga pindutan
forms.css - pangkalahatang mga estilo para sa mga patlang ng pag-input (halimbawa, panloob na anino, focus (frame), pag-istilo ng mga mensahe ng pagpapatunay at pagtatago ng mga ito bilang default)
tabs.css - mga tab, mga tab
system-notifications.css - Ang mga mensahe ng system ay karaniwang may 3 uri: tagumpay (berde), kabiguan (pula) at impormasyon (kulay abo, asul)
pager.css - pager
banners.css - mga banner sa site
balloons.css - lahat ng uri ng mga lobo, tooltip, custom na tooltip, atbp.
/miyembro
thumb.css - avatar ng gumagamit
card.css - user card (avatar, pangalan, maikling impormasyon)
cards-list.css - halimbawa, isang grid na may mga card
profile.css - profile ng gumagamit
/ mga module - iba't ibang mga module para sa site
paghahanap.css
news-list.css
mga regalo.css
laro.css
/not-auth - para sa mga hindi awtorisadong gumagamit
login.css - form ng pahintulot
pagpaparehistro.css - form ng pagpaparehistro
/auth - para sa mga awtorisadong gumagamit
my-account.css
mail-system.css - mga mensahe sa inbox, outbox, atbp.
auth-menu.css - menu ng nabigasyon sa awtorisadong lugar
my-profile.css - pagtingin sa iyong profile, pag-edit
/mga layout
karaniwan.css
header.css
top-menu.css
footer.css
overlay.css - halimbawa, lahat ng layer na lalabas sa itaas ay magkakaroon ng darkness na 0.5
main.css - pangunahing kolektor, naka-link sa lahat ng master page
/mga layout
default.css - pangunahing layout ng site, nangongolekta ng mga file mula sa /layouts folder, kumokonekta sa master gamit ang pangunahing layout
popup-windows.css - mga istilo para sa mga popup, konektado sa mga master page para sa mga popup window
hindi-auth.css - nangongolekta ng mga istilo mula sa /sources/not-auth/ folder
auth.css - nangongolekta ng mga istilo mula sa /sources/auth/ folder
/mga tema - iba't ibang mga paksa ng site
bagong-taon.css
st-valentine.css
/%section-name% - ilang bagong seksyon ng site, isang "site sa loob ng isang site", na nailalarawan sa pagkakaroon ng sarili nitong submenu, atbp.
/css
%section-name%.css
layout.css
/sources
menu.css

Siyempre, ang bawat proyekto ay may sariling natatanging istraktura. Ang prinsipyo ng paghihiwalay ng file ay mahalaga.

Karagdagang paglalarawan para sa ilang mga file:

main.css- nangongolekta ng mga file mula sa mga folder:
/sources/global-vars
/sources/common
/sources/content
/sources/controls
/sources/miyembro
/sources/modules

functions.css- naglalaman ng mga pandaigdigang function, tulad ng:

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

source/layouts/common.css- mga pandaigdigang istilo para sa layout:

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

Pagkonekta ng mga file hindi-auth.css At auth.css depende sa katayuan ng awtorisasyon ng user. Halimbawa, sa asp.net magiging ganito ang hitsura:

< 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" />

* Ang source code na ito ay na-highlight gamit ang Source Code Highlighter.

Nais kong bigyan ka ng isang konsepto na sa tingin ko ay dapat sundin.
Ang mga bagong pahina ay dapat na binuo mula sa mga bahagi, "mga bloke ng gusali" - mga klase ng css. Ang ilang mga tao ay hindi maunawaan ang konseptong ito at bumuo ng isang pahina mula sa mga klase tulad ng mar-bottom-15, lumutang-kaliwa o pad-20, na isa ring malaking pagkakamali.
Ang buong site ay dapat magpanatili ng isang solong istilo ng mga elemento, i.e. Ang h1 na heading sa isang page ay dapat magmukhang kapareho ng h1 sa kabilang page. Mga heading, talata, listahan, panel, tab, pager, talahanayan ng nilalaman, atbp. ang disenyo ay dapat sumunod sa isang solong estilo.
Bago magsulat ng mga istilo para sa isang bagong pahina ng website, dapat mong suriin ang mga kasalukuyang file ng CSS ng proyekto, marahil ay mayroon nang mga kinakailangang istilo. Ang CSS file ay hindi dapat lumaki nang hindi kinakailangan.

Sa konklusyon, sasabihin ko na ang lahat ng inilarawan sa itaas ay may kaugnayan din para sa JS.

Na isasaalang-alang natin ngayon sa pagkakasunud-sunod.

Tulad ng sinabi ko kanina, ang css ay idinisenyo upang magdisenyo ng mga istruktura ng html, iyon ay, bigyan sila ng hitsura, kulay, laki, lokasyon, at iba pa, at samakatuwid ay direktang nakakaimpluwensya sa html code.

Upang matiyak ang epektong ito, ang isang css na koneksyon ay ginawa sa html na dokumento.

Ang unang paraan upang isama ang css ay mga naka-link na istilo. Ito ay ginagamit kapag ang style sheet ay nakasulat sa isang hiwalay na file.

Sa kasong ito, ang style.css file na may style sheet ay konektado sa html file sa head tag, gamit ang link tag

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

ang link ay iisang tag;

href – isang link attribute na pamilyar sa amin, css/stile.css – isang value na nagsasaad ng path patungo sa file, at ang pangalan ng file;

uri – isang katangian na nagsasaad ng uri ng elementong ikokonekta, sa aming kaso ito ay text/css;

Ang rel ay isang katangian na tumutukoy sa isang relasyon, at ang halaga nito ay karaniwang nakasulat na stylesheet;

Sa code na ito, kadalasan ang value lang ng style.css (ang pangalan ng kasamang talahanayan) ang nagbabago. Ang mga talahanayan ay konektado.

Ngayon ay ipapakita ng browser ang html file sa form na isusulat para dito sa style.css file.

Sa pamamagitan ng paraan, para sa hinaharap. Maaari mong ikonekta ang maraming mga style sheet hangga't gusto mo sa isang html file. Lahat ng mga ito ay kasama sa head tag.

At, kung ano ang ginagamit nang mas madalas, sa kabaligtaran, ang isang talahanayan ay maaaring konektado sa maraming mga html na file.

Ito ang gustong paraan upang isama ang mga style sheet, dahil lahat sila ay nasa isang file at samakatuwid ay mas madaling tukuyin.

At gayundin, kung kailangan mong baguhin ang istilo ng ilang elemento ng parehong uri, magiging mas madaling gawin ito kung kinokolekta ang mga ito sa isang tagapili ng grupo.

Ang katotohanan ay ang isa sa mga gawain ng webmaster ay upang bawasan ang dami ng code habang pinapanatili ang parehong panghuling resulta, at isang hiwalay na style.css file ang ganap na nakakatugon sa kinakailangang ito.

Isipin na lang, upang magsulat ng pamagat para sa isang artikulo, kailangan mong itakda ang laki, kulay, font at, posibleng, ilang iba pang mga estilo. At kaya para sa bawat post.

Sa style.css file, maaari kang magtakda ng mga istilo nang isang beses, ngunit para sa lahat ng pamagat ng post sa site.

Ngayon naiintindihan mo na ba ang pagkakaiba?

Gayunpaman, ang iba pang mga paraan ng pagkonekta ng mga istilo ay may karapatang umiral, kaya tingnan natin ang mga ito at ang mga sitwasyon kung saan ginagamit ang mga ito.

Ang pangalawang paraan upang kumonekta sa css ay mga global na istilo ay nagbibigay-daan sa iyo upang kumonekta (maglagay) ng isang style sheet nang direkta sa isang html file.

Ginagawa ito gamit ang style tag, at ito ay nakasulat sa parehong paraan tulad ng sa unang kaso sa head tag.

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

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

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

Третий способ подключения css — внутренние стили позволяет прописывать стили прямо внутри html тега.

Реализуется он при помощи атрибута style , который не стоит путать с одноимённым тегом.

Применяется он тогда, когда нужно оформить только один элемент контента.

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

Дата публикации: 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 {