Tekniker för gradvis nedbrytning av css. Vad är graciös nedbrytning i webbdesign? Graciös nedbrytning med prefix fungerar inte längre

Från författaren: Prefixet -webkit- är så vanligt i CSS idag att vissa sajter vägrar att fungera korrekt utan det. Medan för utvecklare har leverantörens css-prefix under de senaste åren inneburit ett direkt tecken inte riktigt perfekt jobb egenskaper ledde detta till att Mozilla tog ett desperat men nödvändigt steg. I Firefox 46 eller 47 (släpptes i april eller maj 2016) planerar Mozilla att introducera stöd för en serie icke-standardiserade –webkit-prefix för att förbättra webbläsarens kompatibilitet med det prefixet (även på mobila enheter).

Tanken är inte ny Microsoft Edge stöder även olika -webkit- prefix för kompatibilitet. Opera började stödja -webkit- prefix 2012 och bytte sedan till Webkit Blink-motorn. W3C och webbläsarutvecklare planerade inte att använda detta prefix i webbplatsutveckling:

"Officiell W3C-policy säger att experimentella egenskaper inte ska användas i platskod. Men folk använder dem för att de vill att deras webbplatser ska använda den senaste tekniken och se coola ut."- W3C-sida om innehållsoptimering för olika webbläsare

Utvecklare vill dock alltid komma åt de senaste funktionerna så snabbt som möjligt. Leverantörsprefix vände upp och ner på allt och gav Webkit-dominans, men jag tror att prefix hade en enorm inverkan på Internets snabba utveckling.

Mozilla och Microsofts metoder kommer bara att skada de flesta webbplatser. De flesta webbplatser kommer redan att ha –moz- prefix aktiverade, eller kommer att upptäcka att med den nya uppdateringen kommer Mozilla att stödja de nya egenskaperna utan att behöva göra ändringar. Men som professionella webbutvecklare måste vi lägga det här och förstå att vissa designs kan ge blandade resultat. Du kanske redan vet vilka av dina projekt som kommer att förstöras av den här uppdateringen. Webbutvecklare, det är dags att ompröva din inställning till leverantörsprefix och testa dem på webbplatser.

Nya prefix

Mozilla kommer att inkludera ett antal –webkit- prefix. Av vad jag har samlat in verkar det som att Mozilla inte har för avsikt att matcha sin lista med Edge-egenskaper. Alla egenskaper behöver inte vara kompatibla med Mozilla-motorn. Bland prefixen som Mozilla kommer att lägga till, att döma av wikisidan Kompatibilitet/Mobil/Icke-standardkompatibilitet, är följande:

Webkit - för gradienter

Webkit-transformers

Webkit-övergångar

Webkit-utseende

Webkit-bakgrundsklipp

Webkit-enhet-pixel-förhållande

Webkit-animation

Vissa andra egenskaper kan finnas i @-webkit-keyframes.

Testning över webbläsare kommer att vara avgörande

Om du, en webbutvecklare, inte inkluderade prefixet -moz- för att inte testa nya CSS-egenskaper i Firefox, och deadline närmar sig, och klienten tvingar dig att lägga till detta prefix, måste du testa webbplatsen igen i Firefox 46 eller 47. Dessa versioner kommer att släppas i april eller maj, så du har lite tid kvar.

För att testa din webbplats utan att vänta på Firefox 46/47 kan du aktivera dessa ändringar i Firefox Nightly genom att ställa in layout.css.prefixes.webkit i about:config. Om du har den senaste versionen av Nightly installerad bör standardinställningen vara sann. Inte alla ändringar av -webkit-prefix fungerar i Firefox Nightly ännu, men det är fortfarande ett bra ställe att testa hur din webbplats snart kommer att se ut. Jag skulle vänta till mars innan jag på allvar testade sajten i Firefox Nightly.

Mycket viktigare är att Microsoft Edge redan tolkar och visar -webkit-prefix på ett liknande sätt. Det betyder att alla WebKit-stilar på din webbplats redan visas i en webbläsare som var helt oväntad. Om du ännu inte har arbetat med den här webbläsaren, installera sedan Windows 10 och få tillgång till den för att testa webbplatser.

