Share
Förra helgen ladde jag ner Dave Gamaches Skeleton boilerplate för att leka med; bra, ren, lyhörd rolig. När det gällde formulärdesignen påminde jag om ett problem som kan påverka inmatningar i flexibla layouter: felaktiga bredder. Om du någonsin haft samma problem, eller har aldrig varit medveten om det, läs vidare ...
Låt oss säga att vi har en layout med ett innehållande element, som har en flexibel bredd (sträcka webbläsaren, och du sträcker behållaren). Inom vår behållare har vi en mängd olika element (rubriker, stycken, horisontella regler, div) och vi har också en enkel form som spelar värd för några typiska formbitar och bobs.
Innehållet allt växer och krympas beroende på behållarens bredd. Blocknivåelement (t.ex. divs) matchar bredden exakt. De fyller automatiskt 100% av behållarens bredd och oberoende av vadderingar eller gränser som de stannar snyggt inom sina föräldrars gränser.
Forminmatningar gör det inte.
För att de ska fylla behållarens bredd måste vi ansöka a bredd: 100%;. Efter att ha gjort det kommer dock att lägga på vadderingar, gränser eller marginaler att våra ingångar brister från behållarens begränsningar. Besvikelse.
Tja, inte riktigt. CSS-boxmodellen dikterar hur elementets dimensioner beter sig, och sedan webbstandarder infördes har vi kommit att acceptera att polstring, marginal och gränser Lägg till till ett elements dimensioner.
Så tveklöst är vår div i det här fallet den som uppträder oväntat, men det är bara för att vi inte har definierat dess bredd.
Det verkar vara att hantera saker som Internet Explorer traditionellt brukade. Med quirks mode-tillvägagångssättet menade du att du definierade ett elements bredd och höjd, och eventuella vadderingar eller gränser skulle beaktas inom dessa dimensioner. Om du angav en div som är 600px bred, även om du lagt till 10px på vaddering, skulle den fortfarande vara 600px bred. Du skulle kategoriskt veta hur stora dina element var.
Så länge vi var medvetna om hur våra element uppförde sig kunde vi tillåta skillnaderna och ange fasta dimensioner i enlighet därmed. Men i denna ålder av vätskeformat vet vi inte nödvändigtvis hur brett innehållsämnen är. Det finns säkert ett sätt att få våra insatser och textareas att uppträda på samma sätt som allt annat? Lyckligtvis finns det. Och vi ska bygga en snabb demo för att illustrera den.
Som det var skelettpannan som påminde mig om det här problemet kommer vi att ta och ta tag i det för att snabbt bygga oss en demo.
Notera: Varje styling inom skelettpannan är i form av layout och grundläggande estetik - min tillägg till dess css är inte en kritik!
Packa upp filerna och du kommer se något så här:
Den första ändringen jag gör är att index.html. I den sista kolumnen byter vi ut innehållet för ett formulär:
och sedan lägger vi till ett par rader till stylesheets / layout.css:
.kolumn bakgrund: # f7f7f7; inmatas [typ = 'text'], välj textarea bredd: 100%;
Allt vi har gjort ges kolumnerna en grå bakgrund (så vi kan se var gränserna ligger) och gjort våra formelement 100% breda. Kolla in resultatet hittills. Problemet med felaktiga ingångar illustreras tydligt, så nu till lösningen ...
Vi kan göra våra formelement förekommer enligt den gamla quirks mode boxmodellen med en rad css ...
input [typ = 'text'], textarea box-size: border-box; -moz-box-size: border-box; -webkit-box-dimensionering: border-box;
Okej, sex rader, men det viktiga är box-dimensionering: gränsvärde;, tillsammans med sina leverantörer prefixed bröder. Vi har tillämpat den här regeln på våra textinmatningar och textområden och berättar att webbläsaren ska göra sina dimensioner med vaddering och gränser inuti. Ta en titt på den resulterande demoen, perfecto! Ändra storlek på webbläsaren och du ser att formulärelementen spelar bra precis som deras blocknivåvänner.
När det gäller webbläsarsupport är du väl täckt också. Ironiskt nog känner inte IE7 igen till egenskapen boxningsstorlek, men det är den enda webbläsaren du har problem med.
Accentsconagua