Redaguota šio straipsnio versija pirmą kartą pasirodė žurnalo .net - pasaulyje perkamiausio žurnalo, skirto žiniatinklio dizaineriams ir kūrėjams, 225 numeryje.
@twostepmedia: Kur reikėtų sunkiai pakelti tinklalapį? Priekiniame gale ar užpakalinėje dalyje?
Lea Verou: Aš esu tvirtas šalininkas daryti viską, ką galite kliento atžvilgiu. Kai jūsų kodas veikia kliente, jis visada turi susidoroti su viena mašina, nesvarbu, koks sėkmingas bus jūsų projektas.
Viskas, ką parašote serveryje, gali tekti paleisti tūkstančius kartų per sekundę, jei jūsų projektas bus sėkmingas, todėl jo išlaikymas ir išplėtimas tampa vis sudėtingesnis, kai jūsų svetainė auga. Jau nekalbant apie didėjančias prieglobos išlaidas, kurias labai retai galima visiškai padengti iš svetainės pajamų. Aišku, daugybė kliento pusės logikos gali priversti svetainę įkelti lėtai, tačiau mes turime įrankių, kaip to išvengti, pvz., „Gzipping“ ir „užtemimas“, o svarbiausia - „tingus“ įkėlimas.
@komiska: Jūsų darbas nuostabus! Kas įkvėpė jus eiti technikos keliu?
LV: Ačiū! Nemanau, kad tai buvo kažkas įkvėpta. Man tiesiog patiko gaminti daiktus, nes atsimenu save. Kai buvau vaikas, vieną kartą virtuvės kempinės servetėlėmis gaminau pinigines ir rankines!
Maždaug 12 metų atradau, kad programavimas leido lengviau ir profesionaliau kurti naudingus dalykus nei rankdarbius. Tai mane taip sužavėjo, kad iškart įsimylėjau programavimą ir vis stengiausi, kad tai būtų geriau.
@jelmerdemaat: Kaip @LeaVerou sukūrė @dabblet? Su kokia PHP sistema / kita back-end technika? Kas buvo sunkiausia?
LV: „Dabblet“ neturi jokios duomenų bazės, o serveryje naudojamas kodas yra minimalus. Šiek tiek PHP naudojama tik „OAuth“ ir sukuriant rezultatų puslapį, kad būtų galima bendrinti be jokio aplinkinio aprašo chromo (naudinga pranešimų apie klaidas testams). Kaip matote „Github“ statistikoje, PHP sudaro tik tris procentus dabblet. Visa kita yra kliento pusė. Tai padeda išvengti „jsfiddle“ situacijos: „jsfiddle“ daro viską serveryje, todėl dabar, kai tai pavyko, serverio apkrova praėjo per stogą ir ji tapo lėta.
@_dte: Kokia įdomiausia būsima CSS funkcija jums?
LV: filtro efektai tikrai. Jie leidžia mums daryti tai, kas anksčiau buvo neįmanoma, ne tik sunku. Labai nesijaudinu dėl maketavimo modulių, nes a) praeis amžius, kol galėsime jais naudotis, nes jie visiškai negenda gražiai ir b) maketuoti visada buvo įmanoma, tik be reikalo sunku. Žinoma, nauji maketo moduliai taip pat yra labai svarbūs, tačiau mane jaudina ne tokie dalykai.
Taip pat labai jaudinuosi dėl peržiūros srities santykinių vienetų vw ir vh ir CSS3 pratęsimas pritraukti () funkcija, kuri leis mums naudotis pritraukti () kiekviename turte.
Aš taip pat labai norėčiau pamatyti kitas naršykles, išskyrus „Opera“ diegimą objektui tinkamas ir objekto-padėties, kad galėtume nustoti naudoti foninius įsilaužimus, norėdami apkarpyti vaizdus kitu formatu.
@gpirie: Kokią funkciją norėtumėte pamatyti įdiegtą CSS?
LV: A srovė () funkcija, leidžianti nurodyti kitų savybių apskaičiuotą vertę. Kaip ir apibendrinimas currentColor (kuris tada taptų slapyvardžiu srovė (spalva)). Žinoma, įgyvendinti tokį dalyką yra labai keblu, tačiau realybė manęs nesustabdys svajoti!
@kevdog: Kokios yra trys dažniausiai pasitaikančios CSS klaidos?
LV: Dažniausia CSS klaida, kurią matau, yra tai, kad žmonės koduoja savo CSS, daugiausia dėmesio skirdami rezultatui, o ne švariam, prižiūrimam, lanksčiam kodui (ir jie retai pertvarko). Svarbu ne tik tai, kad kažkas atrodo dabar su tam tikru fonu, tam tikra aplinka ir tam tikru dydžiu. Tai turėtų sugebėti prisitaikyti lengvai pasikeisti, neprivalant perrašyti kiekvienos taisyklės apie ją nenuspėjamais būdais.
Galite pagalvoti, kad niekada nieko nepakeisite, tačiau gavę pakankamai laiko, beveik neabejotinai pasirodysite neteisingi. CSS išankstiniai procesoriai gali tai padėti. Jie yra lengviausia išeitis, bet tikrai geresni už aplaistytą, pasikartojantį kodą.
Kita klaida yra per daug išsami CSS. Žmonės nežino apie numatytuosius nustatymus, todėl juos iš naujo apibrėžia. Jie nežino apie trumpinius, todėl vietoj to toliau apibrėžia ilgų rankų savybes. Yra atvejų, kai tuos dalykus turite daryti specialiai, tačiau tai nėra priežastis juos viskuo daryti gynyboje.
@ kevdog: Jei galėtumėte pakeisti vieną dalyką CSS specifikacijoje, kas tai būtų?
LV: Yra daugybė pasiūlymų, su kuriais sutinka beveik visi CSSWG nariai, tačiau jų negalima pridėti dėl to, kad pažeidžiamas plačiai paplitęs žiniatinklio naudojimas. Paprastai WG arba visiškai paneigia tai, arba prideda daugiau savybių, kad valdytų elgesį, o ne pakeistų numatytuosius nustatymus. Norėčiau pamatyti būdą pasirinkti nesuderinamus pakeitimus atgal, kad esamos svetainės nesutrūktų. Kitos kalbos jau seniai išsprendė šią problemą, tačiau naudodamiesi HTML ir CSS mes nuolat kovojame dėl atgalinio suderinamumo kainuojant gerą kalbos dizainą.
@StuRobson: Ar manote, kad dizaineris tingus naudoti karkasą ar katilą norom nenorom, nesuprasdamas visko, ką jis daro?
LV: Ne, bet manau, kad dizaineriui yra tingus naudoti karkasą ar katilą be asmeninio poreikio, vien todėl, kad visi kiti taip daro. Neproduktyvu bandyti išspręsti problemas, kurių dar neturite.
@folktrash: Kuriuo momentu įvyko „garsenybė“? Iš kur tu žinai? Ir ar tai padeda ar trukdo evangelizuoti kodo kokybę / semantiką?
LV: Ačiū, bet nesu tikras, kad mane galėtų taip pavadinti. Visi yra linkę laikyti žmones, apie kuriuos girdėjo, labiau žinomus nei tuos, apie kuriuos nė neįsivaizdavo. Taigi kiekvienas turi natūralų polinkį pervertinti savo šlovę, kurią reikia dirbtinai (ir beveik aklai) subalansuoti, kai žinai šį reiškinį. Taip pat turime nepamiršti, kad niekas mūsų pramonėje nėra įžymybė, niekas nėra namų vardas.
Be to, 2011-ieji buvo beprotiški, ir akivaizdu, kad gavau daugiau pripažinimo už savo darbą, kurio galėjau tikėtis. Tai tikrai padeda evangelizuoti interneto standartus. Žmonės skiria daug daugiau dėmesio, kai ką nors sakau dabar, nei prieš metus. Tačiau tai kainuoja tuo, kad mano sakomi dalykai yra per daug analizuojami, žmonės gali per daug į juos įskaityti ir užpulti mane dėl to, kad tariamai turiu nuomonę, kurios niekada net nesu svarstęs. Arba kartais, vien dėl nuomonių, taškas.
@Tawreh: Kodėl jūs taip fanatiškai žiūrite į moteris industrijoje? Aš suprantu lygybės būtinybę, bet tu ją stumti į kraštutinumą.
LV: Pirmą kartą girdžiu tokį dalyką kaip „kraštutinė lygybė“. Lygybė niekada negali būti kraštutinė, ir aš abejoju, ar kas nors pasakytų ką nors panašaus dėl kitokio pobūdžio diskriminacijos, pavyzdžiui, rasizmo. Tai yra „atvirkštinė diskriminacija“ arba „korekcinis šališkumas“, kuris yra kraštutinis, ir aš tam griežtai prieštarauju.
Tai reiškia, kad aš apskritai nesu „fanatiškas“ dėl moterų pramonėje, aš esu „fanatiškas“ prieš receptinius lyčių stereotipus. Vargu ar kada matau seksizmo mūsų pramonėje, atrodo, kad žmonės jau seniai išmoko savo pamoką. Nemanau, kad mažas moterų dalyvavimas mūsų pramonėje yra dėl to, kad jos jaučiasi nebepageidaujamos. Tai likusi mūsų lyčių lygybės visuomenė, kuri atstumia moteris nuo inžinerijos. Mažos mergaitės žaidžia žaislais, kurie neskatina jų lavinti pažinimo įgūdžių tiek, kiek berniukų žaislai. Vaikiški filmai ir žaislai yra blogiausias lyčių stereotipų įamžintojas ir beveik nematau ten jokio susidomėjimo. Atrodo, kad visi sutelkia savo dėmesį į suaugusiuosius, ištaisydami klaidas, o ne vengdami jų padaryti pirmiausia.
@komiska: Ar kada nors bus šrifto svorio perėjimas?
LV: cituoju pastabą iš spec. „Tai nėra taip paprasta“. Daugumoje ypatybių nepakanka svorio sklandžiam perėjimui ir naršyklė negali generuoti tarpinių būsenų, nes nėra galimybės jų pavaizduoti CSS. Tai sakė, mes galų gale pratęsime kryžminis išblukimas () iš CSS4 „Image Values“ pritaikyti visoms CSS reikšmėms, ne tik vaizdams, kurie išspręstų daugumą perėjimo problemų, ir suteikia mums galingą įrankį, kurį galima naudoti ir statiškai.
