4 enkle teknikker til hurtigt at fejlsøge og rette din CSS-kode i næsten enhver bro. ser

4 enkle teknikker til hurtigt at fejlsøge og rette din CSS-kode i næsten enhver bro. ser

du har designet det perfekte layout til din nye og kommende hjemmeside. Men nu konvertere alle de smukke Photoshop PSD lagdelt fil til en perfekt kode er den udfordrende del. Det er ikke udfordrende, fordi du ikke ved, hvordan man koder, men mere udfordrende, fordi forskellige bro.sere gengiver din kode forskelligt, selv når du bruger en helt gyldig CSS-kode til at vise den fantastiske semantiske HTML5-kode, du har skrevet. Dette er endnu mere frustrerende, når du løser en fejl i en bro.ser, bliver nu en ny fejl i en anden bro. ser. Selvom det ikke er udfordrende, forestil dig nu, at du er tildelt til at rette en andens kode, der er overalt. Ofte er denne sidste sag den, der får dig til at trække dit hår og sige adskillige Vægtf ‘ er, før du helt forstår, hvad der foregår i deres kode, fordi du sandsynligvis kender hele dit stilark udenad, og denne nye kode er ikke tæt på nogen kodningskonvention. Imidlertid, øjeblik for at komme ned og beskidt med debugging at CSS kode er meget enklere og mindre frustrerende end før, takket være disse meget enkle værktøjer og teknikker.

1) Undersøg Element værktøj

Undersøg element langt er det bedste værktøj til at starte debugging noget CSS. Hvis du udvikler hjemmesider, så har du brug for det rigtige sæt af internetudviklingsværktøjer. Og heldigvis Inspect Element er nu integreret indbygget med alle moderne internetsøgere som en del af deres udviklerværktøjer. Dette værktøj giver dig mulighed for at vælge det specifikke element på den side, du gerne vil rette, og straks se, hvilke CSS-regler der anvendes på det element, der får dit valgte element til at blive vist på den måde. Alt hvad du skal gøre er bare at højreklikke og vælge “Undersøg Element” i genvejsmenuen.

nu har du fuld visuel adgang til alle de regler, der beregnes for dette element. Hvis du ikke har valgt det rigtige element, kan du blot klikke på kilden og fastgøre det nøjagtige element, du gerne vil diagnosticere. Som du ser på skærmbilledet ovenfor, kan du nu tilpasse dine CSS-regler. Ved hjælp af afkrydsningsfeltet i venstre side af hver CSS-egenskab kan du skifte den egenskab eller endda klikke på ejendommen og ændre dens værdi eller endda trykke på enter-tasten og tilføje nye regler for dit element. Selv mest forbløffende er, hvor let det er muligt at debugge en svævetilstand for et element ved blot at åbne rullemenuen ved siden af det valgte element og vælge :svævetilstand. Som du kunne se i højre panel, viser dette fantastiske værktøj dig endda stilarkfilen og linjenummeret på CSS-reglen, der udføres på denne side. Desuden er det mere forståeligt at forstå, hvorfor vores element har en 10ph top og bund polstring i stedet for 5PH, fordi reglen på linje 1026 af stil.css af vores medieforespørgsel CSS overskriver den gamle regel på linje 916 i samme fil. Det er endda muligt at se boksmodellen for det valgte element med dets aktuelle dimensioner uden at bruge en tredjeparts lineal eller måleværktøj. At have denne rigdom af information gør nu vores debugging job meget lettere. Antag, at dit typografiark – e-mail-formularfelt ikke ligner andre inputelementer, og du spekulerer på, hvordan du kan løse dette. Du inspicerer dette element og finder ud af, at fordi du bruger de nye HTML5-inputfelttyper, har din temadesigner ikke inkluderet nogen CSS-regler for input, så du tilføjer denne vælger til stilarket.

input,input{ border: 1px solid #ccc;}

Google Chrome har også lignende udviklerværktøjer, der aktiverer de samme funktioner. Det er endda muligt at ændre din fejlretningstilstand til skærmopløsningen på en enhed, som du gerne vil teste dit layout og finde ud af, hvordan dine medieforespørgsler CSS opfører sig under disse forhold.

disse udviklerværktøjer har meget kraftfulde funktioner, selv ud over CSS-udvikling, såsom DOM-inspektion, JavaScript-profilering, JavaScript-konsol, ressourceovervågningsværktøjer og et helt andet sæt funktioner, der har brug for deres eget tutorial-afsnit ud over denne artikel. Som du kunne se på billedet ovenfor, i Chrome developer tools, er det endda muligt at efterligne forskellige brugeragenter eller endda efterligne berøringshændelser som f.eks. Med disse værktøjer behøver du ikke engang aktivt at debugge din CSS i din smartphones mobile bro.ser, i det mindste til en vis grad.

hvilke udviklerværktøjer der er bedst, er et spørgsmål, som du vil finde ud af ved at eksperimentere. I slutningen af dagen afhænger det hele af, hvad du prøver at opnå, og om dette værktøjssæt giver dig mulighed for at komme til dit endelige mål. Jeg bruger personligt alle disse værktøjer til min fordel. Hver har noget, som jeg kan lide og finder nyttigt, når jeg vil debugge min kode. For eksempel finder jeg den lille firkantede farvepræsentation af sekskantfarverne ved siden af CSS-farveegenskaber på en eller anden måde nyttig, selvom jeg kan behandle RGB-farven i mit hoved og få omtrentlig farvegane visualisering, får disse små forskelle mig til at skifte mellem disse udviklerværktøjer.

Firebug

Firebug var et af de første værktøjer, der leverede inspector-funktionen. Det er et af de mest populære internetudviklingsværktøjer med næsten 3 Millioner gennemsnitlige daglige brugere. I skrivende stund er CSS-fejlfindingsværktøjer tilstrækkelige nok til, at jeg ikke kan bruge Firebug, men til JavaScript-fejlfinding i Firebug bruger jeg stadig Firebug.

bange for IE7? Vær ikke længere

du kan blive overrasket, men Internetudforsker har endda Inspect Element (Ctrl+B) funktion i deres udviklerværktøjer (F12). Selvom det ikke er så venligt som andre bro.Sers udviklerværktøjer, er denne funktion, der er indbygget i Internetudforsker 9, stadig meget nyttig til at teste dine layouts i IE7 og IE8 emuleret tilstand. Tilbage i de dage, hvor ingen af disse udviklerværktøjer var tilgængelige til fejlfinding af gamle IE-bro.sere, var denne anden teknik normalt meget praktisk.

2) Debug i stil

