Defensive HTML og CSS

...

Dette kan være helt passende for en regelmæssig opholds-applikation, men for en tredjepartsapp er det en komplet no-no. Grunden? Et sådant generisk klassenavn har en god chance for allerede at blive brugt af forældresiden. Hvis du introducerer denne stilregel, kan du tilsidesætte en eksisterende stilregel, der er udarbejdet af udgiveren og ødelægge deres layout. Eller på reglen kan deres regel overstyre dine og ændre størrelsen på din widget utilsigtet.

Løsningen? Forkaster alle dine klassenavne (og andre attributter) med en identifikator, der er unik for din ansøgning - et navneområde. I tilfælde af Stork-widgeten skal den foregående markering ændres for at se sådan ud:

...

Ideen er, at du navngiv din JavaScript kode, så du ikke erklærer globale objekter, der er i konflikt med kode, der kører på forældresiden. Det strækker sig til hvert stykke HTML, du indsætter i siden: ID'er, klasser, data- * attributter, form navne og så videre.

Namespacing HTML og CSS er et must for enhver tredjepartsprogram, der gøres direkte til udgiverens side. Dette er ikke kun nødvendigt for at forhindre modstridende CSS-regler; det er også tænkeligt, at forældrenes side har JavaScript, der spørger DOM for elementer, hvis identificerende egenskaber kan matche din egen. Vær streng i namespacing alt, hvad du sætter på DOM.

CSS specificitet

Det er vigtigt at bemærke, at selvom det er nyttigt, navngiver navnene HTML og CSS kun tilfælde, hvor udgiveren bruger stilarter eller forespørgsler, der refererer attributter med samme navn som din. Desværre kan din widget stadig være i konflikt med stilarter, der er defineret af forælderssiden, selvom deres CSS bruger id'er, klassenavne og attributter, der ikke direkte henviser til dine elementer. Dette skyldes, at nogle CSS-regler vejes tungere af browseren og kan have forrang over tilsyneladende ikke-relaterede regler, som du måske definerer. Dette fænomen betegnes som CSS-specificitet, og du skal forstå det, før du sikkert kan gengive elementer på forlagets side.

Lad os gå tilbage til containereksemplet fra det forrige afsnit om navneområder. Antag, at udgiverens HTML har en top-level DIV, der ombryder alt deres indhold, med et id-id:

... 
  ... 

Lad os også sige, at siden har følgende CSS, hvor den første regel er defineret af udgiveren, og den anden regel, der målretter mod storkontainer, tilføjes af dit tredjeparts script:

/* Publisher */#page div {background-color: green;}/* Camera Stork */.stork-container {background-color: blue;}

