CSS vs. JavaScript: Trust vs. Control

Калі GotoConf з Амстэрдама папрасіў мяне выступіць, я падумаў, што гэта будзе іншае машыннае навучанне альбо размовы прагрэсіўных вэб-прыкладанняў. Замест гэтага арганізатары прапанавалі мне асвятляць CSS. Недастатковая прадстаўленая мова ў іх трэку "Мовы праграмавання". Цяпер я фанат CSS з самага пачатку. Я выказаў здагадку, што людзі на жорсткай канферэнцыі па развіцці будуць не ў захапленні. Яны не разгледзелі падрабязна CSS. Замест гэтага, я мяркую, што гэта больш неабходнае раздражненне для іх. Таму я напісаў размову пра тое, што значыць CSS і як мы не выкарыстоўваем яго ў сваіх сілах.

Вось нататкі маёй размовы.

Сумны бой

Днямі я зноў паглядзеў "Капітан Амерыка: Грамадзянская вайна". І зноў мне гэта надакучыла, і я не зразумеў гэтага. Ідэя супергерояў, якія прымушаюць несці адказнасць за іх пабочны ўрон, не новая. Просьба пра кантроль над імі таксама не новая. "Суперсемейка" зрабіла вялікую працу з гэтым.

Мне было сумна па памяшканні ўсіх гэтых класных супер-герояў, якія змагаюцца адзін з адным. Мы ведаем іх паўнамоцтвы. Мы ведаем, што яны знаходзяцца ў глыбокай глыбіні сяброў, якія шмат разоў ратавалі жыццё адзін аднаму. Мы ведаем, што іх паўнамоцтвы супадаюць. У гэтых сустрэчах няма гвалту, рэальнага драйву, гневу. Падобна, што Marvel прадставіла занадта шмат класных персанажаў і зараз спрабуе знайсці спосаб, каб людзі маглі ісці на бок. Прадайце больш цацак, стварайце штучную драму.

У мяне такое ж ўражанне, калі мы гаворым пра выкарыстанне CSS або JavaScript для разметкі. Абодва маюць свае заслугі, абодва маюць свае паўнамоцтвы. У абедзвюх ёсць базы прыхільнікаў, каб выкапаць найбольш падрабязную інфармацыю, каб адстаяць адзін за адным. Але мне гэта сумна. Абодва разам выкарыстоўваюцца - гэта тое, што вылучыла Інтэрнэт. І гэта стрымлівае, што ёсць два масавыя лагеры. Адзін канец ўспрымае CSS як мінулае, і ў свеце, кіраваным модулем, мы павінны рабіць усё ў сцэнарыях. Другі бачыць CSS і яго препроцессоры і стварае сцэнарыі больш чым дастаткова, каб зрабіць усё. Памятаеце дні DHTML, калі мы ўсё рабілі з JavaScript? Памятаеце люфт "толькі CSS рашэнні"? Калі мы (не) выкарыстоўвалі сцяжкі для складанай інтэрактыўнасці, каб пазбегнуць выкарыстання якога-небудзь 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 і сябры. Падтрымка прабачлівага браўзэра і вельмі дзіўныя памылкі без параметраў адладкі не дапамагалі. Мы ведалі, што ўсё не так, але нічога з гэтым зрабіць не маглі. Мы нават не маглі спытаць нікога, бо вытворцы браўзэраў былі недаступныя для зваротнай сувязі.

Калі iPhone выйшаў, CSS правёў свой дзень у цэнтры ўвагі. Гісторыя "HTML5 - гэта будучыня" патрабуе шмат дадатковай функцыянальнасці. Калі кампанія Apple выклікала здымкі і стандартызацыя займала занадта шмат часу, была толькі "Webkit".