så godt som Inspect Element er, nogle gange har du ikke adgang til det værktøj, f.eks. Jeg elsker at kende grænserne for det element, jeg styler, så jeg ved, om der er overløb, eller flydende problemer, eller osv… af den grund tilføjer jeg en lys og mærkbar baggrundsfarve til det aktive element, jeg styler, og tager baggrundsfarven ud, når stylingen er færdig. Nogle gange går jeg frem og tilbage og justerer disse elementer, så jeg flytter bare fejlfindingskoden til slutningen af mit stilark og kommenterer det og fjerner det, når jeg har brug for det igen. På denne måde kan jeg hurtigt skifte debugging mode og se, hvordan hvert element er placeret på skærmen.

hvilket resulterer i …

i dette eksempel har jeg lige tilføjet debug kode til de vigtigste struktur blok elementer i min side. Nu Kan jeg se, hvor hvert indlæg starter, og hvor meget mellemrum der er mellem hvert indlæg eller kontrolelement i min sidebjælke, og hvis jeg vil tilføje et mellemrum mellem sidebjælken og hovedindholdet, kan jeg visuelt se det i lyse farver.

det modsatte af dette er også muligt ved at definere en række fejlfindingsregler og tilføje den klasse til det emne, vi ønsker at se. For eksempel har jeg ovenfor defineret en ny klasse kaldet debug med følgende kode.

.debug{ border:1px solid red; }

og når jeg vil debugge noget element, tilføjer jeg simpelthen debug klasse til det element.

<div class="foo debug">Div element with foo and debug classes</div>

3) Debug CSS ved hjælp af JavaScript

denne teknik ligner meget ovenfor, men nogle gange af nogle mærkelige grunde sker det, at ovenstående situation ikke er mulig. Dette er et stykke kode, der kommer til vores hjælp ved at anvende debug-klassen på foo-elementet eller endda tilføje CSS direkte til bjælkeelementet i dette tilfælde.

$(document).ready(function(){ $('.foo').addClass('debug'); $('.bar').css('border' : '1px solid blue'); });

denne situation kan ske meget sjældent, men jeg ved, at jeg har brugt denne teknik tidligere, så det er godt at vide.

4) Lær kaskaden at kende

nogle CSS-problemer er så almindelige som clearingflådene, at du vil falde i den fælde en gang, og næste gang du støder på noget lignende, ved du, hvad der forårsagede problemet, og hvordan du løser det. Generelt er de fleste af CSS-problemerne lette at løse, hvis du ved, hvordan CSS-reglerne tilsidesætter hinanden. For eksempel vil mere specifikke vælgere tilsidesætte mere generelle, eller ID-vælger tilsidesætter klassevælgeren, eller !important – erklæring har forrang for en normal erklæring. At lære kaskaden at kende hjælper dig med at løse din Cascading Style Sheets-kode hurtigere.

her er et eksempel direkte fra V3C spec om, hvordan vælgerspecificitet fungerer.

nogle eksempler:

<HEAD><STYLE type="text/css"> #x97z { color: red }</STYLE></HEAD><BODY><P ID=x97z style="color: green"></BODY>

i ovenstående eksempel ville farven på p-elementet være grøn. Erklæringen i attributten” style ” tilsidesætter den i STILELEMENTET på grund af cascading regel 3, da den har en højere specificitet. Hvis du mener, at dette eksempel er svært at forstå, skal du kontrollere denne artikel om CSS-rækkefølge.

Final notes

det er svært at opnå perfekte resultater på grund af forskellige gengivelser. Nogle gamle bro.sere understøtter ikke fuld CSS3 eller HTML5, så tjek html5please community project for at se, om den syntaks, du prøver at bruge, understøttes af flertallet af bro. sere. Du kan dog eventuelt bruge fallbacks eller polyfills til at levere manglende funktioner til bro.sere, der ikke understøtter fuld CSS3-eller HTML5-implementering.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.