6. februar 2012 kl. 14.14

CSS3: liv uden præfikser

• Website udvikling

Præfikser er en god ting. De hjælper browserproducenter med at implementere nye funktioner. Men udviklernes liv bliver kun vanskeligere af dem. Der er mange præfikser, nogle gange er der forskelle i syntaks.

Problemet er indlysende. Vi har brug for en måde at gøre arbejdet med præfikser lettere.

Det ville naturligvis være uklogt at stoppe med at bruge præfikser. Men det er ganske muligt at flytte ansvaret for at generere dem til værktøjer, der findes specifikt til dette formål. Jeg forsøgte at liste de mulige muligheder.

1. Forbehandlere

Essensen af ​​præprocessorer er, at forfatteren af ​​en stilfil kan bruge yderligere funktioner, som ikke er i CSS, såsom variabler, funktionsligheder og meget mere, efter først at have studeret syntaksen for præprocessoren, og præprocessoren vil allerede oprette normal fil stilarter, der erstatter variabler og anden kode med statiske værdier. Muligheden for at erstatte kode kan også bruges til automatisk at generere kode på tværs af browsere med præfikser.

Den mest berømte CSS-forprocessorer disse er LESS og SASS.

De er direkte konkurrenter, selvom der er forskel på dem. Begge kan bruges på serversiden, men LESS findes også som en javascript-fil, så du kan være særlig opmærksom på denne funktion.

MINDRE

Denne forprocessor har en syntaks, der er enklere end dens konkurrent. Det er muligt at behandle stilfiler på serversiden, men vi er nu interesseret i muligheden for at arbejde på klientsiden gennem en javascript-fil.

Forbindelse

Blanding
.border-radius(@radius: 3px) (
-webkit-border-radius: @radius;
-moz-border-radius: @radius;
grænse-radius: @radius;
}

Brug
#form1(
.border-radius(10px);
}

For at kunne arbejde med præfikser skal du bruge mixins (den samme kode, der ved, hvad der skal erstattes og hvor). Der er færdige sæt mixins og biblioteker til CSS3
lesselements.com
github.com/jdmiller82/-lessins-
snipplr.com/view/47181/less-classes
roel.vanhintum.eu/more-less

Det er ikke nødvendigt at kompilere .less filer på serveren eller i browseren, du kan få den færdige lokalt CSS fil og allerede bruger det på webstedet
SimpLESS er et program, der automatisk kompilerer .less til standard CSS. Gratis til alle platforme.
Mindre app - lignende applikation, men kun til Mac.

Serveren behandler SASS-filer, klientcomputeren modtager en færdiglavet .css-fil

Fordele ved præprocessorer:
+ Udover præfikser kan du gøre mange flere ting
+ Mulighed for automatisk at behandle CSS-filen (for eksempel komprimere, fjerne unødvendige ting)
+ Normal caching (selvom LESS cachelagres ved hjælp af localStorage)

Ulemper ved præprocessorer:
– For versionen med javascript - afhængighed af aktiverede scripts i browseren
– Kode genereres med alle mulige præfikser, ikke kun dem, der kræves af en bestemt browser

3. Generatorer

Denne metode bruges allerede af mange. Bare åbn den og kopier derfra klar kode med præfikser.

Jeg har for nylig prøvet at lede efter en generator, der automatisk tilføjede præfiksegenskaber til en standardegenskab, jeg skrev. Det viste sig, at der er flere muligheder.

Leverandørpræfikser er specielle præfikser, der tilføjes før navnet CSS-egenskaber og er fokuseret på eksperimentelle funktioner i visse browsere. Hver browser har sit eget leverandørpræfiks.

I dag vil vi gerne tale om leverandørpræfikser, nævne de mest almindelige og filosofere lidt over hensigtsmæssigheden af ​​deres brug.

Hvad er en sælger

Først og fremmest vil jeg gerne definere begrebet "leverandør", så det bliver klart for os alle, hvorfor CSS-præfikser kaldes for leverandørpræfikser og ikke noget andet. Sælger- en virksomhed eller et brand, der producerer produkter eller leverer tjenester og leverer dem under sit eget varemærke. Ordet kommer fra fransk vendere- sælge.