Гэта азначала прыстаўкі ў CSS і яшчэ раз разгалінаванне для розных рухавікоў рэндэрынгу. Вытворцы браўзэраў укаранілі інавацыі і прадэманстравалі перавагу над іншымі з пэўнай функцыяй. Для распрацоўшчыкаў гэта азначала паўтарэнне і неабходнасць падабраць план падтрымкі для кожнага з іх. І, вядома, адзін для падтрымкі старых, састарэлых браўзэраў. Гэтыя новыя браўзэрскія войны вакол прэфіксаў выклікалі шмат аргументаў і блытаніны.

І апошняе, але не менш важнае месца ў CSS да нядаўняга часу не было. Замест гэтага мы ўзламалі, выкарыстоўваючы пазіцыянаванне і плавае. Пазіцыянаванне, асабліва абсалютнае размяшчэнне ў пікселях, не разумнае ў Інтэрнэце. Людзі могуць змяніць памер шрыфта і змесціва будзе перакрывацца. Пазіцыянаванне з плаваюць патрэбна ачышчальнымі элементамі.

Гэта не тое, што вы называеце надзейнай базавай лініяй, альбо тое, што было проста зразумець, калі вы не "родная"

Нам трэба было прымусіць CSS працаваць незалежна ад падтрымкі браўзэра

Наша рашэнне заключалася ў тым, каб пераламаць JavaScript. Мы можам прачытаць умовы і рэагаваць на іх, ствараючы HTML і ўжываючы стыль. Паколькі JavaScript з'яўляецца мовай праграмавання, мы маем поўны кантроль над тым, што адбываецца. У нас ёсць умовы, завесы, параўнанні - усё, што праграміст не хапае ў CSS. Гэта ў пэўнай ступені з'яўляецца непаразуменнем CSS як канцэпцыі. Селектар, які адпавядае некалькім элементам, - па сутнасці, цыкл. Мы нават можам выкарыстоўваць: nth-child () для навядзення элемента ў калекцыі.

Увогуле, CSS ідзе ў самыя вялікія крокі, бо нам прыйшлося выкарыстаць JavaScript, каб прамацаць яго. Асабліва расчаравальная падтрымка браўзэра - значна меншая праблема.

  • Вечназялёныя браўзары - рэч - усе браўзары знаходзяцца на пастаянным шляху абнаўлення. Мы нават даведаемся ад вытворцаў браўзэраў пра тое, што ідзе на лінію.
  • Інструмент браўзэра дае падрабязную інфармацыю пра тое, што CSS прымяняецца да чаго. Мы нават атрымліваем візуальныя інструменты, такія як рэдактары анімацыі і падбіральнікі колераў.
Візуальны рэдактар ​​для анімацыі CSS у інструментах Firefox Developer
  • Падтрымка CSS у браўзэрах добра зарэгістравана: caniuse.com - неверагодны рэсурс. Ён не толькі паказвае, які браўзэр і якое асяроддзе падтрымлівае, што. Ён таксама тлумачыць памылкі ў рэалізацыях, прапануе спасылкі на спецыфікацыі і справаздачы пра памылкі. У яго нават ёсць API для ўбудавання гэтай інфармацыі ў дакументацыю і інструменты распрацоўшчыка.
З дапамогай пашырэння кода Visual Studio вы можаце атрымаць інфармацыю пра падтрымку функцый браўзэра непасрэдна ў браўзэры. Вы даведаецеся, каго вы блакуеце, пакуль коды.
  • У нас ёсць каналы падтрымкі і адсочвання памылак практычна для ўсіх браўзэраў. Некаторыя нават дазваляюць падаць памылку пры дапамозе Twitter. Каманды вытворцаў браўзэраў актыўна працуюць у сацыяльных сетках і дасягаюць іх.
  • Папярэднія працэсары, такія як Sass і Less, паднялі тэмпературу, каб хутчэй укараніць CSS-спецыфікацыю. Гэтаксама, як jQuery натхніў JavaScript сёння, яны прыводзяць да функцыянальнасці людзей.
  • Суполка праводзіць шмат часу, робячы CSS больш даступным. Такія падыходы, як аб'ектна-арыентаваны CSS Ніколь Саліван і атамны дызайн Брэда Фроста, існуюць на працягу стагоддзяў і павінны дапамагчы знізіць складанасць.

