CSS для дизайнерів і не тільки. Основи, які має знати кожен. Частина 1

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Усім привіт! Мене звати Микола Громов. Я Senior Web Developer у компанії AB Soft, а також викладач Front-end Basic (HTML + CSS) і Front-end Pro (JavaScript) у комп’ютерній школі Hillel.

У минулому працював у великих проєктах електронної комерції, таких як Цитрус або Tesoro Jewelry, брав участь у кількох невдалих стартапах у ролі СТО та був ментором у стартапі Hillel Evo. На кожному з перелічених проєктів я стикався з версткою. За свою кар’єру я побачив верстку та дизайн з усіх боків. Я верстав від email-листів до великих CRM-систем, розробляв схематичні макети інтерфейсів і навчав верстці багато людей.

Ця стаття буде корисною як для верстальника, так і для дизайнера (а ще трохи для QA, що тестує верстку макету). Але більшою мірою для дизайнера, оскільки маю великий досвід у верстці готового макета і лише певний час займався створенням дизайну. Стаття — це не тільки моя особиста думка, але і збір висновків про проблеми, з якими стикаються як початківці, так і досвідчені фахівці.

Одразу дисклеймер: це перша частина тексту про CSS. І ні, вона не про верстку, не про дизайн і не про стосунки верстальника та дизайнера, скільки би мемчиків про це не існувало. Це стаття про те, як поліпшити розуміння роботи двох спеціалістів з різними цілями для одного продукту.

Дизайнер-верстальник?

Щоразу під час обговорення макета в діалозі, де з одного боку верстальник, а з іншого — дизайнер, я аналізував, чому виникають суперечки стосовно макетів. Ще складніше відповідати студентам на запитання про поганий макет. Висновки з обох боків бувають різні: від «Дизайнер просто не розуміє, як воно працює, і малює абияк» до «Верстальник ледачий і не хоче зробити краще». Та чи це так?

Розбираючи питання про те, чи повинен дизайнер знати HTML + CSS, багато моїх знайомих, зокрема й дизайнерів, упевнено стверджують: «Так, повинен». Це підтверджують і багато вакансій західних компаній, де ми бачимо у вимогах до кандидата HTML + CSS, а іноді навіть JavaScript (кілька прикладів нижче). Досвід індустрії показує, що дизайнеру просто необхідно знати верстку, тоді й у верстальника не виникатиме запитань до дизайну. Отже, конфлікт розв’язано, і проблеми немає? Насправді все геть не так!

Звісно, технічні знання верстки необхідні дизайнеру — вони допоможуть покращити розуміння можливостей верстки для різноманітних пристроїв і вивести розробку інтерфейсів на новий рівень. Однак це в жодному разі не приведе (і не повинно) до ідеального макета для верстальника. Є думка, що дизайнер, який знає верстку, створює менш привабливі макети. Тут річ у підлаштовуванні під можливості HTML і СSS. Адже першорядна задача — створити дизайн, який «чіпляє» клієнта. Виходить, потрібно просто знайти золоту середину. Дизайнеру треба розуміти web-технології, а не використовувати їх.

Відповіддю на цей аналіз буде твердження, що більшість особливостей дизайну, які полегшують роботу верстальника, не потребують жертв з боку дизайну і вони здебільшого елементарні. Про це ми й поговоримо нижче.

Що стосується «ледачого верстальника», то тут усе залежить від ситуації. Якщо дизайн порушує стайлгайди, визначені раніше, то дизайнер несвідомо втручається в код верстки й ламає модульність (останнім часом дедалі більше дизайн-сервісів починають використовувати методологію атомарного дизайну (Atomic design), так що цей біль зміщується в бік дизайнера). Як цього уникнути — ми теж розглянемо нижче.

Ще постає питання в ретельності підбору стилів типографії (стилі шрифтів, перенесення тексту) й позиціювання елементів (видиме неозброєним оком). У такому разі необхідно розбиратися з версткою та дійсно робити краще. Однак і про це нижче.

Вакансія 92nd Street Y в Нью-Йорку, де від дизайнера вимагають феноменальних front-здібностей

Вакансія Jacobs у Кракові з вимогами HTML, CSS і JavaScript

Типографіка