Hvad er leverandørpræfikser i CSS

I tilfælde af CSS-præfikser er leverandørerne browserproducenter, der bruger deres egne varemærke i forkortet form som et præfiks (præfiks) til visse CSS-egenskaber til identifikation. " Hvorfor bruge disse præfikser?", spørger du. Der bruges leverandørpræfikser forskellige browsere til implementering i liste CSS egenskaber og støtte til deres arbejde med egne motorer til nye eksperimentelle egenskaber, der endnu ikke officielt er kommet i omløb og ikke er tilføjet W3C-specifikationen. Med andre ord, nogle ejendom kan udføre en helt ny og ofte meget nyttig funktion, som tidligere skulle implementeres ved hjælp af specielle hacks, tricks, tricks eller endda javascripts. Denne egenskab er dog endnu ikke blevet tilføjet til standardegenskaberne og kan ikke fortolkes af alle browsere; til dette formål tilføjes et præfiks med navnet på den leverandør, som den tilhører, foran denne egenskab og i fremtiden, når fortolket browser CSS kode, vil ejendommen blive forstået korrekt og udføre den funktion, som den faktisk var beregnet til.

Liste over hovedleverandørpræfikser

Lad os nu give en liste over de vigtigste leverandørpræfikser, der findes på dette øjeblik og kendt for os.

• -o-- Opera browser
• -moz-- browsere fra Mozilla-familien (producent af den berømte Mozilla Firefox)
• -Frk-- Microsoft Explorer
• -webkit-- browsere, der bruger Webkit-motoren - Google Chrome, Safari
• -cab-- officiel alternativ browserÆble - Ikab
• -khtml-- en sjældent brugt KHTML-fortolker til KDE

For at bruge et eller andet leverandørpræfiks skal du blot vælge det, du har brug for, fra listen og tilføje det lige før den eksperimentelle egenskab, der endnu ikke er indført i den generelle specifikation, og nyde resultatet.

Her er for eksempel koden, der deaktiverer automatisk transformation(tilpas størrelse) tekst *:

Tekst-størrelse-tilpas: ingen; -moz-text-size-adjust: ingen; -ms-text-size-adjust: ingen; -webkit-text-size-adjust: ingen;

*Ejendom tekst-tilpas-ingen det giver mening at bruge det til mobile enheder, hvis browsere automatisk kan ændre størrelse på tekst på en side, hvilket gør den mere læsbar, men samtidig ødelægger layoutet og æstetikken.

Først beskriver vi ejendommen i generel opfattelse- som om det allerede var i specifikationen og understøttet af alle browsere, selvom det ikke er tilfældet endnu, men efter nogen tid vil det højst sandsynligt blive relevant, når ejendommen er godkendt. Derefter tilføjer vi den samme egenskab med forskellige præfikser for de tilsvarende browsere. Som du kan se, er der dog absolut intet kompliceret ved dette denne handling gør koden meget tungere, fordi vi faktisk har øget antallet af kodebytes med 4-5 gange, hvilket vil være ret mærkbart for sider med mange lignende stilarter. Og selve koden bliver mindre læsbar, fordi den ved gentagne gentagelser af det samme begynder at bølge i øjnene, og der er simpelthen en vis følelse af dårlig smag og dårlig optimering.

Går jeg lidt ud af emnet, vil jeg gerne sige, at der findes en programmeringsmetode, der hedder OOP (objektorienteret programmering). Så her er det hovedopgaven- reducere kode ved hjælp af klasser, funktioner osv. Denne metode eksisterer hovedsageligt, så udførelse af en specifik handling i forskellige dele af programmet ikke kræver at skrive identiske stykker kode. I tilfælde af OOP kan du blot henvise til en foruddefineret klasse og dens funktioner. Dette forenkler arbejdet og reducerer og optimerer koden markant. Næsten det samme sker i tilfældet med CSS med leverandørpræfikser - når de ikke er der, ser koden optimeret ud til alle browsere, og når de kommer utålmodige kodere til hjælp, der gerne vil løbe foran det langsomme lokomotiv kaldet W3C, koden bliver til et rod, der består af de samme linjer, der er kopieret 5 gange, og som adskiller sig fra hinanden med nogle uforståelige præfikser.

