Alproksimiĝo
Lernu pri la gvidprincipoj, strategioj kaj teknikoj uzataj por konstrui kaj konservi Bootstrap, por ke vi povu pli facile personecigi kaj etendi ĝin mem.
Dum la komencaj paĝoj disponigas enkondukan turneon de la projekto kaj kion ĝi ofertas, ĉi tiu dokumento fokusiĝas pri kial ni faras tion, kiujn ni faras en Bootstrap. Ĝi klarigas nian filozofion konstrui en la reto por ke aliaj povu lerni de ni, kontribui kun ni kaj helpi nin plibonigi.
Vidu ion, kio ne sonas ĝuste, aŭ eble fareblas pli bone? Malfermu aferon — ni ŝatus diskuti ĝin kun vi.
Ni plonĝos en ĉiun el ĉi tiuj pli, sed je alta nivelo, jen kio gvidas nian aliron.
- Komponantoj devas esti respondemaj kaj unue moveblaj
- Komponantoj devus esti konstruitaj kun baza klaso kaj etenditaj per modifiklasoj
- Komponantaj ŝtatoj devus obei oftan z-indeksan skalon
- Kiam ajn eblas, preferu HTML- kaj CSS-efektivigon ol JavaScript
- Kiam ajn eblas, uzu ilojn super kutimaj stiloj
- Kiam ajn eblas, evitu devigi striktajn HTML-postulojn (infanaj elektiloj)
La respondemaj stiloj de Bootstrap estas konstruitaj por esti respondemaj, aliro, kiun oni ofte nomas mobile-unue . Ni uzas ĉi tiun terminon en niaj dokumentoj kaj plejparte konsentas kun ĝi, sed foje ĝi povas esti tro larĝa. Kvankam ne ĉiu komponanto devas esti tute respondema en Bootstrap, ĉi tiu respondema aliro temas pri redukti CSS-anstataŭigojn puŝante vin aldoni stilojn dum la vidpunkto pligrandiĝas.
Tra Bootstrap, vi vidos ĉi tion plej klare en niaj amaskomunikilaj demandoj. Plejofte, ni uzas min-widthdemandojn, kiuj komencas apliki ĉe specifa rompopunkto kaj portas supren tra la pli altaj rompopunktoj. Ekzemple, a .d-noneaplikas de min-width: 0ĝis malfinio. Aliflanke, a .d-md-noneaplikas de la meza rompopunkto kaj supren.
Foje ni uzos max-widthkiam la eneca komplekseco de komponento postulas ĝin. Foje, ĉi tiuj anstataŭoj estas funkcie kaj mense pli klaraj por efektivigi kaj subteni ol reverki kernajn funkciojn de niaj komponantoj. Ni strebas limigi ĉi tiun aliron, sed uzos ĝin de tempo al tempo.
Krom nia Reboot, trans-retumila normaliga stilfolio, ĉiuj niaj stiloj celas uzi klasojn kiel elektilojn. Ĉi tio signifas foriri de tipelektiloj (ekz., input[type="text"]) kaj eksterlandaj gepatraj klasoj (ekz., .parent .child) kiuj faras stilojn tro specifaj por facile superregi.
Kiel tia, komponentoj devus esti konstruitaj kun bazklaso kiu enhavas oftajn, ne-estantajn superregatajn posedaĵ-valorajn parojn. Ekzemple, .btnkaj .btn-primary. Ni uzas .btnpor ĉiuj komunaj stiloj kiel display, padding, kaj border-width. Ni tiam uzas modifilojn kiel .btn-primaryaldoni la koloron, fonkoloron, randkoloron ktp.
Modifiklasoj devas esti uzataj nur kiam ekzistas pluraj trajtoj aŭ valoroj ŝanĝendaj tra pluraj variantoj. Modifiloj ne ĉiam estas necesaj, do certiĝu, ke vi efektive konservas liniojn de kodo kaj malhelpas nenecesajn anstataŭojn dum kreado de ili. Bonaj ekzemploj de modifiloj estas niaj temaj kolorklasoj kaj grandvariaĵoj.
Estas du z-indexskvamoj en Bootstrap—elementoj ene de komponanto kaj tegmentaj komponantoj.
- Iuj komponantoj en Bootstrap estas konstruitaj kun imbrikitaj elementoj por malhelpi duoblajn randojn sen modifi la
borderposedaĵon. Ekzemple, butongrupoj, enigogrupoj kaj paĝigo. - Ĉi tiuj komponantoj dividas norman
z-indexskalon de0tra3. 0estas defaŭlta (komenca),1estas:hover,2estas:active/.active, kaj ,3estas:focus.- Ĉi tiu aliro kongruas kun niaj atendoj de plej alta uzantprioritato. Se elemento estas fokusita, ĝi estas en vido kaj ĉe la atento de la uzanto. Aktivaj elementoj estas due plej altaj ĉar ili indikas staton. Ŝvebi estas la tria plej alta ĉar ĝi indikas uzantan intencon, sed preskaŭ io ajn povas ŝvebi.
Bootstrap inkluzivas plurajn komponantojn, kiuj funkcias kiel ia superkovraĵo. Ĉi tio inkluzivas, en ordo de plej altaj z-index, falmenuoj, fiksaj kaj gluiĝemaj navbaroj, modaloj, konsiletoj kaj popovers. Ĉi tiuj komponantoj havas sian propran z-indexskalon, kiu komenciĝas je 1000. Ĉi tiu komenca nombro estas hazarda kaj servas kiel malgranda bufro inter niaj stiloj kaj la kutimaj stiloj de via projekto.
Ĉiu tegmenta komponanto iomete pliigas sian z-indexvaloron tiel, ke komunaj UI-principoj permesas al uzantoj fokusitaj aŭ ŝvebitaj elementoj resti ĉiam videblaj. Ekzemple, modalo estas dokumentblokado (ekz., vi ne povas fari ajnan alian agon krom la ago de la modalo), do ni metas tion super niaj navbaroj.
Lernu pli pri tio en nia z-indexaranĝa paĝo .
Kiam ajn eblas, ni preferas skribi HTML kaj CSS super JavaScript. Ĝenerale, HTML kaj CSS estas pli produktivaj kaj alireblaj por pli da homoj de ĉiuj malsamaj spertaj niveloj. HTML kaj CSS ankaŭ estas pli rapidaj en via retumilo ol JavaScript, kaj via retumilo ĝenerale provizas multajn funkciojn por vi.
Ĉi tiu principo estas nia unuaklasa JavaScript API estas dataatributoj. Vi ne bezonas skribi preskaŭ ajnan JavaScript por uzi niajn JavaScript kromaĵojn; anstataŭe, skribu HTML. Legu pli pri tio en nia JavaScript-superrigardpaĝo .
Finfine, niaj stiloj baziĝas sur la fundamentaj kondutoj de komunaj retaj elementoj. Kiam ajn eblas, ni preferas uzi tion, kion provizas la retumilo. Ekzemple, vi povas meti .btnklason sur preskaŭ ajna elemento, sed la plej multaj elementoj ne provizas ajnan semantikan valoron aŭ retumilon funkciojn. Do anstataŭe, ni uzas <button>s kaj <a>s.
La sama validas por pli kompleksaj komponantoj. Dum ni povus skribi nian propran formvalidigan kromprogramon por aldoni klasojn al gepatra elemento surbaze de la stato de enigo, tiel permesante al ni stiligi la tekston diru ruĝa, ni preferas uzi la :valid/ :invalidpseŭdo-elementojn, kiujn ĉiu retumilo provizas al ni.
Utilaj klasoj—antaŭe helpantoj en Bootstrap 3—estas potenca aliancano por kontraŭbatali CSS-ŝveladon kaj malbonan paĝan rendimenton. Utila klaso estas tipe ununura, neŝanĝebla posedaĵo-valora parigo esprimita kiel klaso (ekz. .d-blockreprezentas display: block;). Ilia ĉefa allogo estas rapideco de uzo dum skribado de HTML kaj limiganta la kvanton de kutimaj CSS, kiujn vi devas skribi.
Specife pri kutima CSS, iloj povas helpi kontraŭbatali pliigi la grandecon de dosiero reduktante viajn plej ofte ripetajn posedaĵ-valorajn parojn en unuopajn klasojn. Ĉi tio povas havi draman efikon je skalo en viaj projektoj.
Kvankam ne ĉiam eblas, ni strebas eviti tro dogmajn en niaj HTML-postuloj por komponantoj. Tiel, ni fokusiĝas al unuopaj klasoj en niaj CSS-elektiloj kaj provas eviti tujajn filajn elektilojn ( ~). Ĉi tio donas al vi pli da fleksebleco en via efektivigo kaj helpas konservi nian CSS pli simpla kaj malpli specifa.