Типографіка видається найпростішою частиною макета. Знайти тут місце для суперечок — складна задача. Здавалося б, завантажив шрифти, скопіював текст і його налаштування. Проте проблеми є, і їх немало. Давайте поглянемо.

1. Набір шрифтів. Для зазначення сімейства шрифту для тексту в CSS використовується властивість font-family. Значенням цієї властивості є ім’я сімейства. Деталь, на яку варто звернути увагу: через низку причин шрифт може не завантажитися. Тому зазвичай вказують кілька шрифтів через кому, які будуть застосовуватися в порядку слідування. Тобто якщо перший не підвантажився — отримаємо наступний у списку тощо. Після основного шрифту зазначають безпечний шрифт, найближчий до основного. Якщо ви хочете це врахувати — зазначайте його також у макетах і стайлгайдах.

p {     font-family: Georgia, 'Times New Roman', Times, serif;    }

2. Розмір шрифту. За розмір тексту в CSS відповідає властивість font-size. Для розміру шрифту може бути зазначений абсолютний, відносний, а також розміри в %, px, pt, але стандартом є пікселі.

Також цікаві одиниці вимірювання — em (висота шрифту елементу), ex (висота символу x) і rem (висота шрифту кореневого елементу), що дозволяє створювати цікаві динамічні зміни шрифтів документу залежно від роздільної здатності екрана або пристрою. Значення, вказані в таких одиницях вимірювання, розраховуються динамічно від вказаних значень. rem одиниці вираховуються відносно розміру шрифту верхнього елементу сторінки — html. Для дизайнера це виглядає як розрахунок від константи.

На більшості сайтів використовуються старі добрі пікселі, але якщо ми говоримо про сайт, де типографіка важлива (де головним контентом є текст), то ці одиниці можуть бути дуже доречними, як і додаткові значення, описані нижче. Використання відносних одиниць виправдане, якщо система продумана та якісно відображена у стайлгайдах. Мій улюблений приклад якісного застосування відносних одиниць для шрифту — сайт газети The New York Times.

Для задання абсолютного розміру використовуються такі значення: xx-small, x-small, small, medium, large, x-large, xx-large. Ці розміри вираховуються так само, як і rem.

Нижче в таблиці зазначена кратність розміру відносно елементу html:

Тобто якщо для html-елементу вказувався розмір 8 пікселів, то small матиме значення 16 пікселів.

Для відносного розміру шрифту використовують значення larger і smaller.

3. Висота рядка. Для зазначення висоти рядка використовується властивість line-height. Вказати висоту рядка можна множником (значення відносно розміру шрифту), одиницями вимірювання, подібним розміру шрифту (em, px, %, etc.), а також значенням normal (стандартно зазначено в самому шрифті). Тут є кілька нюансів.

Ніколи не зазначайте висоту рядка, меншу за розмір шрифту. Такі значення властивостей шрифту часто викликають подив. З точки зору конструкції шрифту ця ситуація не валідна, хоча використовується дизайнерами для зручності розмірності блоку. Це призводить, наприклад, до ситуації, коли складно визначити відступ між двома текстовими елементами.

Верхній шрифт з валідною висотою рядка. Нижній — з висотою рядка, що дорівнює розміру шрифту (скриншот з Figma):

Я навчаю своїх студентів, що типографіка має бути валідною. Тобто висота рядка повинна бути як мінімум normal, де назва властивості говорить сама за себе. Якщо нижньому тексту встановити line-height у normal, то відступ у 20px уже стане неправильним, оскільки висота рядка не врахована.

Як підрахувати правильний? Необхідно з’ясувати висоту рядка для значення normal нижнього шрифту, відняти від неї розмір шрифту та приблизно поділити на два (частіше висота рядка має більший верхній відступ), відняти це значення від відступу.

Приклад: висота рядка 30 для шрифту 21, віднімаємо 30 — 21 = 9, далі ділимо на два: 9 : 2 = 4.5.

Відняти значення від відступу, враховуючи, що зверху більша частина висоти рядка: 20 — 4 = 16.

До речі, як діє верстальник? Він робить на око. У відповідь дизайнер говорить, що верстальник робить абияк. Так і народжується конфлікт на рівному місці.

