Närma sig

Medan startsidorna ger en introduktion till projektet och vad det erbjuder, fokuserar det här dokumentet på varför vi gör de saker vi gör i Bootstrap. Det förklarar vår filosofi att bygga på webben så att andra kan lära av oss, bidra med oss ​​och hjälpa oss att förbättras.

Ser du något som inte låter rätt, eller som kanske kan göras bättre? Öppna ett problem — vi diskuterar det gärna med dig.

Sammanfattning

Vi kommer att dyka in i var och en av dessa mer genomgående, men på en hög nivå är det här vad som styr vårt tillvägagångssätt.

• Komponenter bör vara lyhörda och mobila först
• Komponenter bör byggas med en basklass och utökas med modifieringsklasser
• Komponenttillstånd bör följa en gemensam z-indexskala
• När det är möjligt, föredra en HTML- och CSS-implementering framför JavaScript
• När det är möjligt, använd verktyg framför anpassade stilar
• När det är möjligt, undvik att tillämpa strikta HTML-krav (barnväljare)

Mottaglig

Bootstraps lyhörda stilar är byggda för att vara lyhörda, ett tillvägagångssätt som ofta kallas mobilt först . Vi använder denna term i våra dokument och håller i stort sett med om den, men ibland kan den vara för bred. Även om inte varje komponent måste vara helt lyhörd i Bootstrap, handlar detta lyhörda tillvägagångssätt om att minska CSS-åsidosättningar genom att pressa dig att lägga till stilar när visningsporten blir större.

Över Bootstrap ser du detta tydligast i våra mediefrågor. I de flesta fall använder vi min-widthfrågor som börjar gälla vid en specifik brytpunkt och går upp genom de högre brytpunkterna. Till exempel .d-nonegäller a från min-width: 0till oändlighet. Å andra sidan .d-md-nonegäller a från medel brytpunkt och uppåt.

Ibland använder vi max-widthnär en komponents inneboende komplexitet kräver det. Ibland är dessa åsidosättningar funktionellt och mentalt tydligare att implementera och stödja än att skriva om kärnfunktionalitet från våra komponenter. Vi strävar efter att begränsa detta tillvägagångssätt, men kommer att använda det då och då.

Klasser

Bortsett från vår Reboot, en normaliseringsstilmall för flera webbläsare, syftar alla våra stilar till att använda klasser som väljare. Detta innebär att man undviker typväljare (t.ex. input[type="text"]) och främmande föräldraklasser (t.ex. .parent .child) som gör stilar för specifika för att enkelt åsidosättas.

Som sådan bör komponenter byggas med en basklass som innehåller vanliga, inte att åsidosätta fastighetsvärdepar. Till exempel .btnoch .btn-primary. Vi använder .btnför alla vanliga stilar som display, padding, och border-width. Vi använder sedan modifierare som .btn-primaryatt lägga till färg, bakgrundsfärg, kantfärg, etc.

Modifieringsklasser bör endast användas när det finns flera egenskaper eller värden som ska ändras över flera varianter. Modifierare är inte alltid nödvändiga, så se till att du faktiskt sparar kodrader och förhindrar onödiga åsidosättanden när du skapar dem. Bra exempel på modifierare är våra temafärgklasser och storleksvarianter.

z-index skalor

Det finns två z-indexskalor i Bootstrap – element i en komponent och överläggskomponenter.

Komponenter

• Vissa komponenter i Bootstrap är byggda med överlappande element för att förhindra dubbla gränser utan att ändra borderegenskapen. Till exempel knappgrupper, inmatningsgrupper och sidnumrering.
• Dessa komponenter delar en standardskala z-indexpå 0genom 3.
• 0är standard (initial), 1är :hover, 2är :active/ .activeoch 3är :focus.
• Detta tillvägagångssätt matchar våra förväntningar på högsta användarprioritet. Om ett element är fokuserat är det synligt och till användarens uppmärksamhet. Aktiva element är näst högst eftersom de indikerar tillstånd. Hover är tredje högst eftersom det indikerar användarens avsikt, men nästan allt kan svävas.

