Топ 5 CSS грешки, които трябва да избягвате

Кодови миризми, поддръжка на браузър, единица за пиксели и други

Езикът CSS е важен аспект на мрежата, както я познаваме днес. Това ни дава възможност да опишем как елементите са описани на екрана, хартията или друга медия.

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

Как можем да предотвратим това изобщо да се случи? Като следвате най-добрите практики и избягвате най-честите грешки.

В тази статия ще обобщим кои са първите 5 грешки и как да ги избегнем.

1. Без проектиране отпред

Изкушаващо е да започнете да проектирате и изграждате компоненти веднага. Това ни дава усещане за бързина и постижение. Това обаче има обратен ефект в дългосрочен план.

Докато изграждаме все повече и повече компоненти, някои въпроси без отговор ще започнат да изскачат. Това ще ни накара да импровизираме и да вземем бързи реактивни решения, за да запазим това усещане за напредък. Бавно ще настроим идеалния сценарий за бедствие.

Преди да се извърши каквото и да е кодиране, трябва да се вземат много решения. Какво ще бъде нашето виждане за проектиране на компоненти? Искаме ли да изградим нашите компоненти по атомен начин? Бихме ли предпочели да създадем композируема помощна система? Искаме ли вече вградена UI библиотека? Искаме ли нашият CSS да бъде обхващан глобално или по компоненти?

Наличието на ясна представа къде искаме да стигнем ще ни помогне да изберем най-доброто оборудване. Това ще ни спести от съкращения и DRY нарушения. Има много валидни начини за проектиране на приложение. Най-честата невалидна е импровизацията.

Нашият код трябва да бъде предвидим и лесен за мащабиране и поддръжка.

Да разгледаме един пример:

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

2. CSS код мирише

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

Тук ще видим най-често срещаните и как да ги преодолеем:

Нотацията ::

Обичайно е да се намери нотацията ::, използвана в псевдо-елементи и псевдо-класове. Това е част от стария CSS spec и браузърите продължават да го поддържат като резервен вариант. Трябва обаче да използваме :: само за псевдо-елементи като: ::before, ::after, ::frist-line… и : за псевдо-класове като :link, :visited, :first-child…

Използване на конкатенация на низове за класове

Доста популярно е да се използва Sass препроцесор, за да помогне с нашата CSS кодова база. Понякога в опит да бъдем DRY, създаваме класове чрез конкатенация с оператора &.

Нищо не изглежда нередно, докато разработчикът не се опита да потърси класа .card-selected в кодовата база. Разработчикът трудно ще намери класа.

Неправилно използване на стенографии

CSS стенограмите са страхотни и ни спасяват от твърде многословен код. Понякога обаче не ги използваме умишлено. Съкращението background се използва през повечето време случайно.

Неправилно използване на !important правило

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

По-често се използва в сценарии, при които по-специфичен селектор би свършил работата.

Грубо форсиране на стойност на атрибут

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

3. Имената на CSS класове без обхват

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

Според мен двата най-добри са:

• да използвате конвенция за именуване
• CSS модули

Конвенция за именуване

Най-популярната конвенция за именуване е BEM 101. Това означава Block, Element, Modifier методология.

[block]__[element]--[modifier]
/* Example */
.menu__link--blue {
  ...
}

Целта е да създадете уникални имена, като накарате разработчика да разбере връзката между HTML и CSS.

CSS модули

Най-голямото ми безпокойство относно методологията BEM е, че отнема много време и разчита на разработчика, за да се случи. CSS модулите се случват от страната pre-processor, което го прави без грешки. Той генерира произволни префикси/имена за нашите имена на класове на CSS модули.

Разработчикът има едно нещо по-малко, за което да се тревожи, и може да очаква неговите CSS модули да имат правилен обхват.

4. Използване на PX модула

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

px е абсолютна единица. Какво означава? Че не можем да го мащабираме правилно, за да задоволим по-широка аудитория.

Какво трябва да използваме вместо това? Относителните единици са правилният начин. Можем да разчитаме на тях, за да изразим по-добре нашите динамични оформления. Например, можем да използваме ch, за да изразим ширина на div въз основа на номер на символ.

Най-честата замяна на px обикновено са rem и em единиците. Те изразяват размера на относителния шрифт по относителен начин от полета към текст.

• rem ще изрази размера спрямо корена font-size.
• em ще изрази размера спрямо размера на елемента.

С използването на rem ще можем да изразим оформлението въз основа на предпочитания от потребителя размер на шрифта. Това ще направи оформлението ни по-достъпно и динамично.

В горния запис можем да видим как оформление, базирано на единицата rem, може да се разширява и адаптира към различни размери на шрифта по подразбиране.

5. Игнориране на поддръжката на браузъра

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

Защо е решаващо? Помага ни да разберем на какви устройства ще се използва нашето приложение. След това можем да определим кои браузъри и кои версии ще поддържаме.

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

Инструменти като caniuse.com или browserslist.dev са само помощ по този въпрос. Инструменти като postcss идват с autoprefixer функционалност, която ще помогне на нашия CSS да бъде по-широко поддържан.

Увийте

Видяхме как можем да подобрим нашия CSS код. Следвайки някои лесни насоки, можем да постигнем декларативна, многократно използваема и четима кодова база. Трябва да положим толкова усилия в нашия CSS, колкото и в нашия Javascript.

Наличието на непредсказуема CSS система наистина води до разочарование и замърсява оформлението на браузъра на потребителя.

наздраве —

Свързани