Правильне значення висоти рядка для обох елементів (скриншот з Figma)

4. Переноси тексту. У HTML/CSS, на жаль, немає кросбраузерних і адаптивних переносів слів. Якщо ми говоримо про пе-ре-но-си по складах, як у книжках, то в браузерах є словники (властивість hyphens), проте вони не кросбраузерні. Також можна вручну вказувати можливі місця для переносів за допомогою ­ , але це застосовується максимум для кількох рядків і зовсім не підійде для сайтів з перекладами, оскільки склади можуть бути зміщені.

З перенесенням слів усе теж непросто. Властивість break-word дозволяє або забороняє переноси слів повністю, але це працює для кожного слова. У разі коли дизайнер у макеті ставить звичний для нас перенос рядка за допомогою Enter або Return — це автоматично стає неадаптивним.

І якщо в макеті для мобільної версії це можна видалити, то аналог цього переносу у верстці контентний, тобто в HTML — тег
. Можна окремо писати стилі для мобільної версії, але не контент. Отже, проставлений для desktop-версії перенос залишається і для мобільної, що може ламати текст. Приклад нижче.

На прикладі слово «consectetur» розміщувалося в перший рядок, але заради гармонійності тексту я вирішив додати перенос рядка. Так це працюватиме в HTML при зміні роздільної здатності. Тому проставлення таких переносів для адаптивних макетів — доволі складна задача. Необхідно зважати на це обмеження та уникати таких ситуацій, якщо можливо.

Приклад неадаптивного переносу в HTML

5. Наповнення реальним текстом. Часто можна побачити макет, де випадний список для населених пунктів намальований із трьома прикладами: Київ, Одеса, Львів. Немає жодних проблем верстки, поки в списку не з’являється «село Петропавлівська Борщагівка». Як ви розумієте, випадний список не такої ширини.

Порада очевидна — завжди визначайте, який реальний контент буде на сайті. Lorem ipsum має гарний вигляд, а з реальним контентом постає багато запитань. Також варто зважати на те, що один і той самий макет може бути перекладений іншою мовою як сторінка. Та й слова, наприклад, французькі трохи довші за українські.

6. Стилізація тексту в рядку. Є макети, де дизайнер нашвидкуруч або через зручність стилізує одне слово в параграфі. Під час подальшого розбору макета та вибору цього параграфа (наприклад, у Zeplin) будуть відображатися спільні стилі для всього параграфа. Витягати стилі окремо для слова необхідно на око й піпеткою.

7. Багато накреслень. Не завжди можна уникнути великої кількості унікальних шрифтів та їхніх накреслень. Але шрифти чимало важать, на що варто зважати й доносити це до замовника. Бачив ситуації, коли дуже гарна сторінка з трьома шрифтами та десятьма накресленнями завантажувалася не так гарно. Зрештою шрифти довелося відкотити до етапу макета.

8. Файли зі шрифтами. Разом з макетом необхідно надавати файли шрифтів. Тут не йдеться про те, що верстальник ледачий і не хоче завантажити шрифти. На своєму досвіді бачив в інтернеті безліч шрифтів, що мають однакові імена, але різний зовнішній вигляд (особливо це стосується накреслень), як би це дивно не було. Тому правило просте: для точного збігу шрифтів макета необхідно використовувати одні й ті самі файли. Також слід зважати на те, що в разі інтернаціоналізації сайту (багато мовних версій) необхідно врахувати наявність або повного пакету шрифтів для вибору потрібних накреслень і наборів символів верстальником, або самому створити набір для макета, щоб не загубити жодну é.

Для створення набору можна використати один з онлайн-сервісів, наприклад, Font Squirell. Якщо не захочеться вовтузитися з набором — просто надайте повний пакет цього шрифту.

9. Стилізація тексту. КАПС — не капс. У CSS є властивість text-transform, що дозволяє змінювати регістр тексту. Те ж саме варто робити і в макетах. Написаний капсом текст у макеті виглядає дивно. Для підкресленого, перекресленого тексту та лінії над ним є властивість text-decoration. Якщо для дизайну не критично, то найуніверсальніше рішення — використовувати таке ж позиціювання лінії, як надає CSS, інакше доведеться ліпити велосипед з окремим елементом-смужкою та позиціювати її відносно тексту. До того ж такий текст неможливо буде переносити на новий рядок.