Överläggskomponenter

Bootstrap innehåller flera komponenter som fungerar som en överlagring av något slag. Detta inkluderar, i högsta ordning z-index, rullgardinsmenyer, fasta och klibbiga navigeringsfält, modaler, verktygstips och popovers. Dessa komponenter har sin egen z-indexskala som börjar på 1000. Detta startnummer valdes godtyckligt och fungerar som en liten buffert mellan våra stilar och ditt projekts anpassade stilar.

Varje överlagringskomponent ökar sitt z-indexvärde något på ett sådant sätt att gemensamma gränssnittsprinciper tillåter användarfokuserade eller svävande element att alltid vara synliga. Till exempel är en modal dokumentblockering (t.ex. du kan inte vidta någon annan åtgärd utom för modalens åtgärd), så vi sätter det ovanför våra navigeringsfält.

Läs mer om detta på vår z-indexlayoutsida .

HTML och CSS över JS

När det är möjligt föredrar vi att skriva HTML och CSS över JavaScript. I allmänhet är HTML och CSS mer produktiva och tillgängliga för fler människor på alla olika erfarenhetsnivåer. HTML och CSS är också snabbare i din webbläsare än JavaScript, och din webbläsare erbjuder i allmänhet en hel del funktionalitet för dig.

Denna princip är vårt förstklassiga JavaScript API som använder dataattribut. Du behöver inte skriva nästan något JavaScript för att använda våra JavaScript-plugin; skriv istället HTML. Läs mer om detta på vår JavaScript-översiktssida .

Slutligen bygger våra stilar på de grundläggande beteendena hos vanliga webbelement. När det är möjligt föredrar vi att använda vad webbläsaren tillhandahåller. Till exempel kan du sätta en .btnklass på nästan vilket element som helst, men de flesta element ger inte något semantiskt värde eller webbläsarfunktionalitet. Så istället använder vi <button>s och <a>s.

Detsamma gäller för mer komplexa komponenter. Även om vi skulle kunna skriva vårt eget formulärvalideringsplugin för att lägga till klasser till ett överordnat element baserat på en indatas tillstånd, och därigenom tillåta oss att stila texten med att säga röd, föredrar vi att använda :valid/ :invalidpseudo-elementen som varje webbläsare tillhandahåller oss.

Verktyg

Verktygsklasser – tidigare medhjälpare i Bootstrap 3 – är en kraftfull allierad för att bekämpa CSS-bloat och dålig sidprestanda. En nyttoklass är vanligtvis en enkel, oföränderlig egenskap-värde-parning uttryckt som en klass (t.ex. .d-blockrepresenterar display: block;). Deras primära överklagande är användningshastigheten när du skriver HTML och begränsar mängden anpassad CSS du måste skriva.

Specifikt när det gäller anpassad CSS kan verktyg hjälpa till att bekämpa ökande filstorlek genom att reducera dina vanligast upprepade egenskapsvärdepar till enskilda klasser. Detta kan ha en dramatisk effekt i skala i dina projekt.

Flexibel HTML

Även om det inte alltid är möjligt strävar vi efter att undvika att vara alltför dogmatiska i våra HTML-krav för komponenter. Därför fokuserar vi på enstaka klasser i våra CSS-väljare och försöker undvika omedelbara barnväljare ( >). Detta ger dig mer flexibilitet i din implementering och hjälper till att hålla vår CSS enklare och mindre specifik.

Kodkonventioner

Code Guide (från Bootstrap co-creator, @mdo) dokumenterar hur vi skriver vår HTML och CSS över Bootstrap. Den specificerar riktlinjer för allmän formatering, standardinställningar för sunt förnuft, egenskaps- och attributordningar och mer.

Vi använder Stylelint för att upprätthålla dessa standarder och mer i vår Sass/CSS. Vår anpassade Stylelint-konfiguration är öppen källkod och tillgänglig för andra att använda och utöka.

Vi använder vnu-jar för att upprätthålla standard och semantisk HTML, samt att upptäcka vanliga fel.