CSS срещу JavaScript: Доверие срещу контрол

Когато GotoConf Амстердам ме помоли да говоря, реших, че ще е друго машинно обучение или прогресивно уеб приложение. Вместо това организаторите ме помолиха да покрия CSS. Недостатъчно представен език в тяхната „езици за програмиране“. Сега съм фен на CSS от самото начало. Предполагах, че хората в една твърда конференция за развитие няма да бъдат толкова развълнувани. Те не са разгледали подробно CSS Вместо това предположението ми беше, че това е по-скоро необходимо досада за тях. Затова написах беседа за това какво означава използването на CSS и как не го използваме в силните си страни.

Ето бележките от моята беседа.

Скучна битка

Онзи ден отново гледах „Капитан Америка: Гражданска война“. И за пореден път ме отегчи и не схванах изобщо за това. Идеята за супер герои, принудени да носят отговорност за своите обезпечени щети, не е нова. Искането за контрол над тях също не е ново. „Невероятните“ свършиха чудесна работа с това.

Отегчих се от предпоставката на всички тези готини супер герои, които се бият един срещу друг. Ние знаем техните сили. Знаем, че те са дълбоки приятели, спасили живота си един на друг безброй поводи. Знаем, че техните правомощия съответстват. В тези срещи няма насилие, няма истински нагон, няма гняв. Усещането е, че Marvel представи твърде много готини герои и сега се опитва да намери начин да накара хората да вземат страна. Продайте повече играчки, създайте изкуствена драма.

Създавам същото впечатление, когато говорим за използване на CSS или JavaScript за оформление. И двамата имат своите заслуги, и двете имат своите правомощия. И двете имат фенбази, готови да изкопаят най-подробната информация, за да се застъпват за една над друга. Но това ми е скучно. И двете използвани заедно е това, което изведе мрежата напред. И ни пречи, че има два масивни лагера. Единият край вижда CSS като минало и в нашия модул свят трябва да направим всичко в сценарий. Другият вижда CSS и неговите препроцесори и изгражда скриптове като повече от достатъчно, за да направи всичко. Помнете дните на DHTML, когато направихме всичко с JavaScript? Спомняте ли си обратната реакция „CSS only solutions“? Когато (ab) използвахме квадратчета за сложна интерактивност, за да избегнем използването на JavaScript?

Джиана Блантин го каза прекрасно:

Могат ли тези две групи:
 „CSS е толкова лесен, че дори не е кодиращ“
 „CSS е толкова труден, трябва да го заменим с JS!“
 моля, поговорете помежду си?

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

Често това е прекомерно отстраняване на маркировката. Подобно на използването на OpenGL за просто създаване на градиент, не е нужно да изваждаме големите пушки през цялото време. CSS има няколко трика в ръкава си, които не можем да съпоставим със сценариите от страна на клиента. И няма нищо общо със синтаксиса или езиковите функции. Става въпрос за споделяне на отговорност.

Кой е виновен и кой трябва да бъде толерантен?

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

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

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

Не е нужно да познавате околната среда и не е необходимо да вземате това решение. ОС, браузърът и участващите прокси сървъри вземат тези решения вместо вас.

JavaScript не е толерантен за повреда. Това може да бъде катастрофално. Вие много повече контролирате, когато използвате JavaScript. Но вие също сте много по-отговорни.

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

С други думи:

  • CSS - Прилагате стиловете си и се надявате да работи.
  • JavaScript - Вие контролирате стайлинга и можете и трябва да проверите дали той работи

CSS означава да се възприеме „скубавост“ в мрежата, както го казва Брад Фрост. Мрежата не е фиксирано платно, на което можете да задавате пиксели. Много неща от него са извън вашия контрол:

  • Браузърите на вашите потребители
  • Разделителната способност, плътността на пикселите и цветовите настройки на техните устройства
  • Надеждността и скоростта на връзката им
  • Тяхното ограничаване на връзката - блокирането на ресурси е нещо
  • Техният размер и размер на шрифта се нуждаят
  • Наличието на ресурси на техните машини за вашия продукт (процесорът вече гори?)
  • Количеството на текстовото съдържание и размерите на изображението във вашия продукт - CMS някой?

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