Leverantörsprefix försvinner gradvis

Lyckligtvis försvinner leverantörsprefix gradvis när utvecklingsteam hittar nya lösningar. Chrome/Blink-teamet ändrade sitt tillvägagångssätt lite:

"Framöver, istället för att aktivera leverantörsprefix som standard, kommer vi att behålla de vanliga egenskaperna bakom flaggan 'aktivera experimentella webbplattformsegenskaper' i about:flags tills dessa egenskaper är aktiverade som standard."— Chrome/Blink-teamet

Firefox-teamet följde en liknande väg: "Den huvudsakliga arbetsinriktningen på Mozilla är att flytta bort från leverantörsprefix, genom att inaktivera dem eller överföra dem till tillståndet för vanliga fastigheter om de redan är stabila. Detta är åtminstone vår allmänna policy. Enskilda fall förtjänar undantag. »— Boris från Mozilla

Microsoft Edge siktar också på att ta bort prefixstöd: "Microsoft försöker också bli av med leverantörsprefix i Edge. Detta innebär att utvecklare, när de använder speciella HTML5-taggar eller CSS-egenskaper, inte behöver lägga till ett speciellt prefix för Edge webbläsare. Istället kommer utvecklare att skriva standardkod."— Mashbar

Graciös nedbrytning med prefix fungerar inte längre

Att gå bort från leverantörsprefix betyder bara en sak – tekniken med graciös degradering genom prefix är inte längre ett alternativ. Att isolera specifika webbläsare genom leverantörsprefix (till exempel för Chrome) var inte syftet med dessa prefix. Utvecklare har alltid uppmuntrats att använda alla prefix (–webkit- till –o-). Om du använder någon funktionalitet som fungerar på egenskaper med leverantörsprefix, och även har använt den graciösa nedbrytningstekniken i din design för andra webbläsare, så fungerar detta inte längre.

Slutsats

Tiderna förändras. WebKits dominans var oavsiktlig och orsakade uppståndelse och inkompatibilitet på Internet. Andra webbläsare vill utöka kompatibiliteten genom att lägga till –webkit- prefix. Gradvis, med försvinnandet av leverantörsprefix, kommer det här problemet. Utvecklare bör kontrollera om användningen av prefix inte orsakar oönskade konsekvenser i icke-WebKit-webbläsare.

I den här artikeln kommer vi att försöka förstå skillnaden mellan två principer för att skapa en sida baserad på responsiv webbdesign: Progressive Enhancement och Graceful Degradation.

Värdigt förfall

Graciös nedbrytning, eller "misslyckande tolerans", är ett bredare begrepp som inte bara gäller webbdesign. I en allmän mening innebär det ett systems förmåga att fungera även om några av dess komponenter misslyckas. Och ju allvarligare felet är, desto lägre är kvaliteten på systemet eller arbetet med systemet, men samtidigt förblir systemets huvudfunktionalitet i drift.

Graciös nedbrytning kan uttryckas i förmågan att arbeta med JavaScript inaktiverat, i korrekt visning av webbplatsen i en webbläsare utan stöd för CSS3-specifikationen, i adekvat visning av webbplatsen med inaktiverade bilder. Alla dessa fel bör inte påverka driften av webbapplikationen. Men om allt fungerar är det mycket bekvämare för användaren att använda webbplatsen.

Om vi ​​betraktar ett specifikt exempel, till exempel inom området för webbgränssnittsdesign, kan denna princip formuleras som "systemet kan arbeta med JavaScript helt inaktiverat, men med JavaScript aktiverat kommer det att vara mycket bekvämare att arbeta med." Frågan är inte om det kan finnas en situation där JS är inaktiverat eller inte fungerar helt, eller varför detta händer. Denna situation tas som given. Designern måste utveckla ett gränssnitt som fortsätter att fungera, om än med JS inaktiverat.

