Katika chapisho hili nitatoa mfano wa jinsi ya kuandaa mitindo kwenye mradi wa kawaida.

Utangulizi mfupi, nitajaribu kuelezea umuhimu wa tatizo na kwa nini inahitajika.
Hebu fikiria hali hii. Msanidi anapewa kazi ya kutekeleza utendaji unaofuata kwenye tovuti. Hii inajumuisha kuongeza sehemu mpya, vizuizi, vipengele. Wasanidi programu mara nyingi hawaamini msimbo wa watu wengine, na wanapofika kwenye mpangilio, hupata faili ya css yenye jina kama main.css na kuongeza mitindo yao mipya hadi mwisho.
Wakati fulani hupita, msanidi mpya anakuja, anapewa kazi sawa, hata akijaribu kuelewa mitindo, anaona kwamba hakuna muundo huko, na kurudia yale yaliyotangulia.
Usimamizi huweka tarehe za mwisho, utendakazi mpya zaidi na zaidi unatengenezwa, na mradi unakua. Matokeo yake, faili za css hugeuka kwenye takataka, tovuti inachukua muda mrefu kupakia, kasoro zaidi huonekana, nk.
Nadhani watu wengi wanalijua hili.

Sasa hebu tuzungumze moja kwa moja juu ya muundo wa mitindo yenyewe.
Sio busara kuweka mitindo yote katika faili moja; baada ya muda, inakuwa ngumu sana kuvinjari. Zaidi ya hayo, kila ukurasa hutumia takriban 10% ya sheria kutoka kwa faili hii, na ina uzito kidogo.
Ni bora zaidi kutenganisha mitindo katika vizuizi vya kimantiki vya tovuti.

Pia unahitaji kuunganisha maktaba ya kufanya kazi na css (LESS, SASS, SCSS) kwenye mradi. Tutahitaji kufanya kazi na vigezo na kazi.
Ili kupunguza maombi kwa seva, mkusanyiko wa faili ni muhimu. Faili lazima ziunganishwe kwa kutumia muundo maalum, kwa mfano, unaweza kutumia kiwango cha css - ujenzi wa kuagiza. Hapa unaweza kuhitaji usaidizi wa msanidi programu ili kuhariri vyanzo vya maktaba ya css uliyochagua.
Zaidi, ili kupunguza sauti, faili lazima ziwasilishwe kwa mteja zilizoshinikizwa. dotLess, kwa mfano, inabana faili inapowekwa katika web.config.

Kila kizuizi cha kimantiki kitakuwa na faili tofauti ya css. Hii hurahisisha usaidizi, kupata mitindo inayofaa, na kwa ujumla kuvinjari faili. Faili hizi zote ni vyanzo, tutakuwa nazo kwenye /css/sources/ folda. Faili za css zilizobaki ni wakusanyaji, zimeunganishwa kwenye kurasa na kukusanywa kwa kuleta misimbo ya chanzo.
Wacha tuseme mradi unaozingatiwa ni aina fulani ya mtandao wa kijamii, kwa msingi wa hii tunaweza kutofautisha muundo ufuatao:

