Nærme sig
Lær om de vejledende principper, strategier og teknikker, der bruges til at bygge og vedligeholde Bootstrap, så du nemmere kan tilpasse og udvide det selv.
Mens startsiderne giver en introduktion til projektet og hvad det tilbyder, fokuserer dette dokument på, hvorfor vi gør de ting, vi gør i Bootstrap. Det forklarer vores filosofi om at bygge på nettet, så andre kan lære af os, bidrage med os og hjælpe os med at blive bedre.
Ser du noget, der ikke lyder rigtigt, eller måske kunne gøres bedre? Åbn et problem - vi vil meget gerne diskutere det med dig.
Vi vil dykke mere ned i hver af disse hele vejen igennem, men på et højt niveau er det her, der styrer vores tilgang.
- Komponenter skal være responsive og mobil-først
- Komponenter bør bygges med en basisklasse og udvides via modifikatorklasser
- Komponenttilstande bør følge en fælles z-indeksskala
- Når det er muligt, foretrækker du en HTML- og CSS-implementering frem for JavaScript
- Når det er muligt, skal du bruge hjælpeprogrammer over brugerdefinerede stilarter
- Når det er muligt, undgå at håndhæve strenge HTML-krav (børnevælgere)
Bootstraps responsive stilarter er bygget til at være responsive, en tilgang, der ofte omtales som mobile-first . Vi bruger dette udtryk i vores dokumenter og er stort set enige i det, men til tider kan det være for bredt. Selvom ikke alle komponenter skal være helt responsive i Bootstrap, handler denne responsive tilgang om at reducere CSS-tilsidesættelser ved at skubbe dig til at tilføje stilarter, efterhånden som viewporten bliver større.
På tværs af Bootstrap vil du se dette tydeligst i vores medieforespørgsler. I de fleste tilfælde bruger vi min-widthforespørgsler, der begynder at gælde ved et bestemt brudpunkt og fortsætter gennem de højere brudpunkter. For eksempel .d-nonegælder a fra min-width: 0til uendelig. Til gengæld .d-md-nonegælder a fra mellembrudspunktet og op.
Til tider vil vi bruge max-width, når en komponents iboende kompleksitet kræver det. Til tider er disse tilsidesættelser funktionelt og mentalt klarere at implementere og understøtte end at omskrive kernefunktionalitet fra vores komponenter. Vi bestræber os på at begrænse denne tilgang, men vil bruge den fra tid til anden.
Bortset fra vores genstart, et normaliseringsstilark på tværs af browsere, sigter alle vores stilarter mod at bruge klasser som vælgere. Det betyder, at man undgår typevælgere (f.eks. input[type="text"]) og fremmede forældreklasser (f.eks. .parent .child), der gør stilarter for specifikke til let at tilsidesætte.
Som sådan bør komponenter bygges med en basisklasse, der huser fælles, ikke-til-tilsidesættende ejendomsværdi-par. For eksempel .btnog .btn-primary. Vi bruger .btntil alle de gængse stilarter som display, padding, og border-width. Vi bruger derefter modifikatorer som .btn-primaryat tilføje farve, baggrundsfarve, kantfarve osv.
Modifikatorklasser bør kun bruges, når der er flere egenskaber eller værdier, der skal ændres på tværs af flere varianter. Modifikatorer er ikke altid nødvendige, så vær sikker på, at du faktisk gemmer kodelinjer og forhindrer unødvendige tilsidesættelser, når du opretter dem. Gode eksempler på modifikatorer er vores temafarveklasser og størrelsesvarianter.
Der er to z-indexskalaer i Bootstrap – elementer i en komponent og overlejringskomponenter.
- Nogle komponenter i Bootstrap er bygget med overlappende elementer for at forhindre dobbelte grænser uden at ændre
borderegenskaben. For eksempel knapgrupper, inputgrupper og paginering. - Disse komponenter deler en standardskala
z-indexpå0gennem3. 0er standard (initial),1er:hover,2er:active/.active, og ,3er:focus.- Denne tilgang matcher vores forventninger om højeste brugerprioritet. Hvis et element er fokuseret, er det i øjesyn og til brugerens opmærksomhed. Aktive elementer er næsthøjest, fordi de angiver tilstand. Hover er tredjehøjest, fordi det indikerer brugerens hensigt, men næsten alt kan svæve.
Bootstrap indeholder flere komponenter, der fungerer som et overlay af en slags. Dette inkluderer, i rækkefølge efter højeste z-index, dropdowns, faste og klæbrige navbarer, modaler, værktøjstip og popovers. Disse komponenter har deres egen z-indexskala, der begynder ved 1000. Dette startnummer er tilfældigt og fungerer som en lille buffer mellem vores stilarter og dit projekts brugerdefinerede stilarter.
Hver overlejringskomponent øger dens z-indexværdi en smule på en sådan måde, at almindelige brugergrænsefladeprincipper tillader brugerfokuserede eller svævende elementer at forblive synlige hele tiden. For eksempel er en modal dokumentblokering (f.eks. kan du ikke foretage nogen anden handling undtagen for modalens handling), så vi sætter det over vores navbarer.
Lær mere om dette på vores z-indexlayoutside .
Når det er muligt, foretrækker vi at skrive HTML og CSS over JavaScript. Generelt er HTML og CSS mere produktive og tilgængelige for flere mennesker på alle forskellige erfaringsniveauer. HTML og CSS er også hurtigere i din browser end JavaScript, og din browser generelt leverer en hel del funktionalitet til dig.
Dette princip er vores førsteklasses JavaScript API er dataattributter. Du behøver ikke at skrive næsten noget JavaScript for at bruge vores JavaScript-plugins; skriv i stedet HTML. Læs mere om dette på vores JavaScript-oversigtsside .
Til sidst bygger vores stilarter på den grundlæggende adfærd fra almindelige webelementer. Når det er muligt, foretrækker vi at bruge det, som browseren tilbyder. For eksempel kan du sætte en .btnklasse på næsten ethvert element, men de fleste elementer giver ikke nogen semantisk værdi eller browserfunktionalitet. Så i stedet bruger vi <button>s og <a>s.
Det samme gælder for mere komplekse komponenter. Selvom vi kunne skrive vores eget formularvalideringsplugin for at tilføje klasser til et overordnet element baseret på en inputs tilstand, og derved give os mulighed for at style teksten med at sige rød, foretrækker vi at bruge :valid/ :invalidpseudo-elementerne, som hver browser giver os.
Hjælpeklasser - tidligere hjælpere i Bootstrap 3 - er en stærk allieret i bekæmpelsen af CSS-bloat og dårlig sideydelse. En nytteklasse er typisk en enkelt, uforanderlig egenskab-værdi-parring udtrykt som en klasse (f.eks. .d-blockrepræsenterer display: block;). Deres primære appel er brugshastigheden, mens du skriver HTML og begrænser mængden af tilpasset CSS, du skal skrive.
Specifikt med hensyn til tilpasset CSS kan hjælpeprogrammer hjælpe med at bekæmpe stigende filstørrelse ved at reducere dine oftest gentagne egenskabsværdipar til enkelte klasser. Dette kan have en dramatisk effekt i skalaen i dine projekter.
Selvom det ikke altid er muligt, stræber vi efter at undgå at være alt for dogmatiske i vores HTML-krav til komponenter. Derfor fokuserer vi på enkeltklasser i vores CSS-vælgere og forsøger at undgå umiddelbare børnevælgere ( ~). Dette giver dig mere fleksibilitet i din implementering og hjælper med at holde vores CSS enklere og mindre specifik.