För att följa denna princip måste du ofta göra om logiken för formulärbearbetning på serversidan. Detta tillvägagångssätt kommer dock att löna sig om du tänker på feltolerans vid formulärplaneringsstadiet.

Överensstämmelse med principen om graciös nedbrytning tillåter användare (och varje användare är en potentiell kund) att kunna arbeta med webbplatsen i alla situationer.

Progressiv förbättring

Progressiv förbättring är en princip som tillsammans med mobile first skapar teoretisk grund för "responsiv" (adaptiv) webbdesign. Dess namn säger redan att den positionerar skapandet av en webbsida i etapper, cykliskt, enligt principen "från enkel till komplex." I vart och ett av de förplanerade stadierna ska sidans utseende bli vackrare, bättre och bekvämare, men all funktionalitet bör vara tillgänglig initialt.

Är ett mer speciellt fall av graciös nedbrytning , eftersom alla webbsidor som är byggda på den helt kommer att följa principen om graciös degradering.

Att skapa en sida med principen om progressiv förbättring består vanligtvis av följande steg:

  • Skapa en sida på en "ren" basisHTML
    I detta skede skapas en fullt fungerande sida, som endast består av HTML-kod, som är semantiskt och logiskt korrekt, och därför kan tolkas av vilken webbläsare som helst, även den enklaste. I detta skede utförs ingen formatering och webbläsaren själv formaterar sidan enligt de standarder som ingår i den. Progressiva förbättringar insisterar på att det första steget är det viktigaste, eftersom det inte finns något mer värdefullt på webben än innehåll.
    Kort: skapa en semantisk och logisk dokumentstruktur
  • Lägga till reglerCSS
    I detta skede används en CSS-tabell av det gamla formatet: ett uppmärkningsrutnät läggs till, element placeras, bakgrundsbilder appliceras på block, stilar, färger och textstilar ändras. I allmänhet får sidan ett nytt stiliserat utseende, blir vackrare och trevligare.
    Kort: ger ett dokuments utseende
  • Använder CSS3
    Nu kan du tillämpa alla effekter och förbättringar som tillhandahålls av CSS3-specifikationen på dokumentet. Det vill säga, lägg till genomskinlighet, skuggor, rundade hörn för block, jämna animerade övergångar för pseudoklasser eller formelement.
    Kort: ger perfektion utseende dokumentera
  • Skapar manus påJavaScript
    I detta skede skapas alla effekter och principer för interaktion av webbsidan med användaren med hjälp av JavaScript. Dessa inkluderar AJAX-förfrågningar, dynamisk laddning eller datavalidering, animeringseffekter och widgets (till exempel Prototype eller jQuery). Generellt sett gör vi sidan mer användarvänlig.
    Kort: interaktion, interaktivitet, bekvämlighet

Låt oss försöka tillämpa detta tillvägagångssätt i praktiken. Vi kommer att utveckla och designa enklaste formen logga in på webbplatsen. I det första skedet kommer vi att skapa ett inloggningsformulär i ren HTML. Formen är inte så vacker, men den är fullt funktionell. Nedan visas sidkoden och resultatet i webbläsaren:

Nu i det andra steget kommer vi att ge formuläret en stil genom att applicera en stilmall på den som endast innehåller de regler som är tillämpliga på CSS utan speciella egenskaper. Låt oss lägga till en bakgrundsfärg, stoppning, justering. Nu ser formen bättre ut:

Låt oss nu lägga till reglerna från CSS3-specifikationen. Låt oss lägga till hörn i blocken, skuggor för textinmatningsfält, formatera knappen och använda nya väljare för att ta bort onödig utfyllnad överst. Vi får en förbättrad form:

I det sista skedet kan vi skapa en AJAX-förfrågan så att användaren kan komma åt sidan utan att behöva ladda om sidan.

I det här fallet, vid varje specifikt stadium (om det stöds av webbläsaren), kommer en fullt fungerande sida att visas. Men om webbläsaren stöder mer avancerad teknik, så blir sidan bara bättre.

Vilken princip ska du följa?