Зображення

З графікою виникає чи не найбільше розбіжностей. Просто тому що не все, що може бути гарно та швидко намальовано, може бути так само швидко й адекватно зверстано. Варто пам’ятати, що для створення графіки графічні редактори мають набагато більше можливостей, ніж CSS.

1. Деформації та ефекти. Насамперед під час створення макета варто уникати трансформацій (деформацій). Повторювати їх у CSS — складне й ресурсомістке заняття. Те ж саме стосується трансформацій і тексту, але гадаю, що «не деформувати текст» навчають на першому онлайн-уроці або пишуть на першій сторінці будь-якої книги про дизайн.

У кращому разі при деформації, наприклад, у Figma, відбувається автоматичне перерахування значень шрифту, і ми отримуємо ось такі:

Значення властивостей шрифту після деформації (скриншот з Figma)

У гіршому — отримуємо значення шрифту, що не відповідають дійсності, оскільки текст збільшений вручну через scale і виходить 16px, які виглядають як 20px.

Трохи складніше з ефектами. Якщо ефект накладений на зображення, що може бути експортоване із цим накладенням, — це нескладна задача. Однак ефект, накладений на кілька блоків із зображеннями й текстом, у багато разів ускладнює повторення у верстці.

Зі свого досвіду розповім, що зустрічав ефекти, накладені на SVG графіку, що спричинило обмеження на її використання. Зважайте на те, скільки елементів зачіпають ваші ефекти.

2. Вектор для вектора. Думаю, зі мною всі погодяться, що в 2022 році все, що може бути в SVG, має бути в SVG, якщо ми говоримо про іконки без складних ефектів.

3. Збір графіки. Вічне питання про те, хто має експортувати графіку. Тут зі мною багато хто не погодиться, але я вважаю, що правилом доброго тону для дизайнера є зібрати всю графіку в теки й передати її з макетом. Більшість сучасних систем побудови дизайну автоматично надають зображення до макетів або дозволяють завантажувати зображення окремо вручну, що підтверджує зазначене вище.

До того ж з появою векторної графіки часто виникає необхідність експортування SVG за допомогою AI. Це не те, що ви подумали. Я про Illustrator. Не завжди верстальник має Illustrator, а SVG під капотом — це той самий HTML + CSS, з усіма його правилами пріоритетів і перевизначення.

Тому якщо після створення SVG в ній залучений CSS, і після експорту таких «брудних» SVG вони зустрінуться на одній сторінці, то велика ймовірність, що виникне конфлікт і нижня просто зламає верхню (за правилами перевизначення CSS).

Ось так виглядає «брудна» SVG, здатна зламати побратимів

У прикладі заливка шляхів визначається за допомогою класів st0 і st1, що можуть зустрічатися не тільки в цій SVG і перевизначати стилі побратимів.

Уникнути цього можна, просто обравши «Presentation Attributes» для поля Styling у вікні експорту SVG в Illustrator.

SVG після правильного експорту для WEB в AI

Так виглядає SVG після експорту для WEB. На етапі створення векторної графіки й макета дизайнеру швидше та простіше зібрати графіку в одне місце.

4. Об’єднуйте. Усі елементи, що можуть бути об’єднані після розробки дизайну, мають бути об’єднані. Якщо ви намалювали корову на фоні поля та впевнені, що корову не замінять бараном і не перемістять по полю, то ці шари варто об’єднати. Верстальник може перестрахуватися та зверстати це як два окремі елементи. Хороша практика — повідомляти верстальнику, якщо поведінка шарів відрізняється.

5. Ретина (Ретна, якщо точніше). Якщо планується оптимізувати сайт під ретину й ви збираєте графіку, то слід пам’ятати, що для ретини надаються додаткові 2x зображення. Це необов’язково для фонових зображень, що не мають смислового навантаження, у такому разі можна зекономити на вазі зображення.

Насамкінець

У цій статті я розглянув найгостріші питання, що часто зустрічаються під час розбору макета. Однак це далеко не все. Ще є цілий список більш специфічних, але не менш цікавих проблем. Зовсім скоро вийде друга частина цієї статті. У ній ми поговоримо про адаптивність, кольори, відступи та розміри, а також про найскладніше — дизайн і верстку анімацій.

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось16
До обраногоВ обраному12
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Якщо розробник у web розробці, то повинин знати все що стосується веба, на різному рівні звичайно

