Структура на папки и елементи. Абсолютни и относителни връзки Свържете CSS файл вътре към файл от същия тип

Здравейте на всички, приятели. Днес ще отговоря прост въпрос: „как да свържа css стилов лист към html страница?“
Видео версия на статията:

За да направите това, трябва да вмъкнете в съдържанието на етикета следващ ред:

Нека обясня: тагът за връзка ви позволява да се свържете към страницата външни файлове. Атрибутът 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.
Надявам се тези прости примериразбирате, за да разберете напълно как да зададете пътя до файла.

Отхвърлен атрибут

Преди това, когато свързвате стилов лист, също беше необходимо да посочите атрибута type = „text/css“ в етикета за връзка, но днес това вече не е задължително изискване - браузърите вече разбират всичко отлично. Въпреки това, за пълна поддръжка в по-стари браузъри, можете да играете на сигурно и все пак да го добавите.

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

Кратко въведение, ще се опитам да обясня уместността на проблема и защо е необходим.
Нека разгледаме тази ситуация. Разработчикът получава задачата да внедри следващата функционалност на сайта. Това включва добавяне на нови раздели, блокове, елементи. Разработчиците често не се доверяват на кода на други хора и когато стигнат до оформлението, те намират css файл с име като main.css и добавят новите си стилове към края.
Мина известно време, дойде нов разработчик, той получава подобна задача, дори и да се опита да разбере стиловете, той вижда, че там няма модел и повтаря същото, което направиха предишните.
Ръководството поставя срокове, разработват се все повече и повече нови функционалности и проектът се разраства. В резултат на това css файловете се превръщат в кошче, сайтът се зарежда повече, появяват се повече дефекти и т.н.
Мисля, че много хора са запознати с това.

Сега нека поговорим директно за самото структуриране на стиловете.
Не е разумно да съхранявате всички стилове в един файл с течение на времето, става доста трудно за навигация. Освен това всяка страница използва около 10% от правилата от този файл и тежи доста.
Много по-оптимално е да разделите стиловете в логически блокове на сайта.

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

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

/css
/източници - папка за ресурси, не е качена на сървъра
/глобални-варианти - файловете в тази папка се включват във всеки css файл на колектора, ако е необходимо
locals.css - глобални променливи
functions.css - глобални функции
/общ
reset.css - Мисля, че няма нужда да обяснявам, ясно е какви са стиловете
utils.css - стилове като .clearfix
/съдържание
base.css - основни стилове за съдържание, а именно - h1-h6, p, топчета за списъци (ul.text, ul.dashed и т.н.), dl, dd, dt, изображения и панели в текст (текст обвиване), текстови говорители и др. .
панели.css - различни панели
tables.css - стилове за таблици в съдържанието (th, striped)
/контроли
бутони.css - видове бутони
forms.css - общи стилове за полета за въвеждане (например вътрешна сянка, фокус (рамка), стил на съобщения за валидиране и скриването им по подразбиране)
tabs.css - раздели, раздели
системни известия.css - системните съобщения обикновено са от 3 вида: успех (зелено), неуспех (червено) и информация (сиво, синьо)
pager.css - пейджър
banners.css - банери в сайта
balloons.css - всички видове балони, подсказки, персонализирани подсказки и др.
/член
thumb.css - потребителски аватар
card.css - потребителска карта (аватар, име, кратка информация)
cards-list.css - например решетка с карти
profile.css - потребителски профил
/модули - различни модули за сайта
search.css
списък с новини.css
подаръци.css
игри.css
/not-auth - за неоторизирани потребители
login.css - формуляр за пълномощно
регистрация.css - регистрационна форма
/автор - за оторизирани потребители
my-account.css
mail-system.css - входящи съобщения, изходяща кутия и др.
auth-menu.css - меню за навигация в разрешената зона
my-profile.css - преглед на вашия профил, редактиране
/оформления
общ.css
header.css
горно меню.css
долен колонтитул.css
overlay.css - например всички слоеве, плаващи отгоре, ще имат тъмнина от 0,5
main.css - главен колектор, свързан към всички главни страници
/оформления
default.css - основно оформление на сайта, събира файлове от папка /layouts, свързва се към master с основното оформление
popup-windows.css - стилове за изскачащи прозорци, свързани на главните страници за изскачащи прозорци
not-auth.css - събира стилове от папката /sources/not-auth/
auth.css - събира стилове от папката /sources/auth/
/теми - различни теми на сайта
нова година.css
st-valentine.css
/%име-на-раздел% - някои нов разделсайт, „сайт в сайта“, характеризиращ се с наличието на собствено подменю и др.
/css
%име-на-раздел%.css
оформление.css
/източници
меню.css