Om webbplatsen byggs så effektivt som möjligt enligt konceptet med graciös nedbrytning, blir resultatet ungefär detsamma som vad som skulle hända om progressiv förbättring användes. Så vad är skillnaden då?

Faktum är att det är ganska svårt att bygga en webbplats baserad på principen om graciös nedbrytning, eftersom få utvecklare kan göra det effektivt. I det enklaste fallet av graciös nedbrytning kan du göra följande: bygga webbplatsen för den senaste versionen av webbläsaren och sedan visa användarna ett meddelande som talar om för dem att de måste ladda ner ny version webbläsare. Samtidigt kanske utvecklarna inte bryr sig om hur sajten ser ut i äldre webbläsare. Ett annat exempel på dålig graciös nedbrytning är fullständig avstängning webbplatsfunktionalitet när JavaScript är inaktiverat. Ett slående exempel är att skicka meddelanden på Facebook.com.

Därför uppstod progressiv förbättring som svar på graciös nedbrytning av dålig kvalitet. Att designa sådana gränssnitt har blivit enklare och av bättre kvalitet, eftersom det finns tydligt definierade steg för att skapa ett gränssnitt.

Inom adaptiv design finns begreppet "mobil först", vilket på något sätt motsvarar begreppet progressiv förbättring, eftersom det kräver handling från enkel till komplex, från mobila skärmar till stationära datorer. Det är därför nyckeln till korrekt användning responsiv webbdesign beror på utvecklarens förmåga att tillämpa principerna för progressiv förbättring och mobil först.

Säkert, Internet Explorer innehåller ett stort antal fel i olika versioner, men med hjälp av villkorliga kommentarer kan du bekämpa dem och uppnå deras eliminering. Men vad ingenting kan fixa är att IE är hopplöst föråldrad. Medan andra webbläsare inkluderar fler och fler CSS3-egenskaper och stöder olika nymodiga teknologier, markerar IE tid. Utgivningen av IE9 kommer inte att lösa problemet, tidigare versioner detta kommer inte att avdunsta över natten. I en sådan situation den bästa lösningen det kommer att bli graciös försämring - principen att bibehålla prestanda när någon funktionalitet går förlorad.

Låt oss titta på denna teknik med ett litet exempel, där text visas i ett block och en knapp. Blocket och knappen har rundade hörn, och en liten skugga läggs också till blocket. Hittills använder webbläsare för CSS3 huvudsakligen specifika egenskaper med sina egna prefix:

  • Firefox - egenskaper som börjar med -moz-;
  • Safari och Chrome - egenskaper som börjar med -webkit-;
  • Opera - egenskaper som börjar med -o-.

Olika versioner av dessa webbläsare kan förstå vissa egenskaper både med och utan ett prefix, så för universalitet lägger de till flera egenskaper samtidigt. Så för att skapa rundade hörn behöver vi följande stil.

Moz-gräns-radie: 10px; /* För Firefox */ -webkit-border-radius: 10px; /* För Safari och Chrome */ border-radius: 10px; /* För Opera och IE9 */

Även om användningen av dessa egenskaper kommer att leda till ogiltiga CSS-kod, i det här fallet är det viktigare att arbeta i Firefox webbläsare 1.0, Safari 3.1, Chrome 2.0, Opera 10.50, IE9, såväl som deras äldre versioner. Exempel 1 visar hur man använder CSS3-egenskaper för att skapa skuggor och rundade hörn.

Exempel 1. Block med skugga

XHTML 1.0 CSS 2.1 CSS3 IE 8 IE 9+ Cr Op Sa Fx

Blockera

Du måste gå igenom 20 frågor som väljs slumpmässigt från databasen. För att klara testet räcker det att svara korrekt på minst 75 % av de föreslagna frågorna (15 eller fler frågor).

Resultatet av exemplet visas i fig. 1.

Ris. 1. Blockera vy i Safari

Samma exempel i webbläsaren IE8 och nedan visas i fig. 2.

Ris. 2. Blockvy i IE8