/css
/vyanzo - folda ya rasilimali, haijapakiwa kwenye seva
/global-vars - faili kwenye folda hii zimejumuishwa katika kila faili ya css ya mkusanyaji inavyohitajika
wenyeji.css - vigezo vya kimataifa
kazi.css - kazi za kimataifa
/kawaida
weka upya.css - Nadhani hakuna haja ya kuelezea, ni wazi ni mitindo gani
utils.css - mitindo kama .clearfix
/maudhui
msingi.css - mitindo ya kimsingi ya yaliyomo, ambayo ni - h1-h6, p, vitone vya orodha (ul.text, ul.dashed, nk.), dl, dd, dt, picha na paneli katika maandishi (ufungaji wa maandishi), wasemaji wa maandishi, nk. .
paneli.css - paneli mbalimbali
meza.css - mitindo ya meza katika yaliyomo (th, striped)
/vidhibiti
vitufe.css - aina ya vifungo
fomu.css - mitindo ya jumla ya sehemu za ingizo (kwa mfano, kivuli cha ndani, lengo (fremu), mtindo wa ujumbe wa uthibitishaji na kuzificha kwa chaguo-msingi)
tabo.css - tabo, tabo
arifa za mfumo.css - ujumbe wa mfumo huwa wa aina 3: mafanikio (kijani), kushindwa (nyekundu) na maelezo (kijivu, bluu)
paja.css - paja
mabango.css - mabango kwenye tovuti
puto.css - kila aina ya puto, vidokezo vya zana, vidokezo maalum, nk.
/mwanachama
kidole gumba.css - avatar ya mtumiaji
kadi.css - kadi ya mtumiaji (avatar, jina, habari fupi)
orodha ya kadi.css - kwa mfano, gridi ya taifa na kadi
wasifu.css - wasifu wa mtumiaji
/moduli - modules mbalimbali kwa ajili ya tovuti
search.css
orodha ya habari.css
zawadi.css
michezo.css
/si-mwandishi - kwa watumiaji wasioidhinishwa
login.css - fomu ya idhini
usajili.css - fomu ya usajili
/auth - kwa watumiaji walioidhinishwa
akaunti-yangu.css
barua-mfumo.css - ujumbe wa kikasha, kikasha toezi, n.k.
auth-menu.css - menyu ya urambazaji katika eneo lililoidhinishwa
my-profile.css - kutazama wasifu wako, kuhariri
/miundo
kawaida.css
kichwa.css
top-menu.css
kijachini.css
funika.css - kwa mfano, tabaka zote zinazojitokeza juu zitakuwa na giza la 0.5
kuu.css - mtoza mkuu, aliyeunganishwa kwenye kurasa zote za bwana
/miundo
default.css - mpangilio kuu wa tovuti, hukusanya faili kutoka kwa folda / mipangilio, huunganisha kwa bwana na mpangilio kuu
ibukizi-windows.css - Mitindo ya madirisha ibukizi, iliyounganishwa kwenye kurasa kuu za madirisha ibukizi
not-auth.css - hukusanya mitindo kutoka kwa /source/not-auth/ folda
auth.css - hukusanya mitindo kutoka kwa /source/auth/ folda
/mandhari - mada mbalimbali za tovuti
mwaka mpya.css
st-valentine.css
/%section-name% - sehemu mpya ya tovuti, "tovuti ndani ya tovuti", inayojulikana na uwepo wa menyu yake ndogo, nk.
/css
%section-name%.css
mpangilio.css
/vyanzo
menyu.css

Bila shaka, kila mradi una muundo wake wa kipekee. Kanuni ya kutenganisha faili ni muhimu.

Maelezo ya ziada kwa baadhi ya faili:

kuu.css- hukusanya faili kutoka kwa folda:
/vyanzo/global-vars
/vyanzo/kawaida
/vyanzo/maudhui
/vyanzo/vidhibiti
/vyanzo/mwanachama
/vyanzo/moduli

kazi.css- ina kazi za kimataifa, kama vile:

.pembe-mviringo(@radius)
{
mpaka-radius: @radius;
-moz-mpaka-radius: @radius;
-radius-ya-mpakani-webkit: @radius;
* tabia: url (/libs/progressive-IE.htc ) ;
}

vyanzo/mipangilio/common.css- mitindo ya kimataifa ya mpangilio:

.karatasi-nguzo
{
kuonyesha: meza;
* zoom: 1;
}
.columns-wrapper .safu
{
kuonyesha: meza-kiini;
* kuelea: kushoto;
}

Kuunganisha faili not-auth.css Na auth.css inategemea hali ya idhini ya mtumiaji. Kwa mfano, katika asp.net ingeonekana kama hii:

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

* Msimbo huu wa chanzo uliangaziwa kwa Kiangazia Chanzo cha Msimbo.