В тази непозната среда трябва да решим кой да се заеме с работата, за да се справи с проблемите с изпълнението му:

  • CSS - Задачата на браузъра е да работи добре, да използва GPU ресурси и да пропуска функционалността.
  • JavaScript - Ваша работа е да тествате за поддръжка. И за да се гарантира рендирането, боядисването и презареждането е бързо. И да поддържа анимацията в синхрон.

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

Така че защо подценяваме CSS и надценяваме предимствата на JavaScript? Предполагам, че едно виновно нещо е класика - Internet Explorer.

CSS и неговата неравна история

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

CSS беше много ограничен в началото и означаваше като заместител на визуален HTML и атрибути. Стани всички тези шрифтове, bgcolor, подравняване, център, HR и приятели. Поддръжката на Patchy в браузъра и много странни грешки без опции за отстраняване на грешки не му помогнаха. Знаехме, че нещата не са наред, но не можехме да направим нищо по въпроса. Дори не можахме да поискаме никого, тъй като производителите на браузъри не бяха достъпни за обратна връзка.

Когато iPhone излезе, CSS имаше своя ден в светлината на прожекторите. Историята „HTML5 е бъдещето“ се нуждае от много допълнителна функционалност. Когато Apple извиква снимките там и стандартизацията, която отнема много време, беше „само Webkit“.

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

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

Не е това, което наричате надеждна базова линия или такова, което е било лесно за разбиране, ако не сте „роден в мрежата“

Трябваше да накараме CSS да работи независимо от поддръжката на браузъра

Нашето решение беше да кръпка с JavaScript. Можем да четем условията и да реагираме на тях, създавайки HTML и прилагайки стайлинг. Тъй като JavaScript е език за програмиране, ние имаме пълен контрол върху случващото се. Имаме условия, цикли, сравнения - всички неща, които един програмист липсва в CSS. Това до известна степен е неразбиране на CSS като концепция. Селектор, който съвпада с няколко елемента, е по същество цикъл. Можем дори да използваме: nth-child () за насочване към елемент в колекция.

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

  • Вечнозелените браузъри са нещо - всички браузъри са на постоянен път за надграждане. Дори научаваме от производителите на браузъри какво идва по линията.
  • Инструментирането на браузъра дава подробна информация за това, какво CSS прилага за какво. Дори получаваме визуални инструменти като редактори за анимация и колектори за избор на цветове.
Визуален редактор за CSS анимации в Firefox Developer tools
  • Поддръжката на CSS в браузърите е добре документирана: caniuse.com е невероятен ресурс. Той не само показва кой браузър и коя среда поддържа какво. Той също така обяснява грешки в реализациите, предлага връзки към спецификациите и отчетите за грешки. Той дори има API за вграждане на тази информация в документация и инструменти за разработчици.
Използвайки разширение за Visual Studio Code, можете да получите информация за поддръжката на функции в браузъра директно в браузъра. Научаваш кого блокираш, докато кодираш.
  • Имаме канали за поддръжка и проследяване на грешки за почти всички браузъри. Някои дори ви позволяват да подадете грешка чрез Twitter. Екипите на производителите на браузъри са активни в социалните медии и са достъпни.
  • Предпроцесорите като Sass и Less засилиха топлината, за да иноватизират CSS спецификациите по-бързо. Подобно на jQuery, вдъхновен от днес JavaScript, те водят до функционалност, която хората искат.
  • Общността отделя много време, за да направи CSS по-поддържан. Подходи като обектно ориентирания CSS от Никол Съливан и Atomic Design от Брад Фрост са съществували от години и трябва да помогнат за намаляване на сложността.

Какво CSS може да направи за вас

Ето някои невероятни неща, които CSS може да направи сега и трябва да помислите за използването.

