Retumiloj kaj aparatoj
Lernu pri la retumiloj kaj aparatoj, de modernaj ĝis malnovaj, kiuj estas subtenataj de Bootstrap, inkluzive de konataj strangaĵoj kaj cimoj por ĉiu.
Bootstrap subtenas la plej novajn, stabilajn eldonojn de ĉiuj ĉefaj retumiloj kaj platformoj. En Vindozo, ni subtenas Internet Explorer 10-11 / Microsoft Edge .
Alternativaj retumiloj kiuj uzas la lastan version de WebKit, Blink aŭ Gecko, ĉu rekte aŭ per la interreta API de la platformo, ne estas eksplicite subtenataj. Tamen, Bootstrap devus (en la plej multaj kazoj) montri kaj funkcii ĝuste en ĉi tiuj retumiloj ankaŭ. Pli specifaj subtenaj informoj estas provizitaj sube.
Ĝenerale, Bootstrap subtenas la plej novajn versiojn de la defaŭltaj retumiloj de ĉiu ĉefa platformo. Notu, ke prokuriloj (kiel Opera Mini, la Turbo-reĝimo de Opera Mobile, UC Browser Mini, Amazon Silk) ne estas subtenataj.
| Chrome | Fajrovulpo | Safaro | Android-Retumilo kaj WebView | Microsoft Edge | |
|---|---|---|---|---|---|
| Androido | Subtenita | Subtenita | N/A | Android v5.0+ subtenata | Subtenita |
| iOS | Subtenita | Subtenita | Subtenita | N/A | Subtenita |
| Windows 10 Poŝtelefono | N/A | N/A | N/A | N/A | Subtenita |
Simile, la plej novaj versioj de la plej multaj labortablaj retumiloj estas subtenataj.
| Chrome | Fajrovulpo | interreta Esploristo | Microsoft Edge | Opero | Safaro | |
|---|---|---|---|---|---|---|
| Makintoŝo | Subtenita | Subtenita | N/A | N/A | Subtenita | Subtenita |
| Vindozo | Subtenita | Subtenita | Subtenita, IE10+ | Subtenita | Subtenita | Ne subtenata |
Por Fajrovulpo, aldone al la plej nova normala stabila eldono, ni ankaŭ subtenas la lastan Plilongigitan Subtenan Liberigon (ESR) version de Fajrovulpo.
Neoficiale, Bootstrap devus aspekti kaj konduti sufiĉe bone en Chromium kaj Chrome por Linukso, Fajrovulpo por Linukso kaj Internet Explorer 9, kvankam ili ne estas oficiale subtenataj.
Por listo de iuj el la retumiloj, kiujn Bootstrap devas trakti, vidu nian Muron de retumiloj .
Interreta Esploristo 10+ estas subtenata; IE9 kaj malsupren ne estas. Bonvolu konscii, ke iuj CSS3-ecoj kaj HTML5-elementoj ne estas plene subtenataj en IE10, aŭ postulas prefiksitajn ecojn por plena funkcieco. Vizitu Ĉu mi povas uzi... por detaloj pri retumila subteno de CSS3 kaj HTML5-funkcioj.
Se vi postulas IE8-9-subtenon, uzu Bootstrap 3. Ĝi estas la plej stabila versio de nia kodo kaj ankoraŭ estas subtenata de nia teamo por kritikaj eraroj kaj dokumentaj ŝanĝoj. Tamen, neniuj novaj funkcioj estos aldonitaj al ĝi.
Subteno por overflow: hidden;la <body>elemento estas sufiĉe limigita en iOS kaj Android. Tiucele, kiam vi rulumas preter la supro aŭ malsupro de modalo en iu el tiuj aparatoj retumiloj, la <body>enhavo komencos ruliĝi. Vidu Chrome-cimon #175502 (korektita en Chrome v40) kaj WebKit-cimon #153852 .
Ekde iOS 9.2, dum modalo estas malfermita, se la komenca tuŝo de rula gesto estas ene de la limo de teksta <input>aŭ <textarea>, la <body>enhavo sub la modalo estos rulita anstataŭ la modalo mem. Vidu WebKit-cimon #153856 .
La .dropdown-backdropelemento ne estas uzata en iOS en la navigado pro la komplekseco de z-indeksado. Tiel, por fermi falmenuojn en navbaroj, vi devas rekte alklaki la falmenuman elementon (aŭ ajnan alian elementon, kiu lanĉos klakan eventon en iOS ).
Paĝa zomado neeviteble prezentas bildigajn artefaktojn en iuj komponantoj, kaj en Bootstrap kaj la resto de la reto. Depende de la problemo, ni eble povos ripari ĝin (serĉu unue kaj poste malfermu problemon se necese). Tamen ni emas ignori ĉi tiujn, ĉar ili ofte ne havas rektan solvon krom hakaj solvoj.
Kvankam :hoverne eblas ĉe la plej multaj tuŝaj aparatoj, iOS imitas ĉi tiun konduton, rezultigante "gluiĝemajn" ŝvebstilojn, kiuj daŭras post frapetado de unu elemento. Ĉi tiuj ŝvebstiloj estas nur forigitaj kiam uzantoj frapetas alian elementon. Ĉi tiu konduto estas konsiderata plejparte nedezirinda kaj ŝajnas ne esti problemo en Android aŭ Vindozaj aparatoj.
Laŭlonge de niaj v4-alfa kaj beta-eldonoj, ni inkludis nekompletan kaj komentis kodon por elekti komunikilon pri demandado, kiu malŝaltus ŝvebajn stilojn en tuŝaparataj retumiloj, kiuj imitas ŝvebadon. Ĉi tiu laboro neniam estis plene kompletigita aŭ ebligita, sed por eviti kompletan rompon, ni elektis malrekomendi ĉi tiun shim kaj konservi la miksaĵojn kiel ŝparvojojn por la pseŭdoklasoj.
Eĉ en iuj modernaj retumiloj, presado povas esti stranga.
Ekde Safari v8.0, uzo de la fiks-larĝa .containerklaso povas kaŭzi ke Safaro uzu nekutime malgrandan tiparon dum presado. Vidu numeron #14868 kaj WebKit-cimon #138192 por pliaj detaloj. Unu ebla solvo estas la sekva CSS:
@media print {
.container {
width: auto;
}
}Ekstere de la skatolo, Android 4.1 (kaj eĉ kelkaj pli novaj eldonoj ŝajne) ekspediĝas kun la Foliumilo kiel la defaŭlta retumilo elektita (kontraste al Chrome). Bedaŭrinde, la Foliumilo havas multajn erarojn kaj nekongruojn kun CSS ĝenerale.
Sur <select>elementoj, la Android-akcia retumilo ne montros la flankajn kontrolojn se estas border-radiuskaj/aŭ borderaplikata. (Vidu ĉi tiun StackOverflow demandon por detaloj.) Uzu la malsupran kodon fragmenton por forigi la ofendan CSS kaj prezenti la <select>kiel senstilan elementon en la Android-akcia retumilo. La uzantagento snufado evitas enmiksiĝon kun Chrome, Safari, kaj Mozilla retumiloj.
<script>
$(function () {
var nua = navigator.userAgent
var isAndroid = (nua.indexOf('Mozilla/5.0') > -1 && nua.indexOf('Android ') > -1 && nua.indexOf('AppleWebKit') > -1 && nua.indexOf('Chrome') === -1)
if (isAndroid) {
$('select.form-control').removeClass('form-control').css('width', '100%')
}
})
</script>Ĉu vi volas vidi ekzemplon? Rigardu ĉi tiun JS Bin-demonstron.
Por provizi la plej bonan eblan sperton al malnovaj kaj fuŝaj retumiloj, Bootstrap uzas CSS-retumilon en pluraj lokoj por celi specialajn CSS al certaj foliumilaj versioj por solvi cimojn en la retumiloj mem. Ĉi tiuj hakoj kompreneble kaŭzas CSS-validigilojn plendi ke ili estas nevalidaj. En kelkaj lokoj, ni ankaŭ uzas antaŭajn CSS-funkciojn, kiuj ankoraŭ ne estas plene normigitaj, sed ĉi tiuj estas uzataj nur por progresema plibonigo.
Ĉi tiuj validaj avertoj ne gravas en la praktiko ĉar la ne-haka parto de nia CSS plene validas kaj la hakaj partoj ne malhelpas la ĝustan funkciadon de la ne-haka parto, tial ni intence ignoras ĉi tiujn apartajn avertojn.
Niaj HTML-dokumentoj ankaŭ havas kelkajn bagatelajn kaj sensignifajn HTML-validigajn avertojn pro nia inkludo de solvo por certa Firefox-cimo .