Розбираючи питання про те, чи повинен дизайнер знати HTML + CSS, багато моїх знайомих, зокрема й дизайнерів, упевнено стверджують: «Так, повинен».

Дякую за статтю. У мене трошки інше питання. А чи має бекенд розробник знати CSS? І якщо так, то на якому рівні?
Просто часто у вакансіях пишуть CSS як вимогу, навіть якщо він не використовується на проекті.

Якщо коротко — то ні, не повинен. Розробка інтерфейсу — то задача Front end, а в вакансіях постійно хочуть бачити Full stack.

ти не вважаешь що web розробник повинен розуміти як працюють усi частини проекту, а не лише те що знаходиться в його компетенцii?

Моя думка, что розробник може знати усі частини проекту, якщо це розширює його експертизу або просто якщо йому цікаво, але він не повинен нести відповідальність за не свою частину проекту. Тому вимагати в вакансії Back end CSS як вимогу не вірно. Розмиття відповідальності має властивість роздуватися та породжує код, який ми всі не любимо.

Має знати і CSS і JS, як на те пішло. На якому рівні? На такому, щоб в критичний момент міг сам поправити. Що це за розробник, якщо він не може кнопку відцентрувати?
Це як вміти користувитись шуруповертом, але не вміти забити цвях.

Не претендую на устрій правил. Просто висловлю свою думку та розражу як це виглядає у мене в проекті.

Якщо в критичний момент треба виправити Front — то це робить розробник, який заміняє того, кто відповідальний та відсутній. Якщо такий не виходить на звʼязок — це робить черговий розробник, який завжди на звʼязку. Так само у всіх відділах. Якщо на проекті не так — то наявні проблеми устрою команди.

Люблю метафори.
Що це за розробник, якщо він не може ендпоінт виправити?
Що це за розробник, якщо він не може Kubernetes кластер трохи розширити?
Що це за розробник, якщо він не може Agile борду зібрати?
Що це за розробник, якщо він не може Windows перевстановити?
Так і народжуються вакансії відділу, а не людини. Розмиття відповідальності.
Водій має знати що таке тормозна рідина, де її перевірити та долити, але не заміняти шланги та клапани, бо на то є люди з досвідом і є ризик аварії.

Про Back end і CSS, я би краще сказав, що це як вміти користувитись шуруповертом, але не вміти класти плитку, бо відповідальність за різне.

Буду вдячний за пораду безкоштовних матеріалів для вивчення HTML + CSS. Почав було читати гайди MDN, але схоже що в цьому плані вони досить слабенькі (якщо порівнювати з гайдами для вивчення JavaScript).

Так, дійсно, знайти гідні джерела, на жаль, зараз важко. Вірю, що спільнота (включно зі мною) розробить гідні довідники.
Можу порекомендувати хіба що:
W3C туторіали:
W3C HTML tutorial — www.w3schools.com/html/default.asp
W3C CSS tutorial — www.w3schools.com/css/default.asp
Гайди MDN, які ви вказали
HTML — Structuring the Web — developer.mozilla.org/en-US/docs/Learn/HTML
CSS — Styling the Web — developer.mozilla.org/en-US/docs/Learn/CSS

www.sololearn.com/learning Можливо, для Вас будуть корисні безкоштовні курси для початківців, де крок за кроком відпрацьовуються елементи безпосередньо в консолі. Хоч курси доволі примітивні, але дають розуміння що на що впливає при верстці.

Дякую. У мене є примітивні знання по верстці, можу щось набутстрапити. Але хочеться почитати систематичні якісь матеріали, щоб заповнити усі свої пробіли в цьому плані, і щоб можна було обійтись і без CSS Bootstrap.

www.freecodecamp.org/...​rn/responsive-web-design — безкоштовний, але дещо поверхневий.
з того, що я бачив, найкращим варіантом була HTML Academy, але вона платна та російська (тож заплатити за неї буде не тільки неприємно, а ще й неможливо технічно).

Підписатись на коментарі