Изчислени CSS стойности

Едно нещо, което винаги изглеждаше липсващо в CSS, беше начин за изчисляване на стойностите. Класическият пример е абсолютно позициониран елемент, който е 100% широк, но се нуждае от подплънки. В стари времена трябваше да направим това, като вмъкнем още един елемент и приложим подложката към този. От доста време, въпреки че можем да използваме CSS calc () за това и да приложим ширина на calc (100% - 1em).

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

Медийни заявки

CSS Media Queries ви позволяват да реагирате на промените в екрана за преглед на документа. По същество те означават, че прилагате част от стила си, когато прозорецът отговаря на определени критерии. Това може да бъде оглед, който е поне определена ширина или най-много определена височина. Можете също да проверите за портретна или пейзажна ориентация на екрана или дали документът е разпечатка.
 CSS Media Queries също имат JavaScript, равен в matchMedia. Това ви позволява да зареждате съдържание при поискване. Един проблем на медийните заявки е, че браузърите зареждат изображения в блокове, независимо от съвпадението.

Генерирано съдържание

Използването на :: преди и :: след псевдо селектори в CSS ви позволява да създавате чисто визуално съдържание. Това е чудесен начин да се уверите, че неща, които са по козметични причини, не се нуждаят от собствен, празен елемент DIV, SPAN, B или I. Това е начин да се поддържа всичко визуално поддържано в таблицата със стилове вместо скриптове или HTML документа. Можете да сдвоите това със сенки, градиенти и други функции на CSS, които създават визуални изображения. Впечатляваща витрина от това е „Единичен DIV“. Този уебсайт показва десетки визуализации, създадени от един елемент DIV.

Тази графика е създадена с помощта на един единствен DIV елемент

Анимации и преходи

Анимациите и преходите в CSS бяха големият пробив, когато iPhone излезе. Преходите ви позволяват да създавате плавна промяна от едно състояние в друго. Не е нужно да знаете какви промени трябва да се случат. Всичко, което казвате на браузъра, е колко време да преминете и каква функция за облекчаване да използвате. Анимациите ви дават по-подробен контрол. Вие определяте ключови кадри и какво трябва да оживява как. Както анимациите, така и преходите пожар събития преди, по време и след. Това ви позволява да взаимодействате с JavaScript по предсказуем начин. Ползата от използването на CSS за това е, че браузърът осигурява производителността на анимацията. Това се случва, като ги пуснете на графичния процесор и дроселирането на честотата на кадрите, ако възникне нужда. Това е важна стъпка за осигуряване на добър живот на батерията на телефоните на вашите потребители. Ако анимирате в JavaScript, това лесно може да се обърка.

Viewport Units

Медийните заявки имат смисъл, когато искате да дефинирате подробно преживяванията. Вместо това можете също да използвате единици за оглед, за да оразмерявате елементи според наличното пространство. Широчината на прозореца (vw) е процент от пълната ширина на прозореца. Така че на широк 480px екран 10vw е 10% или 48px. Това се различава от% единицата, която е процентът на родителския елемент, а не прозореца. Вложените проценти ще станат по-малки, vw няма. Височина на Viewport (vh) е процент от пълната височина на прозореца. Можете също така да направите себе си независимо от ориентацията ми, използвайки vmin и vmax. Те или вземат по-малките или по-големите от vw и vh. Единствената бъркалка в подкрепа на единици за изглед е, че към днешна дата Edge не поддържа vmin и vmax.

CSS Tricks има страхотна статия за това колко мощни могат да бъдат зрителните звена. От независими от разделителната способност до типография, зависеща от изглед, можете да използвате зрителни звена за създаване на изключително гъвкави интерфейси.

Flexbox