Det er selvfølgelig bedre at undgå at bruge leverandørpræfikser og ikke forsøge at overhale lokomotivet af en enkelt specifikation, men hvis der er et uimodståeligt ønske og et presserende behov for at bruge en eller anden CSS-ejendom, som endnu ikke er blevet accepteret af W3C, så kan du selvfølgelig bruge præfikser, ingen vil slå dig på håndleddet for dette med en lineal vil ikke være. Men efter vores mening er dette en dårlig form.

Hvad er der sket CSS hacks eller leverandørpræfikser
Hvis browseren ikke understøtter eller forstår en bestemt CSS ejendom, hvordan begynder man så pludselig at forstå denne egenskab efter at have brugt hacket?
Takket være leverandørpræfikser introducerer browserproducenter allerede eksperimentelle CSS3 ejendomme på eget ansvar.

CSS hacks de er - Leverandørpræfikser, leverandørsuffikser og leverandørendelser er præfikser, der bruges af browserproducenter (leverandører) til eksperimentelle CSS-egenskaber, som endnu ikke er blevet overtaget i standarden.

Leverandørpræfikser er skræddersyet til en specifik browser og giver den mulighed for at forstå eksperimentelle CSS-egenskaber og samtidig ignorere indgange, der er beregnet til andre browsere, dvs. ingen browser vil begynde at "ved et uheld" forstå en egenskab, der ikke er beregnet til den.

Det skal huskes, at ejendomme med leverandørpræfikser ikke overholder standarderne og vil ikke bestå validering, men de kan bruges pga. V i dygtige hænder dette er meget kraftfuldt værktøj. Og mange førende RuNet-studier drager fordel af dette.

Brug af leverandørpræfikser (hacks) er enkelt; en CSS-egenskab er skrevet for elementet i direkte form for browsere, der forstår det. Efter den, adskilt af et semikolon, er den samme egenskab, men med forskellige leverandørpræfikser for forskellige browsere. Browseren fra en sådan kode fortolker kun den egenskab, der er skrevet til den, og ignorerer dem, der er skrevet til andre browsere.

De vigtigste grunde til at bruge leverandørpræfikser er:

1. Hvis denne egenskab kun er designet til en bestemt browser og ikke er beskrevet i specifikationen eller CSS-modulet
2. Hvis CSS modul Ejendommen, som denne ejendom henviser til, er under udvikling af W3C og har endnu ikke nået status som kandidatanbefaling.
3. Hvis ejendommen kun delvist implementerer egenskabens funktionalitet beskrevet i CSS-modulet eller specifikationen

Takket være leverandørpræfikser implementerer browserleverandører allerede eksperimentelle CSS3-funktioner på egen risiko.

Koderen kan allerede implementere de fleste af funktionerne fra CSS3, inklusive forskellige overgange og animationer uden brug af scripts, men ved at bruge leverandørpræfikser.

Leverandørpræfikser for de mest almindelige browsere:

Leverandørpræfiks	Fabrikant	Browser	Browser motor
-o-, -op-, -xv-	Opera software	Opera	Presto
-moz-	Mozilla projekt	Firefox, SeaMonkey, Camino osv.	Gekko
-Frk-	Microsoft	Internet Explorer 8	Trident
-khtml-	KDE projekt	Safari op til version 3, Konqueror osv.	KHTML
-webkit-	Æble	Safari 3+, Google Chrome og osv.	WebKit
-cab-	Æble	iCab	WebKit

Skriveeksempel:

border-radius:15px 0 15px 0; /* Gyldig CSS 3-hjørneafrundingsegenskab, værdi (antal) angiver radius af afrundingen */
-moz- border-radius:15px 0 15px 0; /* Firefox */
-webkit- border-radius:15px 0 15px 0; /* Safari, Chrome */
-khtml- border-radius:15px 0 15px 0; /* Konqueror */