Што 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

Анімацыя і пераходы

Анімацыі і пераходы ў CSS сталі вялікім прарывам, калі выйшаў iPhone. Пераходы дазваляюць ствараць плыўныя змены з аднаго стану ў іншы. Не трэба ведаць, якія змены павінны адбыцца. Усё, што вы кажаце браўзэру, гэта тое, як доўга пераходзіць і якую функцыю паслаблення выкарыстоўваць. Анімацыя дае вам больш дэталёвае кіраванне. Вы вызначаеце ключавыя кадры і што павінна ажыўляць. І анімацыя, і пераходы пажарныя падзеі да, падчас і пасля. Гэта дазваляе ўзаемадзейнічаць з JavaScript прадказальным чынам. Перавага выкарыстання CSS для гэтага заключаецца ў тым, што браўзэр забяспечвае працу анімацыі. Гэта адбываецца пры запуску іх на графічным працэсары і ў выпадку неабходнасці дросінгу частаты кадраў. Гэта важны крок да забеспячэння добрага тэрміну службы батарэі тэлефонаў вашых карыстальнікаў. Калі вы ажыўляеце ў JavaScript, гэта можа пайсці не так.

Адзінкі прагляду

Медыя-запыты маюць сэнс, калі вы хочаце падрабязна вызначыць вопыт. Замест гэтага вы можаце таксама выкарыстоўваць элементы прагляду для размяшчэння элементаў у залежнасці ад даступнай прасторы. Шырыня агляду (vw) - адсотак ад поўнай шырыні прагляду. Такім чынам, на шырокім экране 480px 10vw - гэта 10% ці 48px. Гэта адрозніваецца ад% адзінкі, якая складае працэнт бацькоўскага элемента, а не прагляду. Укладзеныя працэнты будуць менш, vw не будзе. Вышыня агляду (vh) - гэта працэнт ад поўнай вышыні прагляду. Вы таксама можаце зрабіць сябе незалежным ад арыентацыі, выкарыстоўваючы vmin і vmax. Яны альбо бяруць меншы, альбо большы vw і vh. Адзіны хіст у падтрымцы блокаў прагляду - гэта, што на сённяшні дзень Edge не падтрымлівае vmin і vmax.

CSS Tricks мае выдатную артыкул пра тое, наколькі магутнымі могуць быць элементы агляду. Ад незалежнага дазволу ўстаўкі да тыпаграфіі, залежнай ад прагляду, вы можаце выкарыстоўваць модулі прагляду для стварэння вельмі гнуткіх інтэрфейсаў.

Flexbox

Flexbox - гэта спосаб стварыць кампаноўку элементаў у CSS. Па сутнасці, гэта ўсё, што людзі, якія сцвярджаюць, што табліцы раскладкі былі прасцей, прапусцілі ў CSS - і многае іншае. Вы можаце выраўнаваць даччыныя элементы элемента, размешчанага справа, злева, уверсе ці ўнізе. Вы можаце вызначыць іх, каб запоўніць даступную прастору, пры гэтым кожная выкарыстае альбо тую ж суму, альбо больш, чым астатнія. Вы таксама можаце вызначыць іх, каб выкарыстоўваць даступную прастору паміж сабой альбо вакол кожнага з іх. Гэта так жа гнутка, як напісана на волаве. Калі вы хочаце мець візуальны рэдактар, каб даведацца, што гэта азначае, у Build With React ёсць выдатны рэдактар ​​праграмнага забеспячэння.

Флагбокс-рэдактар ​​зборкі зборкі React паказвае магчымасць выкладвання элементаў з дапамогай гэтай тэхнікі

Існуе таксама гульня пад назвай Flexbox Froggy. Ён выкладае канцэпцыі ў прыемнай і даступнай форме і выдатна падыходзіць для дзяцей, каб пачаць з CSS.