Разбира се, всеки проект има своя уникална структура. Важен е принципът на разделяне на файловете.

Допълнително описание за някои файлове:

main.css- събира файлове от папки:
/източници/глобални-варианти
/източници/общ
/източници/съдържание
/източници/контроли
/източници/член
/източници/модули

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

.rounded-corners(@radius)
{
радиус на границата: @radius;
-moz-border-radius: @radius;
-webkit-border-radius: @radius;
* поведение: url (/libs/progressive-IE.htc) ;
}

източници/оформления/common.css- глобални стилове за оформление:

.колони-обвивка
{
дисплей: маса;
* увеличение: 1;
}
.колони-обвивка .колона
{
дисплей: таблица-клетка;
* float: ляво;
}

Свързване на файлове 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" />

* Този изходен код беше маркиран с инструмента за открояване на изходния код.

Бих искал да ви дам една концепция, която според мен трябва да се следва.
Новите страници трябва да бъдат изградени от компоненти, „строителни елементи“ - css класове. Някои хора разбират погрешно тази концепция и изграждат страница от класове като mar-bottom-15, float-leftили подложка-20, което също е голяма грешка.
Трябва да се поддържа в целия сайт единен стилелементи, т.е. Заглавието h1 на едната страница трябва да изглежда по същия начин като h1 на другата. Заглавия, параграфи, списъци, панели, раздели, пейджъри, таблици със съдържание и др. дизайнът трябва да се придържа към един стил.
Преди да напишете стилове за нова страницасайт, трябва да анализирате вече съществуващите CSS файлове на проекта, може би необходимите стилове вече съществуват там. CSS файлът не трябва да нараства ненужно.

В заключение ще кажа, че всичко описано по-горе е от значение и за JS.

В тази част на урока ще се запознаем с нови термини, които се използват за описание на папки и HTML елементи.

Забележка: Папката също често се нарича директория или директория.

Структура на сайта

Не съхранявайте всичките си файлове в една папка. Дори малките сайтове са много по-лесни за управление, ако поставяте HTML документи, изображения и други ресурси в различни папки, като по този начин създавате специфична структура за местоположението на различни файлове. Като структурирате файловете, както желаете, можете да изберете достатъчно за себе си гъвкава системаорганизация на файлове, като се има предвид, че сайтът може да се разраства, файловата система ще остане ясна и разбираема. Структурата (йерархията) на директориите, в които се намират различни файлове, обикновено може да се види под формата на дърво. Разгледайте следното изображение като пример.

Както можете да видите, структурата е просто диаграма, която показва влагането на някои директории в други. В примера използвахме само три директории, но това ще бъде достатъчно, за да опишем цялата необходимата информация. Директориите често се описват от гледна точка на наследствени (семейни) връзки. Имаме папка, наречена Банани, разположена в папката Плодове. Папката „Плодове“ е родител на директорията „Банани“, а директорията „Банани“ е дъщерна (дъщерна директория) на папката „Плодове“. Имаме и папка „Киви“, която също е дете на директорията „Плодове“.

За да ви помогнем да запомните по-добре, ще опишем термините отделно:

• Детска директорияе папка, която има родителска директория над нея в йерархичното дърво.
• Родителска директорияе папка, съдържаща друга директория.
• Има и такова понятие като "главна директория"- това е основната (основната) папка, в която се намират всички останали директории и файлове.

Елементна структура

Структурата на елементите може също да бъде представена под формата на диаграма, показваща влагането на някои елементи в други. Нека да разгледаме един прост пример:

Може да бъде представена диаграма, показваща влагането на елементи както следва:

• Детски елементе елемент, който има родителски елемент над него в йерархичното дърво. Извиква се и дъщерен елемент дете.
• Свързан елементе друг дъщерен елемент на същия родителски елемент на същото ниво на клон. Такива елементи също се наричат сестрински, в примера такива елементи са И ,

  Абсолютен адрес

  Изучаване на HTML

  Когато посочите директория на сайт като връзка (например http://site/css/), индексният файл се показва. Това е файлът, който се зарежда по подразбиране при достъп до директория без изрично посочване на името на файла. Обикновено индексният файл е документ с име index.html.

  Абсолютните връзки обикновено се използват за насочване към документ на друг мрежов ресурс, но също така е възможно да се направят абсолютни връзки в рамките на текущия сайт.

  Това обаче не се практикува често, тъй като такива връзки са доста дълги и тромави. Следователно относителните връзки се използват предимно в рамките на сайта.

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

  Това име на файл е взето само като пример на сайта, руски знаци с интервали не трябва да се използват в имената на файловете и дори в различни случаи.

  2. Файловете се намират в различни папки(фиг. 8.5).

  

  Когато изходният документ се съхранява в една папка, а свързаният е в основата на сайта, тогава две точки и наклонена черта (/) трябва да се поставят пред името на файла в адреса на връзката, както е показано по-долу.

  Две точки в този случай означават напускане на текущата папка на по-високо ниво.

  3. Файловете се поставят в различни папки (фиг. 8.6).

  

  Сега изходният файл е в две подпапки и за да направите връзка към документа в корена на сайта, трябва да повторите предишния пример два пъти.

  Връзка

  Подобна е ситуацията с произволен брой подпапки.

  4. Файловете се поставят в различни папки (фиг. 8.7).

  

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

  Връзка

  Имайте предвид, че няма допълнителни точки или наклонени черти преди името на папката.

  Връзка

  Ако файлът се намира не в една, а в две папки, тогава пътят до него е написан така.

  Връзки спрямо корена на сайта Понякога можете да намерите пътя до файла спрямо корена на сайта, изглежда така"/Име на папка/файл" с наклонена черта в началото. Да, записКурсове

  означава, че връзката води до папка с име course, която се намира в основата на сайта и в нея трябва да изтеглите индексния файл. Моля, обърнете внимание, че тази форма на влизане не работилокален компютър

  , но само под контрола на уеб сървър. 2018-03-27

  Дата на публикуване:От автора:

  Работата по големи проекти идва със сложността на работата с голям код в голям екип. Твърде често се оказвах, че не следвам основните принципи на разработката на софтуер като DRY (не се повтаряйте), KISS (нека бъде глупаво просто) и YAGNI (няма да ви трябва).

  Предвид тези проблеми започнах да използвам най-разпространените системи: OOCSS, SMACSS, ITCSS, ACSS и BEM - с тяхна помощ те създават приемлива CSS архитектура. Всъщност, по някаква причина оценявам всички CSS архитектури и не искам да търся перфектната. Стигнах до извода, че най-доброто решение е това, което действително работи за всички хора, които работят по него. Едно решение далеч не е благоприятно за хората, ако има слабости. Понякога лесно се изгубваме в техниките и забравяме, че зад всеки ред код стои човек. Начинът, по който пишем и организираме код, трябва да бъде важно средство за комуникациядруги разработчици, не само техническо решениепроблеми.

  От това заключавам, че определянето на конвенции вече не е достатъчно. Трябва също да бъде прието споразумение, насочено към потребителя. Всичко това означава:

  Избягвайте ненужната сложност

  Обяснете и направете синтаксиса на класа лесен за четене

  Следвайте реда и го поддържайте чист

  Опитайте се да създадете гъвкав модел, който може да се променя и развива според нуждите на хората

  Всички тези мисли ме доведоха до това, което наричам UFOCSS. Това означава да върнете потребителя в светлината на прожекторите, като предоставите възможно най-много информация чрез насочваща CSS архитектура.

  Какво означава UFOCSS?

  Въпреки приликата в името, UFOCSS означава User Friendly Oriented CSS. Това не е извънземна методология и нов начинпредставляваща мащабируема и модулна CSS архитектура. Това е опит да се съсредоточим върху най-„човешката“ част от това, което вече ценим. До къде води това? Нека разберем!

  Струва ми се, че тук трябва да работите върху голям уеб проект, където SCSS и PostCSS се използват в разработката. По този начин CSS кодът може да бъде категоризиран и организиран в малки логически единици, разделяйки кода на множество папки и файлове, които се препращат един към друг чрез директивата @import. След това системата за изграждане ще използва файловете и ще ги компилира в един стилов файл за производство и ще го запише в целевата папка.

  Като цяло една стилова директория може да изглежда така:

  

  Както можете да видите, кодът е разделен на 2 основни папки: резюмета и модули. Това помага да поддържате структурата на вашите папки чиста и организирана, без да създавате допълнителни папки, които всъщност не са необходими.

  Можете да изберете произволни имена на папки, които харесвате (т.е. инструменти за резюмета и модели или слоеве за модули). Конвенцията, която използвам, е да сортирам папките по азбучен и цифров ред. Тази конвенция е наистина полезна, когато работите с езици, които разчитат на каскадни принципи и принципи на наследяване.

  Организирането на файлове и папки по азбучен и цифров ред дава на потребителите ясен визуален индикатор за това какво е на първо място в кода, което от своя страна се определя от принципите на специфичност.

  Ако си представите проекта като многослойна пандишпанова торта, тогава:

  не можете да направите горни слоеве, ако нямате първия

  когато всички съставки се използват в равни количества, съставките се овкусяват най-добре върху горния слой на тортата (каскадно)

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

  Папка с резюмета: инструментите живеят тук

  Първата информация, която трябва да се даде, е какво може да се счита за инструмент. Тоест това, което не генерира CSS правила и обратното, което е в основата на стиловете на проекта. Поради тази причина смятам, че е важно да се разделят абстрактните инструменти - това е широко разпространена практика.

  Връщайки се към примера с баницата, първата стъпка е да разберем какво ще приготвим, какъв дизайн и вкус ще има баницата.

  Резюметата са съставките и инструментите, необходими за стартиране и ускоряване на разработката, като променливи, функции и миксини. Те не влияят външен види вкуса на баницата, но определят начина на създаване и поддържане. Никой не се нуждае от тях, освен вас и вашия екип!

  Всички файлове с резюмета се обясняват сами по себе си. Само имайте предвид, че вземам всичко, което трябва да се използва широко от файла _variables - цветове, шрифтове, мрежа и z-индекс. Мисля, че това улеснява всички да разберат от какви инструменти се нуждаем.

  Например z-index файлът контролира вертикалния ред на елементите. Добра практика за управление на z-index в сложни оформления е да настроите няколко Sass списъка, които описват в какъв ред искаме да се показват елементите, от най-ниския до най-високия.

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

  $modal-elements: полета, контроли на формуляри, предупреждения, падащо меню за автоматично довършване;

  $modal-elements: полета, form-controls, alerts, autocomplete-downdown;

  Този списък на Sass е само инструмент, който ви помага безопасно да управлявате реда на стека от елементи, той не генерира CSS правила.

  Можете да използвате този инструмент, да получите стойността на z-index и да я присвоите на всички елементи чрез функцията Sass index() във валиден модулен файл, както е показано по-долу:

  Модални предупреждения ( z-индекс: индекс($модални елементи, предупреждения); .... )

  Модални - сигнали ( z - индекс: индекс ($ модални елементи, предупреждения); . . . .

  Това е само пример за това как абстрактните инструменти могат да помогнат при работа по големи проекти. След като дефинирате инструментите, най-накрая можете да преминете към същинската същност на проекта. Нека разгледаме модулите по-подробно!

  Папка с модули: слоевете живеят тук

  Принципът на работа според нивата на нарастваща сложност и специфичност ни позволява да добавим втора тухла към CSS стената - това е определението CSS слоеве.

  Обсъденият по-рано слой с резюмета може да се счита за нулев. След създаването на всички необходими инструментии „съставки“, можем да започнем да пишем стиловете на нашия проект чрез прогресивни слоеве абстракция (повече за тях по-долу).

  Дефинирането на слоеве на абстракция ще ни помогне систематично да създаваме модулни стилове, които ще останат последователни, мащабируеми и поддържаеми, докато проектът расте и се променя с течение на времето. Така че ги групирах в папката модули, точно както в SMACSS. Това дава идеята за колекция от шаблони, някои части на Lego с различни приложения, които могат да се използват повторно. Модулите са набор от правила, които могат да се използват повторно в целия проект - повтарящи се и стандартизирани единици. Те представляват истинското ядро ​​на проекта, тъй като именно от тях започва изходът на реални CSS правила.

  Използването на префикси за лесно дефиниране на обхвата на даден клас е добра практика и се възприема от основните системи за CSS архитектура като SMACSS и ITCSS. Ще говоря подробно за конвенциите за именуване в бъдеща статия, но засега имайте предвид, че ще използвам и префикси в имената на файловете. Това може да се постигне:

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

  Всеки знае точно за какво се използва файлът

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

  Идеята за разделяне на CSS кода на отделни слоеве идва от ITCSS, чийто основен принцип е да сортира стиловете от общи към изрични, от ниско специфични селектори към по-специфични. Този подход се оказа много полезен при работа със специфичност, един от най-трудните принципи на CSS.

  Опитвам се да опростя структурата на папките си, като свивам и преименувам слоевете, представени от ITCSS: Настройки, Инструменти, Общи, Елементи, Обекти, Компоненти и Козове.

  Намирам за удобно да групирам променливи, функции и миксини в един слой с резюмета, вместо да ги разделям между Настройки и Инструменти

  Generic и Elements могат да се комбинират в базовия слой, тъй като и двата включват най-основните и нискоспецифични класове

  Предпочитам да преименувам слоя Objects на Layout - най-разбираемия слой, тъй като се използва за некозметични класове

  Ще преименувам Components на Objects, тъй като този слой може да се използва и за повече атомни елементи

  Trumps се използва за помощни програми, така че просто ще нарека слоя Utility

  Ако е необходимо, никой не ви забранява да добавите допълнителен слой като шаблони. Този слой може да се използва за правила, които се прилагат уникално в някои шаблони. В този случай бих използвал префикса _t_. Или можете да използвате следните слоеве.

  Слоеви основи

  Това е първият слой, който генерира действителните CSS правила. Тук можете да намерите нулиране или нормализиране на стилове, глобални правила като оразмеряване на кутия и стилове за HTML текстови тагове. Също така мисля, че на това ниво е възможно да се поставят някои помощни класове, строго свързани с HTML таговекато .h1, .small, .mark - това е полезно, когато няма съответствие между стил и семантика.

  Правилата за шрифтове могат да бъдат поставени тук, както е показано по-долу:

  h1, подобен на .h1 ( шрифт: ( семейство: $font-primary; тегло: удебелен; размер: 2 rem; ) текстово преобразуване: главни букви; ...... )

  h1 , . h1 - харесвам ( шрифт :( семейство: $font-primary; тегло: получер; размер: 2rem; преобразуване на текст: главни букви; . . . . . .

  Бих включил тези правила във файла _b_typography.scss. Префиксът _b_ означава база.

  Оформления на слоевете

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

  Нека да разгледаме пример за карта със статия, която има изображение и текст под нея. Когато оформяме козметично този обект, не е нужно да мислим за неговото оформление. Трябва да работи добре навсякъде! Тоест трябва да прехвърлим отговорността за оформлението на друг клас, който е специално създаден за това.

  Като блок, обектът карта ще заеме цялата ширина на своя родител. Ако искате картата да заема само част от наличното пространство, трябва да напишете друг клас, който е единствено отговорен за оформлението на обекта.

  Идеята за разделяне на структурата и дизайна е заимствана от 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; ) @за $i от $min-cols до $max-cols ( .l_columns-#($i) ( @extend .l_columns-1; grid-template-columns: repeat($i, 1fr ) )

  $ min - cols : 2 ; $max - колони: 6; L_колони - 1 ( дисплей: решетка; grid-row-gap: 30px; мрежа - колона - междина : 30px ; @за $i от $min - cols до $max - cols (