Nærme sig

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.

Resumé

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)

Lydhør

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 fuldstændigt 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.

Klasser

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.

z-indeks skalaer

Der er to z-indexskalaer i Bootstrap – elementer i en komponent og overlejringskomponenter.

Komponentelementer

• 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å 0gennem 3.
• 0er standard (initial), 1er :hover, 2er :active/ .activeog 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 angiver brugerens hensigt, men næsten alt kan svæve.

Overlay komponenter

Bootstrap indeholder flere komponenter, der fungerer som et overlay af en eller anden art. 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 blev valgt vilkårligt og fungerer som en lille buffer mellem vores stilarter og dit projekts brugerdefinerede stilarter.

Hver overlejringskomponent øger sin z-indexværdi en smule på en sådan måde, at almindelige UI-principper tillader brugerfokuserede eller svævende elementer at forblive synlige til enhver tid. For eksempel er en modal dokumentblokering (f.eks. kan du ikke foretage andre handlinger undtagen for modalens handling), så vi sætter det over vores navbarer.

Lær mere om dette på vores z-indexlayoutside .

HTML og CSS over JS

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 leverer generelt en hel del funktionalitet til dig.

Dette princip er vores førsteklasses JavaScript API, der bruger 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 tillade os at style teksten med at sige rød, foretrækker vi at bruge :valid/ :invalidpseudo-elementerne, som hver browser giver os.

Hjælpeprogrammer

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 brugerdefineret 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.

Fleksibel HTML

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.

Kodekonventioner

Code Guide (fra Bootstrap co-creator, @mdo) dokumenterer, hvordan vi skriver vores HTML og CSS på tværs af Bootstrap. Det specificerer retningslinjer for generel formatering, almindelige standarder for sund fornuft, ejendoms- og attributordrer og mere.

Vi bruger Stylelint til at håndhæve disse standarder og mere i vores Sass/CSS. Vores tilpassede Stylelint-konfiguration er open source og tilgængelig for andre at bruge og udvide.

Vi bruger vnu-jar til at håndhæve standard og semantisk HTML, samt til at opdage almindelige fejl.