Цудоўная размова пра Flexbox - тая, якую Зоя Гіллануар давала на розных мерапрыемствах. Што мне больш за ўсё падабаецца ў размовах, гэта тое, як Зоя паказвае, як яны выкарыстоўвалі Flexbox ў вытворчасці. Прыклады з booking.com і паказваюць рэзервовыя копіі для браўзэраў, якія не падтрымліваюць яго.

CSS Grid

Калі Flexbox - гэта адказ на элементы макета ў радку ці слупку, CSS Grid пераносіць яго на наступны ўзровень. З яго дапамогай вы можаце выкласці элементы па пэўнай сетцы ў двух вымярэннях, як у радках, так і ў слупках. Сетка рыхтуецца некаторы час, і зараз, нарэшце, падтрымліваецца па ўсіх напрамках.

Сетку можна спасцігаць, бо яе гнуткасць азначае, што ёсць шмат варыянтаў. На сённяшні дзень самы просты спосаб пачаць гэта рэсурс "Сетка па прыкладзе" Рэйчел Эндру. У гэтым выпадку ёсць копіі + ўстаўка прыкладаў макетаў сеткі. Многія з іх маюць рэзервовыя копіі для браўзэраў, якія не падтрымліваюцца. Навучальныя відэаролікі, якія тлумачаць усе бакі і збоі, робяць яго дзіўным рэсурсам.

Калі вы будзеце лепш вучыцца з праблемамі, вы можаце зразумець CSS Grid, гуляючы ў CSS Grid Garden.

У сеткі Інтэрнэт ёсць некалькі размоў пра "абавязковую прагляд". Першы - "CSS Grid Layout", зноў Рэйчэл Эндру.

Джын Сіманс прымае іншы падыход. У размове "Рэальнае мастацкае кіраванне ў Інтэрнэце" яна паказвае, як універсальнасць Грыда можа дапамагчы нам выйсці з мыслення "макет скрынкі".

Няма ніякіх праблем са змешваннем і супастаўленнем Grid і Flexbox. Ён можа і павінен выкарыстоўваць Flexbox у сваіх клетках. Разам гэтыя інструменты дазваляюць ствараць гнуткія макеты. Макеты, якія дазваляюць змяняць змесціва і змяняцца ў адпаведнасці з даступнай прасторай. Вэб-макеты.

Нестандартныя ўласцівасці CSS (зменныя)

Адзін з самых запатрабаваных функцый CSS, які папярэднія працэсары, такія як Sass і Less, доўгі час мелі, - гэта зменныя. Цяпер у нас ёсць уласныя ўласцівасці CSS, якія выклікаюць найбольшую захапленне ад CSS. Вы можаце вызначыць налады паўторнага выкарыстання адзін раз у дакуменце і прымяняць іх ва ўсім. Часцей за ўсё для гэтага выкарыстоўваюць колеры і памеры. Але вы можаце пайсці далей і вызначыць шрыфты і іншую друкарню. Вы таксама можаце выкарыстоўваць іх для разлікаў гнязда ў CSS. Раней гэта было немагчыма. Дзіўная асаблівасць у тым, што карыстацкія ўласцівасці таксама могуць быць дынамічна ўсталяваны з дапамогай JavaScript.

Як чытаць і пісаць уласныя ўласцівасці CSS з дапамогай JavaScript - (урывак з размовы Леа Веру)

Калі вы хочаце даведацца пра дзіўную сілу ўласных уласцівасцей CSS, мы не можам прапусціць гутарку. "Пераменныя CSS: Lea (падзагаловак) Lea Verou" - скарбніца інфармацыі.

Запыты на функцыі CSS

Яшчэ адным вельмі прывабным дадаткам да CSS былі асаблівасці запытаў. Яны падобныя на медыя-запыты. З дапамогай @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 па сеткавых сетках
  • Крыс Койер (@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) - гэта распрацоўшчык, які з'яўляецца экспертам па гнуткай распрацоўцы і прагматычным падыходам да выкарыстання найноўшых тэхналогій.

Я працягваю натхняцца гэтымі людзьмі (сярод іншых) штодня і спадзяюся, што вы пачнеце атрымліваць той самы досвед