Flexbox е начин за създаване на оформление на елементи в CSS. По същество това е всичко, което хората, които твърдят, че таблиците на оформлението са по-лесно пропуснати в CSS - и много повече. Можете да подравните дъщерните елементи на елемент, който да бъде отдясно, отляво, отгоре или отдолу. Можете да ги определите, за да запълнят наличното пространство, като всеки използва или една и съща сума, или повече от останалите. Можете също така да ги дефинирате, за да използват наличното пространство помежду си или около всеки от тях. Той е толкова гъвкав, колкото пише на калай. Ако искате да имате визуален редактор, за да видите какво означава това, Build With React има чудесен редактор за флексокс, с който да играете.

Създаването с флексбокса на React показва редакцията на елементите, използващи тази техника

Има и игра, наречена Flexbox Froggy. Тя преподава концепциите по приятен и достъпен начин и е чудесно за децата да започнат с CSS.

Страхотна беседа за Flexbox е тази, която Зоуи Гилънуотър даде на различни събития. Това, което най-много ми харесва при разговорите, е как Zoe показва как са използвали Flexbox в производството. Примерите са от booking.com и показват резервни копия за браузъри, които не го поддържат.

CSS Grid

Ако Flexbox е отговорът на елементите на оформление в ред или колона, CSS Grid го извежда на следващото ниво. Използвайки го, можете да разположите елементи в определена мрежа в две измерения, както редове, така и колони. Grid готви от известно време и сега най-накрая се поддържа от цялата страна.

Мрежата може да бъде обезсърчаваща, тъй като нейната гъвкавост означава, че има много възможности за избор. Най-простият начин да започнете е ресурсът на Рейчъл Андрю „Решетка по пример“. Този има копия + поставяне на примери за оформления на мрежата. Много от тях се предлагат с резервни копия за неподдържани браузъри. Обучителните видеоклипове, обясняващи входовете и изходите от тях, го правят невероятен ресурс.

Ако се научите по-добре с предизвикателства, можете да разберете CSS Grid, като играете на CSS Grid Garden.

Има някои „трябва да видите“ разговори за CSS мрежи онлайн. Първият е „CSS Grid Layout“, отново от Рейчъл Андрю.

Джен Симънс предприема различен подход. В разговора си за „Реално изкуство в мрежата“ тя показва как гъвкавостта на Grid може да ни помогне да излезем от нашето мислене за „кутия оформление“.

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

CSS Персонализирани свойства (променливи)

Една от най-търсените функции на CSS, която препроцесори като Sass и Less са имали отдавна, са променливи. Сега имаме CSS Персонализирани свойства, които най-много ме вълнуват от CSS. Можете да определите настройките за повторно използване веднъж във вашия документ и да ги прилагате навсякъде. Най-често срещаният случай за употреба са персонализирани цветове и размери. Но можете да продължите и да определите шрифтове и друга типография. Можете също да ги използвате, за да вложите изчисления в CSS. Това не беше възможно преди. Удивителна характеристика е, че персонализираните свойства също могат да бъдат зададени динамично с JavaScript.

Как да четете и пишете персонализирани CSS свойства с JavaScript - (откъс от разговора на Леа Веру)

Ако искате да научите всичко за невероятната сила на CSS Персонализираните свойства, има беседа, която не бива да пропускате. „CSS Variables: var (- субтитри)“ на Lea Verou е съкровищница от информация.

CSS Въпроси за функции

Друго много приветливо допълнение към CSS бяха Feature Queries. Те работят много като медийни заявки. С помощта на @supports проверявате дали текущият потребителски агент поддържа определена функция. След това дефинирате блок от CSS, който се прилага само когато има поддръжка на функции. Това може да ви се стори странно, тъй като отказът за устойчивост на неизправност на CSS вече трябва да се грижи за това. Това, което прави обаче, е да ви даде много по-подробен контрол. Той също така ви позволява да определите резервен резерв, когато няма поддръжка за определена функция, използвайки ключовата дума „не“.

CSS и JavaScript?

CSS и JavaScript, които работят заедно, са мощни и правилното нещо. Доколкото стигна CSS, той все още не може да направи всичко. Има сценарии, при които самата природа на CSS стои в контраст с това, което искаме да постигнем.

