Nærme seg
Lær om de veiledende prinsippene, strategiene og teknikkene som brukes til å bygge og vedlikeholde Bootstrap, slik at du lettere kan tilpasse og utvide den selv.
Mens startsidene gir en innføring i prosjektet og hva det tilbyr, fokuserer dette dokumentet på hvorfor vi gjør det vi gjør i Bootstrap. Den forklarer vår filosofi om å bygge på nettet slik at andre kan lære av oss, bidra med oss og hjelpe oss med å forbedre oss.
Ser du noe som ikke høres riktig ut, eller som kanskje kan gjøres bedre? Åpne et problem – vi vil gjerne diskutere det med deg.
Vi vil dykke inn i hver av disse mer gjennom, men på et høyt nivå, her er det som styrer vår tilnærming.
- Komponenter bør være responsive og mobil først
- Komponenter bør bygges med en basisklasse og utvides via modifikasjonsklasser
- Komponenttilstander bør følge en vanlig z-indeksskala
- Når det er mulig, foretrekk en HTML- og CSS-implementering fremfor JavaScript
- Når det er mulig, bruk verktøy over egendefinerte stiler
- Når det er mulig, unngå å håndheve strenge HTML-krav (barnevelgere)
Bootstraps responsive stiler er bygd for å være responsive, en tilnærming som ofte omtales som mobil-først . Vi bruker dette begrepet i dokumentene våre og er stort sett enige i det, men til tider kan det være for vidt. Selv om ikke alle komponenter må være helt responsive i Bootstrap, handler denne responsive tilnærmingen om å redusere CSS-overstyringer ved å presse deg til å legge til stiler etter hvert som visningsporten blir større.
På tvers av Bootstrap vil du se dette tydeligst i medieforespørslene våre. I de fleste tilfeller bruker vi min-widthspørringer som begynner å gjelde ved et spesifikt bruddpunkt og fører opp gjennom de høyere bruddpunktene. For eksempel .d-nonegjelder a fra min-width: 0til uendelig. Derimot .d-md-nonegjelder a fra middels bruddpunkt og oppover.
Noen ganger vil vi bruke max-widthnår en komponents iboende kompleksitet krever det. Noen ganger er disse overstyringene funksjonelt og mentalt klarere å implementere og støtte enn å omskrive kjernefunksjonalitet fra komponentene våre. Vi streber etter å begrense denne tilnærmingen, men vil bruke den fra tid til annen.
Bortsett fra vår Reboot, et normaliseringsstilark på tvers av nettlesere, har alle stilene våre som mål å bruke klasser som velgere. Dette betyr å unngå typevelgere (f.eks. input[type="text"]) og fremmede foreldreklasser (f.eks. .parent .child) som gjør stiler for spesifikke til å enkelt overstyres.
Som sådan bør komponenter bygges med en basisklasse som inneholder vanlige, ikke-å-overstyre eiendomsverdi-par. For eksempel .btnog .btn-primary. Vi bruker .btnfor alle vanlige stiler som display, padding, og border-width. Vi bruker deretter modifikatorer som .btn-primaryå legge til farge, bakgrunnsfarge, kantfarge osv.
Modifikatorklasser skal bare brukes når det er flere egenskaper eller verdier som skal endres på tvers av flere varianter. Modifikatorer er ikke alltid nødvendige, så pass på at du faktisk lagrer kodelinjer og forhindrer unødvendige overstyringer når du oppretter dem. Gode eksempler på modifikatorer er våre temafargeklasser og størrelsesvarianter.
Det er to z-indexskalaer i Bootstrap – elementer i en komponent og overleggskomponenter.
- Noen komponenter i Bootstrap er bygget med overlappende elementer for å forhindre doble grenser uten å endre
borderegenskapen. For eksempel knappegrupper, inndatagrupper og paginering. - Disse komponentene deler en standardskala
z-indexpå0gjennom3. 0er standard (initial),1er:hover,2er:active/.active, og ,3er:focus.- Denne tilnærmingen samsvarer med våre forventninger om høyeste brukerprioritet. Hvis et element er fokusert, er det i sikte og til brukerens oppmerksomhet. Aktive elementer er nest høyest fordi de indikerer tilstand. Hover er tredje høyest fordi det indikerer brukerens hensikt, men nesten alt kan holdes.
Bootstrap inkluderer flere komponenter som fungerer som et overlegg av noe slag. Dette inkluderer, i rekkefølge etter høyeste z-index, rullegardinmenyene, faste og klebrige navbarer, modaler, verktøytips og popovers. Disse komponentene har sin egen z-indexskala som begynner på 1000. Dette startnummeret er tilfeldig og fungerer som en liten buffer mellom stilene våre og prosjektets egendefinerte stiler.
Hver overleggskomponent øker z-indexverdien litt på en slik måte at vanlige brukergrensesnittprinsipper lar brukerfokuserte eller svevende elementer være synlige til enhver tid. For eksempel er en modal dokumentblokkering (f.eks. kan du ikke foreta noen annen handling bortsett fra modalens handling), så vi setter det over navbarene våre.
Lær mer om dette på vår z-indexlayoutside .
Når det er mulig, foretrekker vi å skrive HTML og CSS over JavaScript. Generelt er HTML og CSS mer produktive og tilgjengelige for flere mennesker på alle forskjellige erfaringsnivåer. HTML og CSS er også raskere i nettleseren din enn JavaScript, og nettleseren generelt gir deg mye funksjonalitet.
Dette prinsippet er vår førsteklasses JavaScript API er dataattributter. Du trenger ikke skrive nesten noe JavaScript for å bruke våre JavaScript-plugins; skriv i stedet HTML. Les mer om dette på vår JavaScript-oversiktsside .
Til slutt bygger stilene våre på den grunnleggende oppførselen til vanlige nettelementer. Når det er mulig, foretrekker vi å bruke det nettleseren tilbyr. Du kan for eksempel sette en .btnklasse på nesten hvilket som helst element, men de fleste elementene gir ingen semantisk verdi eller nettleserfunksjonalitet. Så i stedet bruker vi <button>s og <a>s.
Det samme gjelder for mer komplekse komponenter. Selv om vi kunne skrive vår egen skjemavalideringsplugin for å legge til klasser til et overordnet element basert på en inngangs tilstand, og dermed tillate oss å style teksten som sier rød, foretrekker vi å bruke :valid/ :invalidpseudo-elementene hver nettleser gir oss.
Verktøyklasser – tidligere hjelpere i Bootstrap 3 – er en mektig alliert i å bekjempe CSS-oppblåsthet og dårlig sideytelse. En nytteklasse er vanligvis en enkelt, uforanderlig egenskap-verdi-paring uttrykt som en klasse (f.eks. .d-blockrepresenterer display: block;). Deres primære appell er hastigheten på bruken mens du skriver HTML og begrense mengden tilpasset CSS du må skrive.
Spesielt når det gjelder tilpasset CSS, kan verktøy bidra til å bekjempe økende filstørrelse ved å redusere de mest gjentatte egenskapsverdi-parene dine til enkeltklasser. Dette kan ha en dramatisk effekt i stor skala i prosjektene dine.
Selv om det ikke alltid er mulig, prøver vi å unngå å være for dogmatiske i HTML-kravene våre for komponenter. Derfor fokuserer vi på enkeltklasser i våre CSS-velgere og prøver å unngå umiddelbare barnevelgere ( ~). Dette gir deg mer fleksibilitet i implementeringen og bidrar til å holde vår CSS enklere og mindre spesifikk.