Problem med utökning av hemsida på höjden.

Men det fixar ingenting egentligen. Man vill ju ha marginaler på sina element och då kommer gliporna komma tillbaka igen. Collapsing margins går att lösa på bättre sätt, exempelvis med overflow:hidden eller padding som inte är 0.

Det som är inkonsekvent webbläsarvarianter emellan är mestadels CSS-buggar och hacks (äldre varianter av IE). Det kan även förekomma plattformsrelaterade avvikelser där ett typsnitt inte återfinns och ersätts med närmast lämpliga.

CSS-resets löser inget av dessa problem.

I dag är nästan samtliga webbläsare helt överens om vad HTML 4.01 och CSS2.1 handlar om, bortsett från IE 7 som haltande dröjer sig kvar på vissa XP-burkar.
CSS-resets hjälper inte här heller.

Jag är mer tekniskt än grafiskt lagd. När jag utvecklar en webbsida brukar jag börja med ett väldigt luddigt koncept och sedan känner jag mig fram. Standardreglerna för elements marginaler är här en stor fördel då de webbläsare som jag känner till tycker att stycken och rubriker ska vara luftiga, listor skjutas in från vänsterkanten och så vidare, som standard. Att nollställa dessa marginaler hjälper mig inte, snarare får jag viss panik när stycken faller samman med varandra till solida block av text. Om jag sätter p, ul { margin:1em 0; } så vet jag att dessa två element nu har en topp– och bottenmarginal på 1 em. Att sätta dem till 0 innan jag ens har använt dem på sidan hjälper mig inte heller — jag upplever inte heller att en reset underlättar mitt arbete om jag vid senare tillfälle lägger in ett av mig ostylat ol-block som är marginalbefriat; det får bara listan att se ful ut.

Marginaler är en webbdesigners goda vänner om han vet hur de fungerar. Rätt applicerade ger de en sida naturligt flöde, med stycken som avgränsas av jämnt och behagligt vitutrymme.

Tanken med att sätta 0 på alla marginaler (och ev. även padding) är ju inte att man ska fortsätta ha den på 0 för alla element, utan för att man ska ha kontroll på marginalerna genom att själv få sätta dem. Lite mer jobb, mycket mindre klientberoende. Jag menar hur ofta vill man sitta och spendera timme efter timme med någonting som sedan kan se helt fel ut bara för att någon annan bestämt sig för att det skall vara extra marginaler på olika ställen.

Bättre då att sätta allt till 0 så vet man vart man börjar och sedan lägga till det man vill ha istället för att förlita sig på att utvecklarna av webläsaren tycker likadant som en själv alla gånger.

Jo men sen kommer man till alla defekta renderingar av sidor som ibland dyker upp. Som t.ex. när en 2px margin på en lista blir default-margin plus 2px extra istället för exakt 2px (host host, IE). Då hjälper det rätt mycket om man redan innan tvingat den till att ha 0 som default. Nu för tiden är ju inte liknande saker något större problem eftersom de flesta fattat att "egna" varianter inte uppskattas. Men det är inte obefintligt.

Kort sagt: Heller ha det och det inte behövs än tvärt om.

Och visst finns det anledningar till att ha noll marginal på hX-element. Det beror helt på hur man bygger upp designen på sidan. De ska inte sitta ihop med texten, men det kan finnas tillfällen då top/botten-marginal på texten istället fungerar bättre.

Det hjälper inte ett skit. Att skriva:

* { margin:0; padding:0; }
ul { margin:1em 0; }

är alltid, oavsett plattform, webbläsare och ramverk, exakt samma sak som att skriva

ul { margin: 1em 0; padding:0; }

när det kommer till ul-element.
En margin-/padding-reset nollställer marginaler och paddings (duh..) vilka sedan sätts tillbaks till vad man vill ha. Det är ingen som helst skillnad mot att bara sätta vad man vill ha, direkt, från början.

* { margin:0; padding:0; }
ul { margin:1em 0; }

ul { margin: 1em 0; padding:0; }

Ja skriver man en reset i samma css så är det ju totalt meningslöst.
En reset är ju till för att ta bort dumheter som inte borde vara där. Det innefattar saker som kan ligga i cachen, dumheter från webläsaren och annat. Som jag sa, webbläsare som hittar på saker är inte så vanligt längre. Det har rätt mycket dött ut i takt med att IE5/6 har fasats ut. Men poängen är att även om vi talar om en nästan obefintlig risk, så är det 2 rader kod vi talar om. De kanske 2kb data det handlar om är idag ett mycket mindre problem ändå.

Så visst, i 99.9% av fallen finns det ingen anledning till det. Men inte heller gör det någon skada att göra det.

Jag vet inte vad du pratar om för cache för en CSS-reset är Vanlig Jävla CSS™ och laddas ner som all annan Vanlig Jävla CSS. Dessutom, har man stilregler för de element som visas på sidan så är de definierade efter reseten och har då preferens. Den nytta som reseten potentiellt sett skulle kunna ha mot någon mystisk cache går förlorad eftersom man ändå skriver över resetens nollställning med egna värden med andra ord. Slutligen, en reset hjälper inte äldre webbläsare: med risk för att repetera sönder min poäng så görs resetens jobb ogjort i samma stund som man definierar egna stilregler för element som används. Internet Explorer 6 har inte lättare att applicera en marginal på 1 em på godtyckligt element, bara för att man stunden innan satt elementets marginaler till 0. Snarare är äldre webbläsare långsammare och de negativa effekterna av en reset har större impakt.

Visst är prestandaförlusten av den extra HTTP-requesten betydelselös ur ett bredare perspektiv men reseten är totalt onödig så varför ha med den alls. Jag vet inte varför de har blivit så populära, folk tror uppenbarligen att de löser ett problem när problemet i själva verket inte existerar.

Notera: Jag motsätter mig inte en "kontextuell reset", i form av CSS som anger generiska grundinställningar för färger, typsnitt, storlekar, marginaler och dylikt över en hel webbplats. Det är praktiskt, minskar repetition och gör det möjligt att göra stora förändringar genom att modifiera en fil. Vad jag motsätter mig är just lista, av, element, eller, * { nollställ }-reseten, vilket är den som folk vanligtvis menar när de diskuterar resets.