Ningependa kukupa dhana ambayo nadhani inapaswa kufuatwa.
Kurasa mpya zinapaswa kujengwa kutoka kwa vipengele, "vitalu vya ujenzi" - madarasa ya css. Watu wengine hawaelewi dhana hii na huunda ukurasa kutoka kwa madarasa kama mar-chini-15, kuelea-kushoto au pedi-20, ambayo pia ni kosa kubwa.
Tovuti nzima lazima ihifadhi mtindo mmoja wa vipengele, i.e. Kichwa cha h1 kwenye ukurasa mmoja kinapaswa kuonekana sawa na h1 kwa upande mwingine. Vichwa, aya, orodha, paneli, vichupo, vipeja, majedwali ya maudhui, n.k. kubuni lazima kuambatana na mtindo mmoja.
Kabla ya kuandika mitindo ya ukurasa mpya wa tovuti, unapaswa kuchanganua faili zilizopo za css za mradi; labda mitindo muhimu tayari iko. Faili ya CSS haipaswi kukua bila lazima.

Kwa kumalizia, nitasema kwamba kila kitu kilichoelezwa hapo juu pia kinafaa kwa JS.

Ambayo sasa tutazingatia kwa utaratibu.

Kama nilivyosema hapo awali, css imeundwa kubuni miundo ya html, ambayo ni, kuwapa mwonekano, rangi, saizi, eneo, na kadhalika, na kwa hivyo huathiri moja kwa moja msimbo wa html.

Ili kuhakikisha athari hii, muunganisho wa css unafanywa kwa hati ya html.

Njia ya kwanza ya kujumuisha css ni mitindo iliyounganishwa. Inatumika wakati karatasi ya mtindo imeandikwa katika faili tofauti.

Katika hali hii, faili ya style.css iliyo na laha ya mtindo imeunganishwa kwenye faili ya html kwenye lebo ya kichwa, kwa kutumia lebo ya kiungo.

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

kiungo ni tag moja;

href - sifa ya kiungo tunayoifahamu, css/stile.css - thamani inayoonyesha njia ya faili, na jina la faili;

aina - sifa inayoonyesha aina ya kipengele cha kuunganishwa, kwa upande wetu ni maandishi / css;

rel ni sifa inayofafanua uhusiano, na thamani yake kwa kawaida ni laha ya mtindo iliyoandikwa;

Katika msimbo huu, kwa kawaida tu thamani ya style.css (jina la jedwali lililounganishwa) hubadilika. Majedwali yameunganishwa.

Sasa kivinjari kitaonyesha faili ya html katika fomu ambayo itaandikwa kwa ajili yake katika faili ya style.css.

Kwa njia, kwa siku zijazo. Unaweza kuunganisha laha nyingi za mtindo upendavyo kwa faili moja ya html. Zote zimejumuishwa kwenye lebo ya kichwa.

Na, ni nini kinachotumiwa mara nyingi zaidi, kinyume chake, meza moja inaweza kushikamana na faili nyingi za html.

Hii ndiyo njia inayopendekezwa zaidi ya kujumuisha karatasi za mtindo, kwa kuwa zote ziko kwenye faili moja na kwa hiyo ni rahisi kufafanua.

Na pia, ikiwa unapaswa kubadili mtindo wa vipengele kadhaa vya aina moja, itakuwa rahisi zaidi kufanya hivyo ikiwa hukusanywa katika kichaguzi cha kikundi kimoja.

Ukweli ni kwamba mojawapo ya kazi za msimamizi wa tovuti ni kupunguza kiasi cha msimbo huku ukidumisha matokeo sawa ya mwisho, na faili tofauti ya style.css inakidhi mahitaji haya kikamilifu.

Hebu fikiria, kuandika kichwa cha makala, unahitaji kuweka ukubwa wake, rangi, font na, ikiwezekana, mitindo mingine. Na hivyo kwa kila chapisho.

Katika faili ya style.css, unaweza kuweka mitindo mara moja, lakini kwa mada zote za machapisho kwenye tovuti.

Sasa unaelewa tofauti?

Hata hivyo, mbinu nyingine za kuunganisha mitindo zina haki ya kuwepo, kwa hiyo hebu tuziangalie na hali ambazo zinatumiwa.

Njia ya pili ya kuunganisha css ni mitindo ya kimataifa hukuruhusu kuunganisha (weka) laha ya mtindo moja kwa moja kwenye faili ya html.

Hii imefanywa kwa kutumia lebo ya mtindo, na imeandikwa kwa njia sawa na katika kesi ya kwanza kwenye kichwa cha kichwa.

Как видите, таблица стилей расположена прямо в 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 {