Fra forfatteren:-webkit-præfikset er så almindeligt i CSS i dag, at nogle websteder nægter at arbejde korrekt uden det. Mens leverandørens css-præfikser har været et klart tegn på mindre end perfekte egenskaber for udviklere i løbet af de sidste par år, har dette fået Mozilla til at tage et desperat, men nødvendigt skridt. I Firefox 46 eller 47 (udgivet i april eller maj 2016) planlægger Mozilla at introducere understøttelse af en række ikke-standardiserede –webkit-præfikser for at forbedre browserkompatibiliteten med det præfiks (selv på mobile enheder).

Ideen er ikke ny Microsoft Edge understøtter også forskellige -webkit- præfikser for kompatibilitet. Opera begyndte at understøtte -webkit- præfikser i 2012 og skiftede derefter til Webkit Blink-motoren. W3C og browserudviklere havde ikke planer om at bruge dette præfiks i webstedsudvikling:

"Den officielle W3C-politik siger, at eksperimentelle egenskaber ikke bør bruges i webstedskoden. Men folk bruger dem, fordi de ønsker, at deres websteder bruger den nyeste teknologi og ser cool ud."— W3C-side om optimering af indhold til forskellige browsere

Udviklere vil dog altid have adgang til de nyeste funktioner så hurtigt som muligt. Leverandørpræfikser har vendt op og ned på alt og givet Webkit-dominans, men jeg tror på, at præfikser har haft en enorm indflydelse på hurtig udvikling Internettet.

Mozilla og Microsofts metoder vil kun skade de fleste websteder. De fleste websteder vil allerede have –moz- præfikser forbundet, eller det vil vise sig med det nye Mozilla opdatering vil understøtte nye ejendomme uden behov for ændringer. Men som professionelle webudviklere er vi nødt til at lægge dette til ro og forstå, at nogle designs kan give blandede resultater. Du ved måske allerede, hvilke af dine projekter der vil blive ødelagt af denne opdatering. Webudviklere, det er tid til at genoverveje din tilgang til leverandørpræfikser og teste dem på websteder.

Nye præfikser

Mozilla vil inkludere en række –webkit- præfikser. Ud fra det, jeg har indsamlet, ser det ud til, at Mozilla ikke har til hensigt at matche sin liste med Edge-egenskaber. Ikke alle egenskaber behøver at være kompatible med Mozilla-motoren. Blandt de præfikser, som Mozilla vil tilføje, at dømme efter wiki-siden for kompatibilitet/mobil/ikke standard kompatibilitet, er følgende:

Webkit - til gradienter

Webkit-transformeres

Webkit-overgange

Webkit-udseende

Webkit-baggrundsklip

Webkit-enhed-pixel-forhold

Webkit-animation

Nogle andre egenskaber kan være i @-webkit-keyframes.

Test på tværs af browsere vil være kritisk

Hvis du, en webudvikler, ikke inkluderede præfikset -moz- for ikke at teste nye CSS-egenskaber i Firefox, og deadline nærmer sig, og klienten tvinger dig til at tilføje dette præfiks, så bliver du nødt til at teste webstedet igen i Firefox 46 eller 47. Disse versioner udkommer i april eller maj, så du har stadig lidt tid.

For at teste dit websted uden at vente på Firefox 46/47, kan du aktivere disse ændringer i Firefox Nightly ved at indstille layout.css.prefixes.webkit i about:config. Hvis du har installeret nyeste version Nat, så burde standarden være sand. Ikke alle ændringer af –webkit-præfikser virker i Firefox Nightly endnu, men det gør de. god platform for at teste, hvordan dit websted snart vil se ud. Jeg ville vente til marts, før jeg for alvor testede siden i Firefox Nightly.

Meget vigtigere er, at Microsoft Edge allerede fortolker og viser -webkit- præfikser på en lignende måde. Det betyder, at alle WebKit-stile på dit websted allerede vises i en browser, der var fuldstændig uventet. Hvis du endnu ikke har arbejdet med denne browser, så installer Windows 10 og få adgang til den for at teste websteder.