Även om elementens utseende skiljer sig åt i detalj, förblir funktionaliteten på sidan som helhet densamma. Knappen kan klickas, texten förblir densamma, inklusive dess färg och bakgrund, och det finns inga visningsfel. I själva verket är skillnaden bara i de små sakerna som utför dekorativa snarare än praktiska funktioner. Alla principer för graciös nedbrytning är uppfyllda.

Vad ger detta tillvägagångssätt i praktiken?

  • Låter dig aktivt använda dekorativa egenskaper hos CSS3 utan hänsyn till webbläsaren.
  • Motiverar att använda olika CSS3-effekter.
  • Det gör utvecklarens liv betydligt enklare, eftersom han inte längre behöver leta efter lösningar för föråldrade webbläsare.
  • Snabbar upp arbetsproduktiviteten.

Naturligtvis är graciös nedbrytning inte alltid tillämplig. Om layoutkraven indikerar stöd för äldre versioner, måste du leta efter alternativa lösningar, till exempel genom att använda bilder för rundade hörn. Men för det mesta ställs krav på layout utan att ta hänsyn till den allmänna situationen. Och om vi jämför alla fördelarna med graciös nedbrytning med nackdelen, som endast visar sig i det faktum att föråldrade webbläsare, särskilt IE8, inte visar sidan tillräckligt "vackert", kommer sympatier att vara på sidan av framstegen.

Jag har inte skrivit på länge, jag var tvungen att flytta till en plats utan internet (det är hemskt), vilket resulterade i att jag inte kunde skriva i bloggen. Idag vill jag prata om utvecklingsmetoden (layout) som delvis används i utformningen av min blogg.

I senaste versionerna Innovativa webbläsare (som FF 3.5, Opera 10) har introducerat några dekorativa effekter från den föreslagna CSS 3-specifikationen. Transparens, skuggor och zebraeffekten (striping) är nu tillgängliga utan användning av JavaScript eller ytterligare uppmärkning. Men vissa äldre webbläsare som fortfarande används har inte dessa funktioner, och det skulle vara tråkigt att tro att du inte kommer att ha chansen att använda dessa underbara effekter på några år till.

I den här artikeln kommer jag att prata om hur man gör snygga (inkrementella) förbättringar i webbläsare som stöder CSS3-funktioner och fortfarande ger en tillfredsställande layout för andra användare.

Vad är progressiv förbättring?

För att förstå begreppet "gradvis förbättring" måste du förstå principen om "graciös degradering", som beskrivs väl av följande citat:

Mild försämring innebär att din sida fortsätter att fungera även om den visas i en mindre än optimal webbläsare där avancerade effekter inte fungerar.
Fluid Thinking, av Peter-Paul Koch

"Inkrementell förbättring" använder samma metod endast från motsatt sida, istället för att oroa dig för att webbplatsen inte faller sönder i en gammal webbläsare, måste du tänka på innehållet först och helt enkelt lägga till funktioner i moderna program till designen för att förbättra användaren erfarenhet, medan den grundläggande tillståndslayouten fortfarande fungerar på äldre maskiner. Detta är för närvarande det bästa sättet att använda de nya funktionerna i CSS 3.

Exempel

Som ett exempel, låt oss göra en enkel navigeringsmeny som kommer att se lite snyggare ut beroende på CSS-stödet i din webbläsare.

Jag skulle vilja notera att jag i det här exemplet inte använder grafik, hack eller webbläsarspecifika prefix - alla förbättringar beror på de deklarerade kapaciteterna. Med det i åtanke är några av sakerna nedan bara för exempel och kanske inte är det bästa valet för att skapa faktiska webbplatser.

Märkning

Låt oss göra en enkel meny med en oordnad lista (ul):

Grundläggande stil

Som bas kommer jag att använda en stil som bara använder enkla lagerväljare. Det skapar en ram för varje element och ändrar bakgrunden när du håller musen över (på musen över). Detta bör fungera i alla webbläsare som gjorts under de senaste 7-8 åren (och möjligen mer).

CSS är väldigt enkel:

Ul (
bakgrundsfärg: blå;
border-bottom: 1px prickad #999;
list-stil: ingen;
marginal: 15px;
bredd: 150px;
}

