Share
Jeg har et lite kjæledyr som jeg skal dele med deg. På nettene når jeg avslutter en ny CSS3 opplæring for Nettuts + - vanligvis mens du hører på min favoritt Biebster sanger - klikker jeg publisere, og så venter du på hvor lang tid det tar før en leser legger en kommentar som inneholder uttrykket, "Men det bekrefter ikke."
Her er saken om validering: det er et verktøy. Ikke noe mer; intet mindre; bare et verktøy.
Så her er saken om validering: det er et verktøy. Ikke noe mer; intet mindre; bare et verktøy. Ved første øyekast, skjønt, er det fornuftig, ikke sant? Vi likestiller validering med beste praksis, mye som JavaScript og JSLint. Langs denne tankegangen, hvorfor ville vi ikke ha en perfekt 100% score? Vel det er tingen: det gjør vi; Det oppstår imidlertid problemer når poengsummen har forrang over vår egen logikk.
For å teste oppslag og stilark, kan du besøke:
Alternativt kan du installere den nyttige Firefox-tilleggsprogrammet, Webutvikler, som blant annet tilbyr de praktiske dandy "Validate HTML" og "Validate CSS" -koblinger, samt muligheten til å validere selv dine lokale filer.
På dette tidspunktet vil en rapport bli generert, som viser noen feil at validatoren kommer over. Men her ligger gni.
Absolutt ikke. Jeg kan tenke meg at, spesielt for de som bare bryter inn i denne bransjen, uttrykket "nettsteder trenger ikke å bestå validering" forvirrer hælen ut av dem.
"Validering er ditt varslingssystem om å introdusere feil i sidene dine, som kan manifestere seg i interessante og vanskelig å bestemme måter. Når en nettleser møter ugyldig HTML, må den ta et utdannet gjetning om hva du mente å gjøre forskjellige nettlesere kan komme med forskjellige svar. "
- Opera Developer Community
Når det er sagt, er sluttresultatet faktisk, irrelevant.
Husk dagene da vi (eller i det minste noen av oss) limte inn disse validerings knappene til bunntekst av våre nettsider? Så morsomt; hvem var de for? Besøkende på nettstedet? Ha ha; Jeg håper ikke! Men her er saken: da var validering egentlig ikke en standard. 
Nei; Faktisk, hvis du selv plaget å validere HTML og CSS, var du en standarder altomfattende, kanten dude! Noen ganger er det enkelt å glemme at nettstandarder er et relativt nytt konsept.
For mange år siden, da jeg pleide å delta i CSS fora, mislyktes det aldri: hver gang et nytt medlem ba om hjelp på et merkelig layoutproblem, var vårt første svar vanligvis noe i tråd med "Yvår nettside validerer ikke. Løs feilene, og kom tilbake til oss hvis det fortsatt er problemer."Mange ganger er utilsiktede layoutproblemer resultatet av unclosed elementer, som a div. I disse tilfellene kan validering være en stor hjelp.
Så hva forandret seg? Er validering ikke lenger nødvendig? Tillater HTML5 oss å skrive forferdelig mark-up uten en annen tanke? Er den nye HTML5-doktypen magisk-infisert? Ikke i det hele tatt. Validering er et nyttig verktøy som gjør det mulig for oss å identifisere ubesvarte lukkede koder, ekstra semikoloner, osv. Når det er sagt, sluttresultatet er, faktisk irrelevant. Det er ikke et magisk nummer - som 100% kontakter Arkitekten bak kulissene, og instruerer ham til å søke bonuspoeng på nettstedet ditt. Denne poengsummen tjener ikke noe høyere formål enn å gi deg tilbakemelding. Den bidrar heller ikke til tilgjengelighet, og peker heller ikke på beste praksis. Faktisk kan validatoren være misvisende, som den signalerer feil Det er ikke feil, av en hvilken som helst del av fantasien. HTML4-validatoren har raskt blitt utdatert, men heldigvis har W3C en ny HTML5-validator (fortsatt eksperimentell) som er mye bedre.
Nå, husk at godt formet oppslag kan øke SEO; Det er imidlertid ingen spesifikk korrelasjon mellom SEO og en valideringspoeng.
HTML5 standardiserer mange av funksjonene som noen nettlesere har støttet i årevis, for eksempel tilpassede attributter (via data- prefiks) og ARIA-attributter, som mislykkes i W3Cs HTML4-validator.
Når du tester nye design, må du kontrollere eksperimentell HTML5 validator alternativ. Med dette alternativet kan du bruke de støttede CSS3-egenskapene, tilpasset data- attributter og mer.
Aldri noensinne, noensinne, kompromittere bruken av de nyeste CSS3-teknikkene og -selektorene for valideringens skyld.
Hva om vi strever for minst en 75% score? Jeg forstår tanken, som jeg tenkte på den måten også på et tidspunkt; men igjen er det irrelevant. Når du validerer, bør du fokusere på å bestemme hvor du har gjort feil. Validering er ikke et spill, og mens det kan være morsomt å teste dine ferdigheter for å avgjøre hvor høyt du kan få poengene dine, må du alltid huske: det spiller ingen rolle. Og aldri, noensinne, noensinne, kompromittere bruken av den nyeste doktypen, CSS3 teknikker og selektorer for valideringens skyld..
Den skitne hemmeligheten til nettlesere er at de aldri utfører HTML-validering mot en DTD. Doktypen du legger øverst på dokumentet, slår parseren inn i en bestemt modus, men ingen operasjoner innebærer å laste ned doktypen og verifisere at koden samsvarer. Hva betyr dette? Det betyr at en grunnleggende syntakseparser håndterer HTML, med unntak angitt for selvlukkende koder og blokk mot inline-elementer (og jeg er sikker på at andre situasjoner også).
- Nicholas Zakas
Avhengig av alternativene du angir før du sjekker designene dine (HTML4 vs HTML5), vil validatoren skrike som en baby når det kommer til:
Ahh, nettleser hacker ... skal du bruke dem? Svaret på det spørsmålet har blitt diskutert til døden, og det overskrider absolutt omfanget av denne opplæringen. Vær imidlertid oppmerksom på at bruk av IE6-underskore-hack vil for eksempel mislykkes validering.
Av denne grunn foretrekker mange designere å bruke ikke-bryt teknikker i stedet.
Så:
/ * Mislykkes validering * / #myElement _position: relative; / * Måler bare IE6 * /
Blir:
/ * Passerer validering * / * html #myElement posisjon: relative; / * mål IE6 * /
Årsaken til denne tankegangen er, hva hvis i fremtiden sier, vil Internet Explorer 10 også gi egenskaper som er prefiks med underskrift? I slike tilfeller vil din IE6-bare (så du tenkte) styling også bli brukt til IE10 og utover, antagelig. Nå er sannheten i saken at dette aldri ville skje, da det ville ødelegge et stort antall nettsteder. Når det er sagt, er denne metoden for nettlesermålretting faktisk en hack. Bortsett fra i mindre eller sjeldne tilfeller, er det bedre å bruke et betinget stilark, eller en form for funksjonsdeteksjon for å målrette mot bestemte nettlesere.
Selv om vi alle kan være enige om at du bruker flere selgerprefikser til egenskaper, alt for å oppnå, sier avrundede hjørner, er utrolig kjedelig, bør du takke de heldige stjernene dine at nettleservirksomhetene eksperimenterte med disse teknologiene før de ble offisielt anbefalt.
Hadde
webkitikke eksperimentert med CSS-gradienter, og hvis Mozilla ikke var forbedret på deres foreslåtte syntaks, ville gradienter ikke være like mye støttet i den nåværende generasjonen av moderne nettlesere som de er i dag. Du ser, nettlesere har en stor hånd i å forme fremtiden for nettet.
.boks bakgrunn: # 666; bakgrunn: -moz-lineær-gradient (topp, svart, hvit); bakgrunn: - webkit-gradient (lineær, venstre topp, venstre bunn, fra (svart) til (hvit)); bakgrunn: lineær gradient (topp, svart, hvit);
Med alt som er sagt, vil bruken av disse leverandørprefixene føre til at stilarkene mislykkes. Men det er greit. ikke la det bekymre deg en bit.
Lær reglene slik at du vet hvordan du skal bryte dem ordentlig.
Dessverre, selv nå velger mange designere å bruke, i vårt eksempel ovenfor, bilder for å lage gradienter - hvis bare for å skape deres valideringspoeng tilbake til 100%. Hvis du faller inn i denne leiren, gjør du det feil.
Hvis du bare tar en ting fra denne artikkelen, husk at validering er bare et verktøy. Så snart du kompromitterer din egen logikk og teknikker for å appellere en validator og oppnå en meningsløs poengsum, slutter det å være et verktøy. Når det er sagt, bruk det, og bruk det ofte!
Accentsconagua