Traducere: Vlad Merzhevich

Dezvoltatorii au o relație de dragoste-ura cu vânzătorii Prefixe CSS, care vă permit să fiți în fruntea progresului datorită anunțurilor detaliate:

Imagine de fundal: -webkit-linear-gradient(#fff, #000); imagine de fundal: -moz-linear-gradient(#fff, #000); imagine de fundal: -ms-linear-gradient(#fff, #000); imagine de fundal: -o-linear-gradient(#fff, #000); imagine de fundal: gradient liniar (#fff, #000);

Acest lucru funcționează bine în teorie, dar iată ce se întâmplă în realitate.

• Cel mai adesea, caracteristicile experimentale sunt implementate mai întâi în motorul Webkit, dar nu există nicio garanție că vor apărea în alte browsere.
• Uneori poate fi dificil să se determine dacă o proprietate cu un prefix de furnizor face parte din specificația CSS. Unii furnizori de browsere nu standardizează proprietățile.
• Chiar dacă proprietatea implicită s-a schimbat, proprietățile incorecte cu prefixe de furnizor continuă să fie acceptate. Ta cod vechiîncă funcționează și nu trebuie să te întorci la el pentru a o repara.

Veți găsi din ce în ce mai multe site-uri folosind un singur prefix -webkit, chiar dacă alte browsere acceptă proprietatea sau este utilizată pe scară largă fără un prefix (cum ar fi border-raduis ). Prin urmare, Chrome și Safari arată mai bine decât browserele concurente, iar alți producători nu sunt mulțumiți de acest lucru.

Problema a fost ridicată și discutată la reuniunea W3C din 7 februarie 2012.

Activiștii pentru standarde îi învață pe oameni cum să folosească Webkit. Veți vedea din prezentările susținătorilor standardelor web că aceștia încurajează oamenii să folosească prefixul webkit.

Treaba noastră este să găsim o soluție comună.

Pe acest momentÎncercăm să aflăm câte și care proprietăți cu prefixul webkit sunt de fapt acceptate în Mozilla.

Dacă nu acceptăm prefixele webkit, ne vom închide de la o parte a web-ului mobil.

Să luăm un moment să ne uităm la această cloană.

Browserele care nu se bazează pe motorul Webkit vor suporta prefixul -webkit. Această soluție este luată în considerare de W3C.

Ideea va eșua cel mai probabil lamentabil. Două sau mai multe implementări ale aceleiași proprietăți nu vor fi compatibile, astfel încât dezvoltatorii nu le vor putea folosi nicăieri. Nu vor exista câștigători, inclusiv Apple și Google.

Dar sunt mai îngrijorat de pagubele ireparabile care se vor întâmpla dacă se va lua decizia. Odată ce dezvoltatorii descoperă că prefixul webkit funcționează în Firefox, IE și Opera, se vor aștepta ca prefixele să funcționeze în toate proprietățile. Doar adoptarea Webkit-ului va crește exponențial, iar producătorii de browsere vor fi obligați să implementeze prefixe. În acest moment, proprietățile cu webkit vor deveni un standard de facto independent de specificația W3C. Joc încheiat: web deschis se va inchide.

Cine este vinovat?

Putem arăta cu degetul către următoarele.

Grupul de lucru W3C

Petrece prea mult timp așteptând ca standardele web să se maturizeze. Acest lucru poate fi inevitabil, dar producătorii de browser ignoră acest proces.

Producători de browsere

În graba de a promova noile tehnologii, producătorilor le este ușor să adauge un prefix și să uite de el. Dezvoltatorii web cer mai multe informatii: Această proprietate este luată în considerare de W3C și când va fi eliminat prefixul?

ÎN lume ideală prefixele experimentale ar dispărea imediat ce browserul începea să accepte proprietatea standard. Producătorii nu vor face acest lucru, deoarece vor distruge site-urile, dar pot face mai mult pentru a crește gradul de conștientizare a problemei, cum ar fi lansarea instrumentelor de detectare a uzurii și afișarea mesajelor de eroare în consola dezvoltatorului.

Apple și Google

Ambele companii sunt vinovate de promovarea prefixelor webkit ca și cum ar fi o parte standard a dezvoltării HTML5 de zi cu zi. Apple este acuzat că a lucrat activ împotriva W3C.

Mozilla, Microsoft și Opera

Alți furnizori urmăresc browsere bazate pe Webkit de luni de zile, dacă nu de ani. Adăugarea de prefixe webkit este o decizie ridicolă, este timpul să vă jucați jocul.

Site Tehnologi și evangheliști

Cu toții iubim demonstrațiile interesante, dar evangheliștii uită adesea să menționeze că funcțiile sunt experimentale și s-ar putea să nu fie niciodată pe deplin acceptate de browser. În mod ideal, codul ar trebui să funcționeze în cel puțin două browsere, ceea ce înseamnă cel puțin că sunt necesare mai multe prefixe de furnizor.

Dezvoltatori web

Suntem prea leneși. Scriem cod specific browserului și, deși este posibil să avem intenții bune de a-l remedia mai târziu, rareori o facem.

Îți amintești ultima dată când s-au concentrat dezvoltatorii browser specific? Era IE6. Încă trăim cu moștenirea acestei decizii un deceniu mai târziu. Chiar vrei ca istoria sa se repete?

E timpul să acționezi

Sunt împotriva browserelor non-Webkit care acceptă prefixe webkit. ÎN cel mai bun scenariu, fac prefixele inutilizabile. În cel mai rău caz, perturbă întregul proces de standardizare. S-ar putea să fiți de acord sau să nu fiți de acord, dar spuneți-vă colegilor părerea dvs. prin bloguri și social media. W3C și furnizorii de browser vă vor asculta părerea, trebuie doar să le arătați.

Apoi testați-vă site-ul în browsere diferite. O mică degradare grațioasă nu va strica, dar neglijarea unuia sau mai multor browsere moderne asta e rău. Remediați codul, altfel site-ul dvs. contribuie la această problemă.

În acest articol, ne vom uita la ce sunt prefixele browserului, de ce există și cum să le folosim în CSS.

Ce sunt prefixele?

Învățare pentru dezvoltatori web începători baza teoretica CSS și utilizarea acestor cunoștințe în practică pot întâmpina probleme atunci când luați în considerare exemple reale. Acest lucru îl poate determina să înțeleagă greșit ce se întâmplă și să descurajeze dorința de a studia această tehnologie.

De exemplu, când ia în considerare stilurile unui site, un dezvoltator web poate întâlni proprietăți care conțin câteva cuvinte de neînțeles în față: -webkit-, -moz-, -ms- etc.

* ( -webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box; )

Ce este? De fapt, totul este simplu, aceste cuvinte ciudate sunt prefixele următoarelor browsere:

• -webkit-: Browsere Chrome, Safari, Opera;
• -moz- : browser Mozilla Firefox;
• -Domnișoară- : motor de cautare Explorator.

Astfel, dacă există un prefix înainte de numele proprietății, aceasta înseamnă că această proprietate implementat și va fi folosit exclusiv în browser specificat. Toate celelalte browsere vor ignora această proprietate, deoarece pentru ei prefix dat necunoscut

Motive pentru apariția prefixelor?

Au existat multe motive pentru apariția prefixelor:

• Pentru a include proprietăți experimentale CSS în browser care nu au fost încă aprobate de standard. Prin urmare, furnizorii de browsere testează și fac sugestii înainte de a adopta proprietățile CSS în standard.
• Pentru a rezolva problemele cu compatibilitatea între browsere.
• Pentru a vă crea propriile proprietăți care nu sunt incluse în standardul CSS, dar care pot apărea în acesta după un timp.

Când o proprietate experimentală este aprobată în standard și testată în browser, de obicei, prefixul ei este eliminat.

Cum se folosesc prefixele?

Luați în considerare următorul cod ca exemplu:

* ( -webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box; )

Acest cod se aplică Proprietăți CSS, care modifică algoritmul de calcul al lățimii și înălțimii pentru toate elementele paginii web. Prima proprietate CSS -webkit-box-sizing cu valoarea border-box este destinată browserelor care utilizează motorul webkit (Safari) sau blink (Chrome, Opera, Yandex.Browser). A doua proprietate CSS -moz-box-sizing cu valoarea border-box este destinată browserelor care utilizează motorul Gecko (Mozilla Firefox). Ultima proprietate CSS este destinată browserelor în care proprietatea a fost deja testată și implementată conform standardului.

Când utilizați prefixe pentru proprietățile CSS, trebuie să vă amintiți că acestea ar trebui să fie plasate înaintea proprietății CSS fără un prefix. De ce este asta atât de important? Acest lucru este important pentru că, dacă într-o zi browser-ul implementează proprietatea originală (fără prefix), atunci aceasta va fi folosită (deoarece este situat ultima), și nu versiunea sa experimentală.

De exemplu: aplicarea unei proprietăți CSS la toate elementele unei pagini web în browser Google versiuni Chrome 40.

În imaginea de mai sus, puteți vedea că proprietatea originală de dimensionare a casetei este deja implementată în acest browser și, deoarece este ultima, browserul o folosește mai degrabă decât proprietatea -webkit-box-sizing de mai sus.

Cum se verifică suportul pentru o anumită proprietate în browser?

Un site unde puteți verifica dacă această proprietate este implementată sau nu într-un anumit browser poate fi găsit la linkul de mai jos. În plus, site-ul arată numărul de utilizatori ca procent care folosesc această versiune a browserului.

Site-ul web „Pot folosi...”

De exemplu: să verificăm cum este implementat transforma proprietateaîn browsere.

Browserele sunt notate pe site-ul web CanIUse Culori diferite, în funcție de starea suportului pentru anumite proprietăți sau etichete:

• Dreptunghiul roșu este un browser în care această proprietate nu este implementată;
• Dreptunghi verde cu o cratimă în dreapta colțul de sus– browserul în care se utilizează această proprietate prin prefix;
• Un dreptunghi verde deschis este un browser în care această proprietate este parțial implementată;
• Dreptunghiul verde este un browser în care această proprietate este implementată în conformitate cu standardul.

Cuprins:

Prefixul -webkit- este atât de dominant în CSS încât unele site-uri nu funcționează corect fără el. Acest lucru indică faptul că dezvoltatorii nu urmăresc cel mai mult cele mai bune practici V anul trecut iar acest lucru a dus la o decizie nefericită, dar aproape forțată din partea Mozilla. În Firefox versiunea 46 sau 47 (aceasta este aprilie sau mai 2016), Mozilla intenționează să implementeze suport pentru prefixele non-standard -webkit- pentru a îmbunătăți compatibilitatea Firefox cu site-urile care folosesc activ -webkit (de obicei site-uri mobile-first).

Cu toate acestea, dezvoltatorii folosesc prefixe pentru a le folosi ultimele caracteristici browsere cât mai repede posibil. Prefixele au provocat confuzie cu dominația WebKit, dar au forțat și web-ul să avanseze într-un ritm accelerat.

Abordarea Mozilla și Microsoft este sigură pentru majoritatea site-urilor. Multe site-uri vor folosi prefixul -moz- sau nu necesită nicio acțiune pentru a fi compatibile cu o viitoare actualizare a Firefox. Dar, în calitate de dezvoltatori web profesioniști, trebuie să luăm în considerare cu atenție și să înțelegem ce consecințe va implica acest lucru. Probabil știți care dintre site-urile dvs. ar putea fi afectate de această actualizare.

Așadar, este timpul să regândim abordarea prefixelor și să testăm site-urile cu acestea.

Prefixe acceptate

Există o serie de prefixe -webkit- pe care Mozilla le poate implementa. Din ceea ce am adunat, Mozilla nu tinde să se potrivească cu lista proprietăților de prefix acceptate cu cele ale lui Edge, deoarece nu toate sunt necesare pentru compatibilitatea cu motorul de layout.

Dezvoltatorii Firefox sunt, de asemenea, aproape de o abordare similară:

Tendința actuală în Mozilla este de a evita prefixele furnizorului prin dezactivarea proprietăților fără prefix și folosind versiunea fără prefix cu suficientă stabilitate. Aceasta este o politică generală: se pot aplica excepții în unele cazuri - Boris de la Mozilla

Microsoft Edge va abandona și prefixele de furnizor:

„Microsoft va elimina și prefixele de furnizor din Edge. Aceasta înseamnă că dezvoltatorii care doresc să utilizeze anumite funcții HTML și CSS nu vor folosi un prefix specific Edge. În schimb, pur și simplu vor scrie cod conform standardelor” - Mashable

Nu va mai exista degradare treptată pe baza prefixelor

Această îndepărtare de prefixele de furnizor înseamnă un lucru - degradarea treptată folosind prefixele de furnizor nu are perspective.

Utilizarea prefixelor de furnizor pentru a aplica stiluri pentru un anumit browser (de exemplu, numai Chrome) nu a fost scopul introducerii acestora; Recomandarea pentru dezvoltatori a fost întotdeauna să folosească toate prefixele (de la -webkit- la -o-). Dacă utilizați funcții care depind de proprietățile prefixelor și folosiți prefixe pentru a vă degrada treptat designul în alte browsere, atunci acest lucru nu mai funcționează.

Concluzie

Vremurile se schimbă. Dominația WebKit a dus fără să vrea la probleme de incompatibilitate, forțând alți furnizori de browsere să implementeze prefixele -webkit-. Această problemă se va încheia pe măsură ce furnizorii de browsere renunță treptat la prefixele furnizorului, dar între timp dezvoltatorii ar trebui să se asigure că prefixele nu produc rezultate neașteptate în browserele non-WebKit.

Voi cita un fragment din cartea Leei Veru „Secretele CSS. Soluții ideale sarcini zilnice."

Un cântec de gheață, foc și prefixe de browser

Dezvoltarea standardelor este întotdeauna de natură paradoxală: echipele de standarde au nevoie de informații de la dezvoltatori pentru a crea specificații care să răspundă nevoilor reale ale dezvoltatorilor. Dar dezvoltatorii, în general, nu sunt prea interesați să testeze lucruri pe care nu le pot folosi în munca lor. Când tehnologiile experimentale încep să fie utilizate pe scară largă în producție, echipa nu are de ales decât să rămână cu versiunea experimentală timpurie a tehnologiei, deoarece schimbarea acesteia ar putea distruge site-urile existente. Evident, acest lucru anulează complet beneficiile pe care testarea le poate aduce. versiuni anterioare standarde de către dezvoltatori reali.

De-a lungul anilor, s-au propus multe opțiuni pentru a depăși această situație dificilă, dar toate sunt departe de a fi ideale. Prefixele browserului disprețuite universal sunt unul dintre ele. Ideea a fost că fiecare browser ar putea implementa caracteristici experimentale (sau chiar proprietare) care ar trebui să fie prefixate la numele lor. Cele mai comune prefixe sunt -moz- pentru Firefox, -ms- pentru IE, -o- pentru Opera și -webkit- pentru Safari și Chrome. Dezvoltatorii au fost încurajați să experimenteze liber cu acestea caracteristici specialeși împărtășiți-vă impresiile cu grupul de lucru. Grup de lucru, la rândul său, a trebuit să țină cont de feedback-ul de la dezvoltatori la pregătirea specificațiilor, aducând treptat funcționalitatea corespunzătoare la perfecțiune. Deoarece versiunea finală, standardizată, ar avea un nume diferit (fără prefix), adăugarea acesteia nu ar trebui să provoace conflicte în produsele care utilizează echivalente existente, prefixate.

Sună grozav, nu-i așa? Dar, după cum probabil știți deja, realitatea s-a dovedit a fi complet diferită de ceea ce era planificat să fie realizat. Odată ce dezvoltatorii și-au dat seama că aceste proprietăți experimentale dependente de browser au facilitat crearea de efecte care anterior necesitau mult efort și soluții complicate, au început să le folosească oriunde au putut. Proprietățile prefixate de browser au devenit rapid o tendință fierbinte în lumea CSS. Au fost publicate tutoriale, răspunsuri au fost publicate pe StackOverflow și, în curând, aproape fiecare dezvoltator CSS care se respectă și-a acoperit site-urile cu ele din cap până în picioare.

În cele din urmă, dezvoltatorii și-au dat seama că, dacă ar folosi doar prefixele de browser existente, ar trebui să se întoarcă la codul existent și să adauge noi declarații de fiecare dată când un nou browser a adăugat suport pentru caracteristica CSS favorită. Ca să nu mai vorbim că toate prefixele necesare pentru o anumită caracteristică sunt, în general, destul de greu de reținut. Soluţie? Desigur, folosiți întotdeauna toate prefixele posibile de browser, adăugând versiunea fără prefix la sfârșit pentru a vă asigura prelucrare corectă cod în viitor. Drept urmare, codul arăta cam așa:

Moz-border-radius: 10px;

-ms-border-radius: 10px;

-o-border-radius: 10px; -webkit-border-radius: 10px; chenar-rază: 10px; Aplicații similare a devenit una dintre primele implementări adăugare automată prefixele browserului, dar și-au pierdut rapid popularitatea deoarece, în comparație cu alte soluții, sunt destul de incomod de utilizat;

Autoprefixer (http://github.com/ai/autoprefixer) folosește o bază de date de la Pot folosi...(http://caniuse.com) pentru a determina ce prefixe trebuie adăugate la cod fără prefixe de browser și le compilează local ca preprocesor;

propria mea utilitate -fără prefix(http://leaverou.github.io/prefixfree) efectuează testarea caracteristicilor în browser, determinând ce prefixe sunt necesare. Avantajul său este că rareori necesită actualizare, deoarece primește totul informatie necesara, inclusiv o listă de proprietăți, din mediul browser;

preprocesoare precum MAI PUȚIN(http://lesscss.org) și Sass(http://sass-lang.com) nu oferă funcționalitate standard pentru adăugarea de prefixe, dar mulți dezvoltatori își creează propriile colecții pentru caracteristicile cu care folosesc cel mai adesea prefixele de browser și mai multe biblioteci similare pot fi găsite în circulație.

Deoarece dezvoltatorii au folosit versiuni fără prefixe ca garanție că codul lor va funcționa în viitor, a devenit imposibil să le schimbe. În esență, suntem blocați cu specificații timpurii pe jumătate care permit doar modificări minore. Foarte curând toată lumea și-a dat seama că prefixele browserului au fost un eșec epic.

Astăzi, prefixele browserului sunt folosite foarte rar pentru noile implementări experimentale. În schimb, funcțiile experimentale sunt activate folosind steaguri de configurare, ceea ce împiedică dezvoltatorii să le folosească într-un mediu de producție - nu puteți forța utilizatorii să schimbe setari locale pentru a se asigura că site-ul web se afișează corect pe computerele lor. Desigur, consecința acestui lucru este că acum există mult mai puțini dezvoltatori care testează funcții experimentale, dar avem totuși suficiente părere- și eventual feedback de calitate superioară - fără bătaia de cap a prefixelor de browser. Cu toate acestea, va mai trece mult timp până când vom scăpa complet de consecințele neplăcute ale existenței prefixelor de browser.

Opinie personala:

Nu adăugați prefixe de browser fără un motiv întemeiat. Doar căutați pe Google noua proprietate pentru suport pentru browser. De prea multe ori văd adăugarea de prefixe care erau necesare în browserele foarte vechi, pe care aproape nimeni nu le acceptă (de exemplu, care erau necesare chiar la prima versiuni Firefox sau Chrome) pe același StackOverflow.

6 februarie 2012 la 14:14

CSS3: viață fără prefixe

• Dezvoltare site

Prefixele sunt un lucru bun. Ele ajută producătorii de browsere să implementeze noi funcții. Dar viața dezvoltatorilor devine doar mai dificilă din cauza lor. Există multe prefixe, uneori există diferențe de sintaxă.

Problema este evidentă. Avem nevoie de o modalitate de a face lucrul cu prefixele mai ușor.

Desigur, ar fi neînțelept să nu mai folosiți prefixele. Dar este foarte posibil să se transfere responsabilitatea generării lor către instrumente care există special pentru acest scop. Am încercat să enumerez opțiunile posibile.

1. Preprocesoare

Esența preprocesoarelor este că autorul unui fișier de stil o poate folosi caracteristici suplimentare, care nu sunt în CSS, cum ar fi variabile, asemănări de funcții și multe altele, după ce a studiat mai întâi sintaxa preprocesorului, iar preprocesorul va crea deja dosar normal stiluri, înlocuirea variabilelor și a altor coduri cu valori statice. Capacitatea de a înlocui codul poate fi folosită și pentru a genera automat codul între browsere cu prefixe.

Cel mai faimos Preprocesoare CSS acestea sunt LESS și SASS.

Sunt concurenți direcți, deși există o diferență între ei. Ambele pot fi folosite pe partea de server, dar LESS este disponibil și ca fișier javascript, așa că puteți acorda o atenție deosebită acestei caracteristici.

MAI PUȚIN

Acest preprocesor are o sintaxă mai simplă decât concurentul său. Este posibil să procesăm fișiere de stil pe partea de server, dar acum suntem interesați de opțiunea de a lucra pe partea client printr-un fișier javascript.

Conexiune

Mixin
.border-radius(@radius: 3px) (
-webkit-border-radius: @radius;
-moz-border-radius: @radius;
border-radius: @raza;
}

Utilizare
#forma1(
.border-radius(10px);
}

Pentru a lucra cu prefixe, trebuie să utilizați mixins (același cod care știe ce să înlocuiască și unde). Exista truse gata făcute mixuri și biblioteci pentru CSS3
lesselements.com
github.com/jdmiller82/-lessins-
snipplr.com/view/47181/less-classes
roel.vanhintum.eu/more-less

Nu este necesar să compilați fișiere .less pe server sau în browser, pe cel terminat îl puteți obține local fișier CSSși îl folosești deja pe site
SimplLESS este o aplicație care compilează automat .less la CSS standard. Gratuit pentru toate platformele.
Less App este o aplicație similară, dar numai pentru Mac.

Fișierele SASS sunt procesate pe server, computerul client deja primește dosar gata.css

Avantajele preprocesoarelor:
+ Pe lângă prefixe, puteți face mult mai multe lucruri
+ Abilitatea de a procesa automat fișierul CSS (de exemplu, comprimarea, eliminarea lucrurilor inutile)
+ Memorarea în cache normală (deși LESS este stocată în cache folosind localStorage)

Dezavantajele preprocesoarelor:
– Pentru versiunea cu javascript - dependență de scripturile activate în browser
– Codul este generat cu toate prefixele posibile, nu numai cele necesare unui anumit browser

3. Generatoare

Această metodă este deja folosită de mulți. Doar deschideți-l și copiați de acolo cod gata cu prefixe.

Recent am încercat să caut un generator care să adauge automat proprietăți prefixate la o proprietate standard pe care am scris-o. S-a dovedit că există mai multe opțiuni.