Както Кристиано Растели обяснява в беседата си „Нека има мир в CSS“, заветната функция на „Разделяне на проблемите“ не се прилага в света на модулите.

Когато CSS се превърна в нещо, ние преместихме целия външен вид и поведение от HTML в CSS и JavaScript. Дефинираме или на документ, или дори на ниво проект. Ние празнуваме факта, че CSS наследява от родителските елементи. Когато изграждаме компоненти, които могат да се използват последователно, ние не искаме това. Искаме те да носят външния си вид, усещане и поведение, без да кървят нито към съседни, нито да наследяват от родителите си.

CSS и JavaScript работят заедно в некомпонентен свят

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

Йерархията на това CSS и JS да работят с друг в този сценарий са следните:

  • Използвайте CSS, когато можете - използвайки нещата, които видяхте тук
  • Ако трябва да комуникирате с CSS, помислете за промяна на персонализираните свойства
  • Ако това не е опция, приложете класове към родителските елементи, използвайки classList.
  • Като краен случай можете да промените стила директно
Отличен пример, показващ как да четете позицията на мишката в JavaScript и да я съхранявате в CSS Персонализирани свойства - (откъс от разговора на Леа Веру)

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

CSS Triggers ви дава информация за ефектите от различни промени в стила

В обобщение

CSS е много по-надежден от преди и не е останало много, което трябва да е различно от това, което е. Основното нещо, което трябва да запомните, е, че CSS не е предназначен да прави същите неща, които прави и JavaScript. Дори езиците за оформление не работят както прави CSS и покриват същата нужда. Има доста трудна работа и го върши добре. Когато използвате CSS, браузърът ви помага да удовлетворите нуждите на крайните потребители, независимо от настройката им. Това е основен принцип на мрежата и е дефиниран в принципите на W3C HTML Design:

Потребители над автори над изпълнители над спецификатори над теоретична чистота

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

Вдъхновяващи и активни CSS хора, които да следват

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

  • Ire Aderinokun (@ireaderinokun) пише много лесно за разбиране и до точката, информационни битове на CSS в блога си, bitsofco.de.
  • Ана Тудор (@anatudor) е разработчик, който създава нелепо сложни и красиви анимации в CSS. Нейният Codepen е един от най-посещаваните и това, което прави на CSS двигателите, е чудесна помощ за производителите на браузъри да тестват тяхната ефективност
  • Джен Симънс (@jensimmons) е CSS експерт по оформление и дизайн, който работи за Mozilla
  • Рейчъл Андрю (@rachelandrew) за мен е експертът по №1 за CSS мрежи
  • Крис Койер (@chriscoyier) е основателят на невероятния CSS ресурс CSS Tricks и интерактивната игрална площадка Codepen
  • Сара Драснер (@sarah_edo) е експерт по анимация и дизайн, фокусиран върху изграждането на поддържащи се продукти
  • Zoe M. Gillenwater (@zomigi) е водещ разработчик, който използва кървави CSS в производството
  • Брад Фрост (@brad_frost) е автор на Atomic Design, мащабируем начин за използване и повторно използване на CSS в големи проекти
  • Рейчъл Наборс (@rachelnabors) е комична артистка и експерт по анимация, пишеща за уеб анимации и достойнствата на различните технологии
  • Уна Кравец (@una) е разработчик, специализиран в CSS и новите му функции. Тя също е подкастър и има пръст много върху пулса на CSS и други визуални технологии
  • Леа Веру (@leaverou) е автор на отличната книга за CSS тайни, изследовател в MIT и поканен експерт от работната група на CSS на W3C. Тя е старателна в своите изследвания и безмилостна в предоставянето на много страхотна информация за кратък период от време.
  • Сара Суейдан (@sarasoueidan) е разработчик, който е експерт по отзивчиви дизайни и прагматични подходи за използване на най-новите технологии.

Непрекъснато се вдъхновявам от тези хора (сред другите) всеки ден и се надявам да започнете да получавате същото преживяване