Leverandørpræfikser forsvinder gradvist

Heldigvis forsvinder leverandørpræfikser gradvist, efterhånden som udviklingsteams finder nye løsninger. Chrome/Blink-teamet ændrede deres tilgang en smule:

"Fremover vil vi, i stedet for at aktivere leverandørpræfikser som standard, beholde de almindelige egenskaber bag flaget "aktiver eksperimentelle webplatformsegenskaber" i about:flags, indtil disse egenskaber er aktiveret som standard."— Chrome/Blink-teamet

Firefox-teamet fulgte en lignende vej: "Den primære arbejdsretning hos Mozilla er nu at bevæge sig væk fra leverandørpræfikser ved at deaktivere dem eller overføre dem til tilstanden af ​​almindelige egenskaber, hvis de allerede er stabile. Dette er i det mindste vores generelle politik; individuelle tilfælde fortjener undtagelser. »— Boris fra Mozilla

Microsoft Edge sigter også mod fjernelse af præfiksunderstøttelse: "Microsoft forsøger også at slippe af med leverandørpræfikser i Edge. Det betyder, at udviklere, når de bruger specielle HTML5-tags eller CSS-egenskaber, ikke skal tilføje et særligt præfiks for Edge browser. I stedet vil udviklere skrive standardkode."— Mashable

Yndefuld nedbrydning ved hjælp af præfikser virker ikke længere

At bevæge sig væk fra leverandørpræfikser betyder kun én ting - teknikken med yndefuld nedbrydning gennem præfikser er ikke længere en mulighed. At isolere specifikke browsere gennem leverandørpræfikser (f.eks. til Chrome) var ikke formålet med disse præfikser; Udviklere er altid blevet opfordret til at bruge alle præfikser (–webkit- til –o-). Hvis du bruger en funktionalitet, der fungerer på ejendomme med leverandørpræfikser, og også har brugt den yndefulde nedbrydningsteknik i dit design til andre browsere, så virker dette ikke længere.

Konklusion

Tiderne ændrer sig. WebKits dominans var utilsigtet og forårsagede tumult og inkompatibilitet på internettet. Andre browsere søger at udvide kompatibiliteten ved at tilføje –webkit- præfikser. Gradvist, med forsvinden af ​​leverandørpræfikser, vil dette problem. Udviklere bør kontrollere, om brugen af ​​præfikser ikke forårsager uønskede konsekvenser i ikke-WebKit-browsere.

Oversættelse: Vlad Merzhevich

Udviklere har et had-kærlighedsforhold til leverandørens CSS-præfikser, som giver dem mulighed for at være på forkant med udførlige erklæringer:

Baggrundsbillede: -webkit-linear-gradient(#fff, #000); baggrundsbillede: -moz-lineær-gradient(#fff, #000); baggrundsbillede: -ms-lineær-gradient(#fff, #000); baggrundsbillede: -o-linear-gradient(#fff, #000); baggrundsbillede: lineær-gradient(#fff, #000);

Dette fungerer godt i teorien, men her er hvad der sker i virkeligheden.

• Oftest implementeres eksperimentelle funktioner først i Webkit-motoren, men der er ingen garanti for, at de vises i andre browsere.
• Nogle gange kan det være svært at afgøre, om en ejendom med et leverandørpræfiks er en del af CSS-specifikationen. Nogle browserleverandører standardiserer ikke egenskaber.
• Selvom standardegenskaben er ændret, understøttes ukorrekte egenskaber med leverandørpræfikser fortsat. Din gammel kode virker stadig, og du behøver ikke at gå tilbage til det for at rette det.

Du vil i stigende grad finde websteder, der kun bruger ét præfiks -webkit, selvom andre browsere understøtter egenskaben, eller den er meget brugt uden et præfiks (som border-raduis ). Chrome og Safari ser derfor bedre ud end konkurrerende browsere, og det er andre producenter ikke glade for.

Spørgsmålet blev rejst og diskuteret på W3C-mødet den 7. februar 2012.

Standardaktivister lærer folk at bruge Webkit. Du vil se fra præsentationer af fortalere for webstandarder, at de opfordrer folk til at bruge webkit-præfikset.

Vores opgave er at finde en fælles løsning.

Vi forsøger i øjeblikket at finde ud af, hvor mange og hvilke egenskaber med webkit-præfikset, der faktisk understøttes i Mozilla.

Hvis vi ikke understøtter webkit-præfikser, lukker vi os for en del af mobilnettet.

Lad os tage et øjeblik på at se ind i denne afløbsbrønd.

Browsere, der ikke er baseret på Webkit-motoren, understøtter -webkit-præfikset. Denne løsning overvejes af W3C.

Idéen vil højst sandsynligt mislykkes. To eller flere implementeringer af den samme ejendom vil ikke være kompatible, så udviklere vil ikke være i stand til at bruge dem nogen steder. Der vil ikke være nogen vindere, inklusive Apple og Google.

Men jeg er mere bekymret over den uoprettelige skade, der vil ske, hvis beslutningen bliver truffet. Når udviklere opdager, at webkit-præfikset fungerer i Firefox, IE og Opera, vil de forvente, at præfikserne virker i alle egenskaber. Alene vedtagelse af Webkit vil vokse eksponentielt, og browserproducenter vil blive tvunget til at implementere præfikser. På dette tidspunkt vil egenskaber med webkit blive en de facto standard uafhængig af W3C-specifikationen. Spil slut: åben web vil lukke.

Hvem er skyldig?

Vi kan pege fingeren på de næste.

W3C arbejdsgruppe

Hun bruger for meget tid på at vente på, at webstandarder modnes. Dette kan være uundgåeligt, men browserproducenter ignorerer denne proces.

Browser fabrikanter

I hastværket med at fremme nye teknologier er det nemt for producenter at tilføje et præfiks og glemme det. Web-udviklere efterspørger mere information: Overvejer W3C denne egenskab, og hvornår vil præfikset blive fjernet?

I en ideel verden ville eksperimentelle præfikser forsvinde, så snart browseren begyndte at understøtte standardegenskaben. Producenter vil ikke gøre dette, fordi det vil ødelægge websteder, men de kan gøre mere for at øge bevidstheden om problemet, såsom at frigive værktøjer til registrering af forældelse og vise fejlmeddelelser i udviklerkonsollen.

Apple og Google

Begge virksomheder er skyldige i at promovere webkit-præfikser, som om de var en standard del af den daglige HTML5-udvikling. Apple er anklaget for aktivt arbejde mod W3C.

Mozilla, Microsoft og Opera

Andre leverandører har fulgt Webkit-baserede browsere i måneder, hvis ikke år. Tilføjelse af webkit-præfikser er en latterlig beslutning, det er tid til at spille dit spil.

Hjemmeside Teknologer og evangelister

Vi elsker alle seje demoer, men evangelister glemmer ofte at nævne, at funktionerne er eksperimentelle og måske aldrig bliver fuldt understøttet af browseren. Ideelt set bør koden fungere i mindst to browsere, hvilket i det mindste betyder, at der kræves flere leverandørpræfikser.

Webudviklere

Vi er for dovne. Vi skriver browserspecifik kode, og selvom vi måske har gode intentioner om at rette op på det senere, gør vi det sjældent.

Kan du huske sidste gang, da udviklerne fokuserede på specifik browser? Det var IE6. Vi lever stadig med arven fra den beslutning et årti senere. Vil du virkelig have, at historien gentager sig?

Det er tid til at handle

Jeg er imod ikke-Webkit-browsere, der understøtter webkit-præfikser. I bedste fald gør de præfikser ubrugelige. I værste fald forstyrrer det hele standardiseringsprocessen. Du kan være enig eller uenig, men lad dine kolleger vide din mening gennem blogs og sociale medier. W3C og browserleverandørerne vil lytte til din mening, du skal bare vise dem det.

Test derefter dit websted i forskellige browsere. En lille yndefuld nedbrydning vil ikke skade, men at negligere en eller flere moderne browsere det her er dårligt. Ret din kode, ellers bidrager dit websted til dette problem.