Nu, hvilken farve vil .stork-container have? Svaret kan chokere og forfølge dig: grøn. I dette enkle eksempel prioriterer udgiverreglen (#page div) over din tredjepartsprogrammets klassestyring (.stork-container). Dette sker, fordi browseren vejer regler, der indeholder ID'er højere end dem, der målretter mod klasser eller attributter.

CSS-regel prioriteter

W3C CSS-specifikationen beskriver, hvordan browsere er beregnet til at prioritere forskellige regeltyper. Her er en liste over disse regeltyper, bestilt fra højeste prioritet til laveste:

1. Inline-stilarter (style = "...")
2. id'er
3. Klasser, attributter og pseudo-klasser (: fokus,: svinger)
4. Elementer (div, span osv.) Og pseudo-elementer (: før, efter)

Ifølge dette diagram vejes inline-stilarter over alle efterfølgende regeltyper: ID'er, klasser og elementer. Dette fortsætter logisk ned på listen, med ID'er prioriteret højere end klasser og elementer, og så videre. Der er en undtagelse til denne liste: Egenskaber mærket med det vigtige søgeord har højeste prioritet. Men bemærk at det vigtige søgeord påvirker en enkelt ejendom inden for en regel, ikke hele reglen.

Hvad sker der, når du har flere CSS-regler af samme vægt, som hver især kunne tænkes at påvirke det samme element? Lad os se på et eksempel:

Eat your vegetables!

Hvad antager du, at spændets farve er? Svaret igen kan være overraskende: gul. Selv om disse regler er primært klassebaserede, anses den anden regel (.container span) mere specifik end den første regel, og den tredje regel (.stork-container .stork-msg) mere specifik end den anden. Hvordan virker det?

Inline-stilarter er konge

Hvad angår CSS-specificitet, er det. Hvis du husker fra tidligere i dette kapitel, nævnte vi, at inline-stilarter har den fordel, at de sjældent er i modstrid med forældrenes side. Nu er det klart hvorfor: De prioriteres over hver anden type regelmæssig CSS-regel (eksklusive dem med det vigtige søgeord). Hvis du skriver en særlig enkel widget, er det måske ikke en dårlig idé at bruge inline-stilarter; du vil undgå de fleste CSS-specificitetskonflikter.

Browseren bruger et simpelt scoringssystem til at bestemme hvilken regel der prioriteres. For en given regel er hver vælger, der komponerer den regel, værd at have en vis værdi. Disse værdier summeres for at skabe en specificitetsscore. Når flere regler påvirker det samme element, sammenligner browseren hver regels specificitetsscore, og reglen med den højeste score prioriteres. I tilfælde af et slips vinder den regel, der blev defineret sidste. Inline stil attributter: 1000; ID'er: 100; klasser, pseudoklasser og attributter: 10, elementer og pseudoelementer: 1.

Så ser vi tilbage til vores tidligere eksempel, ville disse CSS-regler have fået følgende scoringer, hvor højest scoring-reglen prioriteres af browseren: Du vil hurtigt bemærke, at disse ikke er almindelige tal. En specificitetsscore er faktisk en tuple af formen (a, b, c, d), med et væsen mere værdifuldt end b, b er mere værdifuld end c og så videre. Det betyder, at en stil, der skyldes en enkelt inline-stilattribut (1, 0, 0, 0), har højere specificitet end en regel med hundred ID-selektorer (0, 100, 0, 0).

• .Stork-container (0,0,1,0-en klasse vælger)
• .Stork-container spænding (0,0,1,1-en klasse selector, en element vælger)
• .Stork-container. Stork-msg (0,0,2,0-to klasse selektorer)

På dette tidspunkt skal du have et godt håndtag om, hvordan CSS-specificitet fungerer, og hvorfor browseren prioriterer nogle regler over andre. Du vil herefter sætte denne viden til brug, da vi udforsker nogle metoder til at skrive CSS, der står højt i modsætning til modstridende udgiver stilarter.

Overspecificere CSS

Den første og enkleste metode til at skrive CSS, der ikke er i konflikt med udgiverens side, er at overspecificere dine regler. Dette betyder at deklarere yderligere selektorer for at øge specificiteten af ​​dine regler, sådan at når browseren sammenligner dine regler med dem fra forælderssiden, vil de sandsynligvis score højere og blive prioriteret.

Lad os se på dette i praksis. Overvej dette reviderede eksempel på Stork-widgetbeholderen, der nu har to containerelementer med hver en unik ID:

Mikon E90 Digital SLR
  "/> 
  $ 599 
  4,3 / 5,0 • 176 Anmeldelser 

Den ledsagende CSS for denne HTML kan så se sådan ud:

#stork-main #stork-container { ... }#stork-main #stork-container .stork-product { ... }#stork-main #stork-container .stork-price { ... }

Ved at redundant specificere begge container ID'er som overordnede vælgere af alle dine CSS regler, giver du effektivt dine CSS regler en minimum specificitets score på (0,2,0,0). Derefter vil udgiverens generiske #page-regel fra tidligere ikke længere være i konflikt med din widget, fordi den kun bruger et enkelt id. Hverken rent klasse- eller elementbaserede regler vil heller ikke være i konflikt, fordi de er en hel CSS-vægtklasse under ID s. Selvom det for udvalgt formål er helt unødvendigt at angive et andet id til dine regler, fungerer det som en effektiv enhed til at øge specificiteten.

Bevar din sanity med en CSS preprocessor

At skrive overspecificeret CSS kan være en reel træk: du skal hele tiden omskrive de samme id'er igen og igen for hver enkelt af dine CSS-regler. Du kan afhjælpe dette ved at bruge en CSS preprocessor, som udvider CSS-sproget med yderligere funktioner som evnen til at erklære indlejrede hierarkier af regler. For eksempel kan du bruge den tidligere CSS preprocessor til at skrive det forrige eksempel som dette:

#stork-main {#stork-container {.stork-product { ... }.stork-price { ... }}}

En række populære CSS preprocessorer er tilgængelige i dag, som alle har forskellige funktionssæt. Blandt de mest populære er MINDRE,Sass, og Stylus.

På forsiden kræver dette eksempel, at din widget bruger topniveau containere med ID'er, hvilket ikke er praktisk for widgets, der kan gengives flere gange på samme side. Derudover er det stadig ikke bulletproof: en udgiver kan følge din ledelse og overspecify deres egne CSS regler, hvilket resulterer i det samme problem du havde før.

Men dette er et usandsynligt scenario, især da du har redundant specificeret to id'er i hver af reglerne. Du kan alternativt bruge en, men det vil naturligvis være mere sårbart. Virkeligheden er, at de fleste udgivere bruger sane CSS-regler, og at overspecificere dine regler som dette vil være kompatible med de fleste af dem.

Overspecificerende CSS blandes ikke med kodekvalitetsværktøjer

Hvis du tager for at overspecificere dit CSS som dette, kan du finde en usandsynlig fjende: værktøjer, der evaluerer kvaliteten af ​​din CSS-kode, såsom CSS Lint, Google Page Speed ​​og Yahoo's YSlow. Disse værktøjer vil indikere, at du redigerer CSS-selektorer, og de vil råde dig til at fjerne sådanne selektorer for at reducere filstørrelsen og forbedre browsernes CSS-ydeevne. Desværre er disse værktøjer ikke programmeret med tredjeparts scripts i tankerne, og vurderer ikke rimeligt brugen af ​​overspecificerende CSS. Fordelene ved overspecifikation for tredjepartsapplikationer vil opveje den ekstra filstørrelse og minuscule ydeevne hit.

Misbrug! Vigtigt

Hvis du mener, at overspecifying din CSS med ekstra ID eller klassevalgere ikke går langt nok, kan du bryde ud i nukleare indstillingen: det vigtige søgeord. Egenskaber inden for en CSS-regel, der idrætter det vigtige søgeord, prioriteres højest af alt, selv over inline-stilarter. Dette skyldes, at det vigtige søgeord er designet til at give browserenne brugerne en sikker måde at overstyre "forfatter" (udgiver) stilarter i tilfælde af browser plugins eller webstedsspecifikke stilarter. Du kan misbruge det vigtige ved at bruge det på alle dine CSS-egenskaber og prioritere dem effektivt over alle andre regler.

Sådan kan du bruge det vigtige søgeord på en enkelt CSS-regel:

.stork-price {font-size: 11px !important;color: #888 !important;text-decoration: none !important;display: block !important;}

Da det er pr. Ejendom, skal det vigtige søgeord gentages som dette, som kan blive en træk over et langt og komplekst stylesheet. Men i bytte får du et støbt sæt stilark, der meget næppe vil blive nulstillet af forlagets side.

Det er stadig tænkeligt, at udgiveren igen kunne bruge! Vigtigt at målrette mod dine elementer og sætte deres egne stilarter, hvorefter de sandsynligvis målrettet mod dine elementer for tilpasning. På den ene side kan det være frustrerende, hvis du forsøger at opretholde et ensartet udseende. Men hvis du har besluttet at tillade udgivere at tilpasse din widget, er dette sandsynligvis ønsket adfærd.

En ting skal være klart: at dele DOM med udgiveren kan gøre det særligt svært at lave en konsekvent stylet widget. Selvom du kan tage skridt til at overspecificere dine CSS-regler for at reducere sandsynligheden for konflikter, er det altid muligt for udgiveren at målrette dine elementer med deres regler, enten ved et uheld eller med vilje.

Men hvis du deler DOM med udgiveren, hvad der forårsager så meget sorg, er det muligt at gøre din widget slukket af DOM? Hvorfor, ja ja det kan du.

Resumé

For en tredjeparts JavaScript-applikation kræver indsprøjtning af HTML og CSS på udgiverens side mere pleje, end hvis du tilføjer markering til et "sikkert" miljø. Du skal sørge for, at når du udsender HTML til siden, sænker du ikke siden med en blokeringsoperation. Du skal også overveje, at dit script kan blive inkluderet flere gange på samme side, og det skal gøre flere forekomster yndefuldt. Derudover bør du vælge en optimal metode til at injicere CSS på forlagets side - enten ved at indføje alle dine stilarter, tilføje linkelementer eller indlejre CSS-regler i JavaScript.

Men bare at få HTML og CSS på siden er ikke nok. Du skal anerkende, at elementer, du introducerer til DOM, kan være i konflikt med forældresiden. Du skal også overveje, hvordan dine stilarter kan komme i konflikt med eksisterende stilarter, der er defineret af udgiveren. Du kan bruge en række teknikker til at reducere virkningen af ​​overordnede stilarter på din widget: ved at overspecificere dine CSS-regler eller præsentere dit indhold bag en iframe, uanset om det er en src-mindre iframe eller en, der indeholder et eksternt HTML-dokument.

Hvilke teknikker bruger du, når du producerer CSS og HTML til tredjepart? Er du nogensinde faldet tilbage! Vigtigt? Lad os vide i kommentarerne.

Fremhævet billede / miniaturebillede, forsvar billede via Shutterstock.