li(
bakgrundsfärg: #fff;
kantlinje: 1px prickad #999;
border-bottom-width: 0;
typsnitt: 1.2em/1.333 Verdana, Arial, sans-serif;
}

li a (
svart färg;
display: block;
höjd: 100%;
stoppning: 0,25em 0;
text-align: center;
text-dekoration: ingen;
}

li a:hover ( bakgrundsfärg: #efefef; )

Det enda konstiga här är den blå bakgrunden

    ; Jag ska förklara detta senare. Med den här stilen kommer vi att ha följande grundläggande vy, den kommer att visas i IE6 så här:

    Grundläggande layout, så här kommer det att se ut i IE6 och andra äldre webbläsare.

    Tillämpa förbättringar

    IE7 var den första i IE-serien av webbläsare som stödde alla attributväljare från CSS 2.1, vilket också är vanligt i nästan alla andra webbläsare. Vi kan använda en av dem - barnväljaren - för att börja förbättra. Eftersom IE6 inte stöder underordnade väljare ignorerar den följande regler:

    Kropp > ul ( kantbredd: 0; )

    ul > li (
    kantlinje: 1px fast #fff;
    kantbredd: 1px 0 0 0;
    }

    li > a (
    bakgrundsfärg: #666;
    färg vit;
    font-weight: fet;
    }

    li:first--child a (färg: gul;)

    li > a:hover ( bakgrundsfärg: #999; )

    Med dessa CSS-regler ser listan ut så här:

    Menyn har nu en färgad bakgrund och fet text, och den första länken är markerad i en annan färg.

    Så här kommer IE7, Firefox, Safari och Opera att visa listan.

    Låt oss lägga mer vikt

    Nästa steg är att öka tonvikten med en egenskap som IE inte känner igen: Transparency. Vi behöver inte använda speciella väljare för detta, eftersom IE kommer helt enkelt att hoppa över egenskapen som den inte stöder:

    Li (opacitet: 0,9; )

    li:hover ( opacitet: 1; )

    Följande bild visar hur den här egenskapen fungerar i Opera, du kan se att listobjekten har fått en lätt blå nyans från bakgrunden

      . Vid muspekaren blir varje element helt ogenomskinligt:

      Du kan naturligtvis använda IE:s egen filteregenskap för samma effekt i IE samt webbläsarspecifika prefix (-moz-, -webkit-) för egenskaperna nedan. eftersom filtret inte är standardegenskap är det inte giltigt.

      Firefox 2 stöder transparens, men i senare webbläsare kan vi gå ännu längre. I Safari och Opera kan vi dekorera text med text-shadow-egenskapen:

      Li a:hover ( text-skugga: 2px 2px 4px #333; )

      Som följande bild visar har elementet en liten skugga när det svävar och verkar sticka ut något från sidan:

      Slutligen kan du se till att Opera fullt ut stöder de nya CSS 3-väljarna och lägga till ytterligare ett lager av förbättringar: bakgrundsfärgsvariabler med hjälp av n:te underordnade väljaren:

      Li:nth-child(2n+1) a ( bakgrundsfärg: #333; )

      li:nth-child(n) a:hover (
      bakgrundsfärg: #aaa;
      färg: #000;
      }

      li:first--child > a:hover (färg: gul;)

      Vi kommer att se en randig meny i Opera:

      Sammanfattning och slutsatser

      Bilden nedan visar hur den initiala uppmärkningen ser ut i IE6, IE7, Firefox, Safari och Opera, efter tillämpning av CSS-reglerna som beskrivs i den här artikeln. Som du kan se, när webbläsarstödet för CSS blir mer sofistikerat, blir menyerna mer eleganta och komplexa, och med hjälp av stegvisa förbättringstekniker förblir menyerna funktionella även i mycket gamla webbläsare.

      Naturligtvis har många webbläsare en rad andra egenskaper som jag inte har beskrivit här men som kan användas till exempel RGBA-färger och SVG som bakgrundsfärger.

Publikationer om ämnet