Kleur Ingangen: Een Diepe Duik in Cross-Browser Verschillen

0
12

In dit artikel zullen we een kijkje nemen op de structuur binnen een <input type=’color’> elementen, browser inconsistenties, waarom kijken ze op een bepaalde manier in een bepaalde browser, en hoe om te graven in het. Het hebben van een goed begrip van deze input stelt ons in staat om te beoordelen of een bepaalde cross-browser look kan worden bereikt en hoe om dit te doen met een minimum aan inspanning en een code.

Dit is precies waar we het over hebben:

Maar voordat we dieper in deze, we nodig hebben om in…

Toegankelijkheid!

We hebben een groot probleem hier: voor degenen die volledig te vertrouwen op een toetsenbord, deze ingang niet werkt zoals het zou moeten in Safari en Firefox op Windows, maar het werkt wel in Firefox op de Mac en Linux (die ik alleen getest op Fedora, dus voel je vrij om te schreeuwen bij mij in de comments als het niet werkt voor u met behulp van een andere distributie).

In Firefox op Windows, kunnen we Tabblad om de invoer te richten, druk op Enter om een dialoog… en dat we dan niet navigeren met het toetsenbord!

Ik heb geprobeerd de tab-toets, de pijltoetsen, en elke andere toets op het toetsenbord beschikbaar… niets! Ik kon in ieder geval sluit het dialoogvenster met goede oude Alt + F4. Later, in de bug ticket vond ik voor deze op Bugzilla, ik ontdekte ook een oplossing: met Alt + Tab naar een ander venster, dan Alt + Tab terug en de picker dialoogvenster kunt navigeren met het toetsenbord.

De dingen zijn nog erger in Safari. De ingang is niet eens te focussen (bug ticket) als VoiceOver is niet aan. En zelfs wanneer het gebruik van VoiceOver, de tab-toets door middel van de dialoog de ingangen geopend is onmogelijk.

Als u wilt gebruiken <input type=’color’> op een actuele website, laat het browsers weten dat dit iets is dat moet worden opgelost!

Hoe om binnen te kunnen kijken

In Chrome, we nodig hebben om DevTools, gaat u naar Instellingen , en in de Voorkeuren van de afdeling in het kader Elementen, controleer dan de Toon van de user-agent schaduw DOM optie.

Het weergeven van de structuur binnen een ingang in Chrome.

Toen we terug te inspecteren ons element, zien we in de schaduw van de DOM.

In Firefox, we moeten naar about:config gaan en zorg dat de devtools.inspecteur.showAllAnonymousContent vlag is ingesteld op true.

Het weergeven van de structuur binnen een ingang in Firefox.

Vervolgens sluiten we de DevTools en, wanneer we inspecteren onze invoer nogmaals, zien we in onze input.

Het is jammer dat we niet lijken te hebben een optie om dit in de pre-Chroom Rand.

De structuur binnen

De structuur geopenbaard in DevTools verschilt van browser tot browser, net als voor het aanbod ingangen.

In Chrome, op de top van de schaduw DOM, we hebben een <div> – wrapper die wij kunnen de toegang met behulp van ::-webkit-kleur-swatch-wrapper.

Binnen hebben we nog een <div> we kunnen de toegang met:- webkit-kleur-staal.

Innerlijke structuur in Chrome.

In Firefox, we zien alleen een <div>, maar het is niet gelabeld, dus hoe doen we het?

Op een voorgevoel, gegeven deze <div> heeft de achtergrondkleur ingesteld op de invoer van de waarde van het kenmerk, net als de ::-webkit-kleur-swatch component, heb ik geprobeerd ::-moz-kleur-staal. En het blijkt dat het werkt!

Innerlijke structuur in Firefox.

Echter, ik kwam er later achter dat we een betere manier om uit te zoeken dit voor Firefox!

We kunnen gaan in de Firefox DevTools Instellingen en, in het Infovenster sectie, zorg ervoor dat de “Toon Browser Stijlen” optie is aangevinkt. Vervolgens gaan we terug naar de Inspecteur en selecteer deze <div> in de <input type=’color’>. Onder de user agent stijlen, zien we een regel ingesteld voor input[type=’kleur’]::-moz-kleur-swatch!

Kunnen bekijken browser stijlen in Firefox DevTools.

In de pre-Chroom Rand, kunnen we niet eens zien wat voor soort structuur hebben we binnen. Ik gaf ::-ms-kleur-staal een keer proberen, maar het werkte niet en ook niet ::-ms-swatch (die ik geacht omdat, voor een input type=’bereik’, hebben we ::-webkit-slider-duim-en ::-moz-bereik duim, maar slechts:- ms-duim).

Na een heleboel zoeken, ik vond was dit probleem van 2016. Pre-Chroom Rand blijkbaar verbiedt ons om de stijl van wat er zich ook in deze ingang. Nou, dat is een teleurstelling.

Hoe om te kijken naar de browser stijlen

In alle browsers, hebben we de mogelijkheid van het niet toepassen van om het even welke stijlen van onze eigen en dan op zoek op de berekende stijlen.

In Chrome en Firefox, kunnen we ook zien dat de user agent stylesheet regel stelt dat van invloed zijn op het geselecteerde element (al moeten we expliciet staat dit in Firefox, zoals gezien in de vorige paragraaf).

Het controleren van de browser stijlen in Chrome en Firefox.

Dit is vaak nuttiger dan de berekende stijlen, maar er zijn uitzonderingen en we moeten nog altijd de berekende waarden als goed.

In Firefox, zien we ook het CSS-bestand voor de vorm-elementen in beeld-bron:resource://gre-resources/formulieren.css.

Het controleren van de browser stijlen in Firefox.

Het input element zelf

We zullen nu een kijkje nemen op de standaardwaarden van een paar eigenschappen in verschillende browsers om een duidelijk beeld te krijgen van wat we zouden het echt nodig om expliciet om een aangepaste cross-browser resultaat.

De eerste eigenschap denk ik altijd over de controle als het gaat om de <input> – elementen is box-sizing. De initiële waarde van deze eigenschap border-box in Firefox, maar de inhoud-box in Chrome en Rand.

De box-sizing waarden voor de <input type=’color’> ten opzichte van Chrome, Firefox en Rand (van boven naar onder).

We kunnen zien dat Firefox in te stellen border-box op <input type=’color’>, maar het lijkt Chrome is niet ingesteld op alle, dus het is links met de oorspronkelijke waarde van content-box (en ik vermoed dat hetzelfde geldt voor de Rand).

In ieder geval, wat het allemaal betekent is dat, als we een grens of een bekleding op dit element, we moeten ook expliciet box-sizing, zodat we een consistent resultaat in al deze browsers.

De eigenschap font-waarde is verschillend voor elke browser, maar omdat we geen tekst binnen deze ingang, alles wat we echt belangrijk is, is de font-grootte, die consistent is bij alle browsers heb ik gecontroleerd: 13.33(33)px. Dit is een waarde die ziet er echt als kwam het uit te delen 40px door 3, ten minste in Chrome.

Het lettertype waarden voor de <input type=’color’> ten opzichte van Chrome, Firefox en Rand (van boven naar onder).

Dit is een situatie waar de berekende stijlen zijn meer geschikt voor Firefox, want als we kijken naar de browser stijlen, krijgen we niet veel in termen van nuttige informatie:

Soms is de browser stijlen zijn vrijwel waardeloos (Firefox screenshot).

De marge is ook consistent is in al deze browsers, computing naar 0.

De marge waarden voor de <input type=’color’> ten opzichte van Chrome, Firefox en Rand (van boven naar onder).

De grens is verschillend voor elke afzonderlijke browser. Zowel In Chroom en de Rand, we hebben een solid 1px, maar de rand-kleur is anders (rgb(169, 169, 169) voor Chrome en rgb(112, 112, 112) voor de Rand). In Firefox, de grens is een begin 2px één met een rand-kleur van… ThreeDLightShadow?!

De grens waarden voor de <input type=’color’> ten opzichte van Chrome, Firefox en Rand (van boven naar onder).

Wat is de deal met ThreeDLightShadow? Als het niet bekend voor, maak je geen zorgen! Het is een (inmiddels afgeschafte) CSS2 systeem waarde, die Firefox op Windows toont mij rgb(227, 227, 227) in de Berekende tabblad opmaakprofielen.

De berekende grens-kleur voor <input type=’color’> in Firefox op Windows.

Merk op dat in Firefox op Windows), het besturingssysteem van de zoom-niveau (Instellingen → Systeem → Display → Schaal en de Lay-out → Verander de grootte van de tekst, apps en andere items) zal van invloed zijn op de berekende waarde van de border-width, ook al is dit niet lijkt te gebeuren voor een andere woning heb ik gecontroleerd en het lijkt gedeeltelijk in verband met de border-style.

Zoomniveau-opties in Windows.

Het vreemdste is de berekende border-width waarden voor de verschillende zoomniveaus lijken geen enkele zin. Zo houden we de eerste border-style: outset, we hebben:

  • 1.6 px 125%
  • 2px voor 150%
  • 1.7 px voor 175%
  • 1.5 px 200%
  • 1.8 px voor 225%
  • 1.6 px voor 250%
  • 1.66667 px voor 300%

Als we border-style: solid, we hebben een berekend border-width van 2px, precies zoals het was voor de zoom-waarden die een veelvoud zijn van 50% en exact dezelfde berekende waarden voor border-style: outset voor alle andere zoomniveaus.

De vulling is hetzelfde voor Chrome en Rand (1px 2px), terwijl Firefox is een buitenbeentje weer.

De vulling waarden voor de <input type=’color’> ten opzichte van Chrome, Firefox en Rand (van boven naar onder).

Het kan eruit zien als de Firefox is padding 1px. Dat is wat het is ingesteld en er is geen indicatie van iets overschrijft — als een object wordt overschreven, dan wordt het weergegeven als grijs en met een strike-through.

Het spotten van overschrijvingen in Firefox.

Maar de berekende waarde is eigenlijk 0 8px! Bovendien, dit is een waarde die niet afhankelijk is van het besturingssysteem zoom niveau. Dus, wat de harige heck is er aan de hand?!

De berekende waarde voor de vulling in Firefox komt niet overeen met de waarde die is ingesteld op de ingang.

Nu, als u daadwerkelijk hebt geprobeerd het inspecteren van een kleur-ingang, nam een korte blik op de stijlen, en uw hersenen werken anders dan de mijne (wat betekent dat u leest wat er voor u en niet slechts zoeken naar het ene ding dat voor u van belang zijn, het volledig negeren van alles wat anders…) dan heb je waarschijnlijk gemerkt dat er iets is boven de 1px padding (en moeten als zodanig gemarkeerd zijn) — de stroom-relatieve padding!

Flow-relatieve padding overschrijvingen in Firefox.

Dang, die wist dat deze eigenschappen met veel letters waren eigenlijk relevant? Dankzij Zoltan voor het opmerken en me te laten weten. Anders, het zou waarschijnlijk hebben me twee dagen om dit een uitzoeken.

Dit roept de vraag op of dezelfde soort overschrijven kon niet gebeuren in andere browsers en/of voor andere eigenschappen.

Edge ondersteunt geen CSS logische eigenschappen, dus het antwoord is “nee” in die hoek.

In Chrome, geen van de logische eigenschappen voor marge, rand of vulling zijn expliciet ingesteld voor <input type=’color’>, dus we hebben niet opheffen.

Over andere eigenschappen in Firefox, zouden wij bevonden ons in dezelfde situatie voor de marge of voor de grens, maar met deze twee, het is gewoon zo gebeurt het flow-relatieve eigenschappen niet expliciet hebt ingesteld voor onze input, dus nogmaals, er is niet overschrijven.

En zelfs dan is het zeker iets om naar uit te kijken voor in de toekomst!

Bewegen op de afmetingen, onze ingang is de breedte is 44px in Chrome en Rand en 64px in Firefox.

De breedte van de waarden voor de <input type=’color’> ten opzichte van Chrome, Firefox en Rand (van boven naar onder).

De hoogte is 23px in alle drie de browsers.

De hoogte van de waarden voor de <input type=’color’> ten opzichte van Chrome, Firefox en Rand (van boven naar onder).

Merk op dat, aangezien Chrome Rand en hebben een box-sizing van content-box, hun breedte en hoogte waarden omvatten niet de padding of border. Echter, sinds Firefox heeft box-sizing ingesteld op border-box, de afmetingen zijn inclusief de padding en border.

De lay-out vakjes voor <input type=’color’> ten opzichte van Chrome, Firefox en Rand (van boven naar onder).

Dit betekent dat de content-box is 44pxx23px in Chrome en Rand en 44xpxx19px in Firefox, de padding-box is 48pxx25 in Chrome en Rand en 60pxx19px in Firefox en de border-box is 50pxx27px in Chrome en Rand en 64pxx23 in Firefox.

Kunnen We duidelijk zien hoe de dimensies werden in Chrome en ik zou aannemen dat ze zijn ingesteld in het directe manier in de Rand, ook als Rand verbiedt ons om te traceren van dit spul. Firefox niet laten zien dat deze dimensies als dat uitdrukkelijk werd ingesteld en heeft niet eens ons toelaten om na te gaan waar zij kwamen uit in de Berekende tabblad (als niet voor andere eigenschappen zoals de grens, bijvoorbeeld). Maar als we kijken naar de stijlen die ingesteld zijn op de input[type=’kleur’], ontdekken we de afmetingen zijn ingesteld als flow-relatief zijn (inline-grootte en block-size).

Hoe <input type=’color’> afmetingen zijn in Firefox.

De laatste eigenschap controleren we voor de normale staat van de eigenlijke ingang is de achtergrond. Hier Edge is de enige browser om een achtergrond-afbeelding (ingesteld op een van boven naar beneden verloop), terwijl Chrome en Firefox hebben beide een achtergrond kleuren instellen naar ButtonFace (een ander verouderd CSS2 systeem-waarde). Het vreemde is dat moet worden rgb(240, 240, 240) (volgens deze bron), maar de berekende waarde in Chrome is rgb(221, 221, 221).

De achtergrond waarden voor de <input type=’color’> ten opzichte van Chrome, Firefox en Rand (van boven naar onder).

Wat nog vreemder is, dat als we ook kijken naar onze input in Chrome, het doet zeker kijken als het moet een gradient achtergrond! Als we screenshot en gebruik dan een picker, krijgen we dat het een boven naar beneden verloop van #f8f8f8 te #ddd.

Wat de eigenlijke ingang eruit ziet in Chrome. Het blijkt om een kleurverloop te hebben, in weerwil van de info die we krijgen van DevTools vertellen ons maakt het niet.

Houd er ook rekening mee dat het veranderen van slechts de achtergrond-kleur (of een andere eigenschap niet in verband met de afmetingen zoals border-radius) in de Rand, verandert ook de achtergrond-afbeelding, achtergrond-oorsprong, border-color of border-style.

Rand: side-effecten van het veranderen van de achtergrond-kleur.

Andere staten

We kunnen een kijkje nemen op de stijlen toegepast voor een groot aantal andere staten van een element door te klikken op de hov – knop in het deelvenster Stijlen voor Chrome en Firefox en de een: knop in dezelfde deelvenster Stijlen voor Edge. Dit wijst op een afdeling waar kunnen wij de gewenste stand(s).

Een kijkje nemen bij andere staten in Chrome, Firefox, Rand (van boven naar beneden).

Merk op dat, in Firefox, het controleren van een klasse alleen visueel geldt de gebruiker stijlen op het geselecteerde element, niet de browser stijlen. Dus, als we inchecken :hover bijvoorbeeld, zullen we niet zien :hover stijlen toegepast op ons element. Wij kunnen echter wel zien dat de user agent stijlen die overeenkomen met de geselecteerde staat voor onze geselecteerde element weergegeven in DevTools.

Bovendien kunnen we niet testen voor alle lidstaten als deze, en laten we beginnen met een dergelijke staat.

:uitgeschakeld

Om te zien hoe stijlen veranderen in dit land, we moeten handmatig toevoegen van de disabled attribuut van de <input type=’color’> element.

Hmm… niet veel wijzigingen in een browser!

In Chrome, zien we de achtergrond-kleur is iets anders (rgb(235, 235, 228) in de :disabled (uitgeschakeld) staat tegenover rgb(221, 221, 221) in de normale status).

Chrome :uitgeschakeld styling.

Maar het verschil is alleen duidelijk op zoek naar de info in DevTools. Visueel, kan ik vertellen dat er een klein verschil tussen een input-dat is :disabled (uitgeschakeld) en een die niet of ze de side-by-side, maar als ik niet van te voren weten, ik kon het niet vertellen, die is, die slechts door naar hen te kijken, en als ik zag, ik kon niet zeggen of het is ingeschakeld of niet zonder te klikken.

Uitgeschakeld (links) versus ingeschakeld (recht) <input type=’color’> in Chrome.

In Firefox, we hebben exact dezelfde waarden zijn ingesteld voor :disabled (uitgeschakeld) staat als voor de normale toestand (goed, behalve voor de cursor, die realistisch is, is niet van plan om te produceren verschillende resultaten opslaan voor uitzonderlijke gevallen toch). Wat geeft, Firefox?!

Firefox :uitgeschakeld (boven) versus normale (onder) styling.

In de Rand, zowel de grens-kleur en het verloop van de achtergrond zijn anders.

Rand :uitgeschakeld styling (door te controleren berekend stijlen).

We hebben de volgende stijlen voor de normale staat:

border-color: rgb(112, 112, 112);
background-image: linear-gradient(rgb(236, 236, 236), rgb(213, 213, 213));

En voor :disabled (uitgeschakeld) staat:

border-color: rgb(186, 186, 186);
background-image: linear-gradient(rgb(237, 237, 237), rgb(229, 229, 229));

Duidelijk verschillend als we kijken naar de code en visueel beter dan Chrome, hoewel het nog niet erg genoeg:

Uitgeschakeld (links) versus ingeschakeld (recht) <input type=’color’> in de Rand.

:focus

Dit is een toestand kunnen we testen door het schakelen van de DevTools pseudo-klassen. Nou, in theorie. In de praktijk is het niet echt helpen ons in alle browsers.

Vanaf Chrome, kunnen we zien dat we een overzicht in deze staat en de outline-color berekent aan rgb(77, 144, 254), dat is een soort van blauw.

Chrome :focus styling.

Vrij eenvoudig en gemakkelijk te herkennen.

Op weg naar Firefox, dingen beginnen te krijgen harige! In tegenstelling tot Chrome, wisselen de :focus pseudo-class van DevTools, gebeurt er niets op het input element, maar door de nadruk (door tabblad klikt), wordt de rand blauw en we krijgen er een gestippelde rechthoek binnen — maar er is geen indicatie in DevTools over wat er gebeurt.

Wat gebeurt er in Firefox wanneer met de tab naar onze input :focus het.

Als we controleren of Firefox de formulieren.css biedt een verklaring voor de gestippelde rechthoek. Dit is de gestippelde rand van een pseudo-element, ::-moz-focus-binnen (een pseudo-element die, voor sommige reden, niet wordt weergegeven in DevTools binnen onze input als:- moz-kleur-staal). Deze grens is in eerste instantie transparante en dan wordt zichtbaar wanneer de ingang is gericht — de pseudo-class gebruikt hier (:-moz-focusring) is vrij veel een oude Firefox-versie van de nieuwe standaard (:focus-zichtbaar), die momenteel alleen ondersteund door Chrome achter de Experimentele Web Platform is voorzien van een vlag.

Firefox: waar de innerlijke gestippelde rechthoek op :de focus komt uit.

Hoe zit het met de blauwe rand? Nou, het lijkt erop dat dit niet wordt ingesteld door een stylesheet, maar op een OS-niveau in de plaats. Het goede nieuws is dat we kunnen overschrijven al deze stijlen moeten we kiezen om dit te doen.

In de Rand, worden we geconfronteerd met een soortgelijke situatie. Er gebeurt niets wanneer het schakelen van de :focus pseudo-class van DevTools, maar als we werkelijk tab om onze input te concentreren, zien we een innerlijke gestippelde rechthoek.

Wat gebeurt er in de Rand, wanneer de tab-toets om onze input :focus het.

Hoewel ik op geen enkele manier van zeker weten, ik vermoed dat, net als in Firefox, deze binnenste rechthoek is te wijten aan een pseudo-element dat wordt zichtbaar op :focus.

:beweeg met de muis

In Chrome, wisselen deze pseudo-class is niet gebleken van feiten :hover-specifieke stijlen in DevTools. Bovendien, eigenlijk door de input niet wordt weergegeven om iets te veranderen visueel. Zodat het er uitziet als Chrome, maakt echt niet hebben :hover-specifieke stijlen?

In Firefox, wisselen de :hover pseudo-class van DevTools blijkt dat er een nieuwe regel in het deelvenster stijlen:

Firefox :hover styling zoals te zien is in DevTools.

Wanneer daadwerkelijk door de ingang zien we de achtergrond lichtblauw en de grens blauw, dus de eerste gedachte zou zijn dat het licht blauw -moz-buttonhoverface waarde en dat de blauwe rand is opnieuw ingesteld op het niveau van het BESTURINGSSYSTEEM, net als in de :focus geval.

Wat gebeurt er eigenlijk in Firefox op :hover.

Echter, als we kijken naar de berekende stijlen, zien we dezelfde achtergrond hebben we in de normale toestand, dus die blauwe achtergrond is waarschijnlijk echt een OS-niveau, in weerwil van het hebben van die regel in de vormen.css stylesheet.

Firefox: berekende achtergrond-kleur van een <input type=’color’> op :hover.

In de Rand, het schakelen van de :hover pseudo-class van DevTools geeft ons input een licht blauw (rgb(166, 244, 255)) achtergrond en een blauw (rgb(38, 160, 218)) grens, waarvan de exacte waarden die we kunnen vinden in de Berekende tabblad:

Rand: berekende background-color en border-color van een <input type=’color’> op :hover.

:actief

Het controleren van de actieve status in de Chrome DevTools doet niets visueel en geeft geen specifieke regels in het deelvenster Stijlen. Echter, als we echt op onze input, zien we dat het verloop van de achtergrond die niet eens te zien in DevTools in de normale toestand wordt teruggedraaid.

Wat de eigenlijke ingang eruit ziet in Chrome in de :actieve toestand. Het lijkt een gradient (omgekeerde van de normale toestand), in weerwil van de info die we krijgen van DevTools vertellen ons maakt het niet.

In Firefox DevTools, wisselen de :actieve staat op, doet niets, maar als we ook wisselen de :hover state op, dan krijgen we een regel ingesteld, dat wijzigingen in de inline-padding (het blok is padding op dezelfde waarde ingesteld van 0 in alle andere lidstaten), de border-style en zet de achtergrondkleur terug naar onze oude vriend ButtonFace.

Firefox :active styling zoals te zien is in DevTools.

In de praktijk, echter, het enige dat overeenkomt met de info die we krijgen van DevTools is de inline-shift gegeven door de verandering in de logische vulling. De achtergrond wordt een lichter blauw dan de :hover state en de grens is blauw. Beide veranderingen zijn waarschijnlijk gebeurt op een OS niveau.

Wat gebeurt er eigenlijk in Firefox in een :actieve toestand.

In de Rand, het activeren van de actieve klasse van DevTools geeft ons de exacte dezelfde stijlen die we hebben voor de :hover state. Echter, als we zowel de :hover en :active staten, dingen veranderen een beetje. We hebben nog steeds een licht blauwe achtergrond en een blauwe rand, maar beide zijn nu donkerder (rgb(52, 180, 227) voor de achtergrond-kleur en rgb(0, 137, 180) voor de border-color):

De berekende background-color en border-color van een <input type=’color’> aan :actieve bekeken in de Rand.

Dit is de meeneemmaaltijden: als we willen dat een consistente cross-browser resultaten voor <input type=’color’>, moeten we bepalen onze eigen duidelijk herkenbare stijlen voor al deze staten zelf omdat deze, gelukkig, bijna alle browser standaardinstellingen, met uitzondering van de binnenste rechthoek krijgen we in de Rand op :focus — kan worden overschreven.

De swatch wrapper

Dit is een onderdeel zien we alleen in Chrome, dus als we willen dat een cross-browser resultaat, moeten we waarschijnlijk voor zorgen dat het geen invloed heeft op het staal aan de binnenkant — dit betekent dat ervoor gezorgd heeft geen margin, border, padding of achtergrond is en dat de afmetingen gelijk zijn aan die van de werkelijke invoer content-box.

Om te weten of we moeten knoeien met deze eigenschappen (en misschien anderen als gevolg) of niet, laten we zien wat de browser die standaard zijn voor hen.

Gelukkig, we hebben geen marge of grens, zodat we niet hoeven te maken over deze.

De marge en de grens-waarden voor de swatch verpakking en in Chrome.

We hebben wel een non-zero padding (van 4px 2px), dus dit is iets wat we moeten op nul uit als we het willen bereiken van een consistente cross-browser resultaat.

De vulling waarden voor de swatch verpakking en in Chrome.

De afmetingen zijn zowel gunstig zijn ingesteld op 100%, wat betekent dat we niet hoeft te knoeien met hen.

De size-waarden voor de swatch verpakking en in Chrome.

Iets wat we nodig hebben om hier op te merken is dat we box-sizing ingesteld op border-box, zodat de vulling wordt afgetrokken van de afmetingen op deze wrapper.

De box-sizing waarde voor de swatch verpakking en in Chrome.

Dit betekent dat, terwijl de padding-box, border-box en marge-box van onze wrapper (allemaal gelijk, want we hebben geen marge of grens) zijn identiek aan de inhoud-box van de werkelijke <input type=’color’> (dat is 44pxx23px in Chrome), het krijgen van de verpakking de inhoud van het vak gaat om het aftrekken van de vulling van deze dimensies. Het resultaat is dat deze doos is 40pxx15px.

De box-model voor de swatch verpakking en in Chrome.

De achtergrond is ingesteld op transparant, dus dat is een andere eigenschap die we niet hoeft te maken over het resetten.

De achtergrondwaarden voor de swatch verpakking en in Chrome.

Er is nog een eigenschap is ingesteld op dit element, dat mijn aandacht trok: het display. Het heeft een waarde van flex, wat betekent dat de kinderen flex-items.

De waarde op het display voor de swatch verpakking en in Chrome.

De swatch

Dit is een component kunnen we stijl in Chrome en Firefox. Helaas, Rand niet blootstellen aan ons toe te stijl, dus kunnen we niet veranderen eigenschappen kunnen we, zoals randen, border-radius-of box-shadow.

De box-sizing van het pand is een moeten we expliciet als we van plan zijn op het geven van de swatch van een grens of een padding, omdat de waarde ervan is content-box in Chrome, maar border-box in Firefox.

De box-sizing waarden voor de swatch bekeken in Chrome (boven) en Firefox (onder).

Gelukkig, de font-grootte is overgenomen van de ingang zelf, dus is het hetzelfde.

De font-size-waarden voor de swatch bekeken in Chrome (boven) en Firefox (onder).

De marge berekent aan 0 in Chrome en Firefox.

De marge waarden voor de swatch bekeken in Chrome (boven) en Firefox (onder).

Dit is omdat de meeste marges nog niet zijn ingesteld, zodat ze uiteindelijk op 0 is de standaardwaarde in voor de <div> – elementen. Echter, Firefox is het instellen van de inline marges voor de auto en we krijgen waarom dat berekent aan 0 in slechts een klein ogenblik.

De inline-marge voor het staal wordt ingesteld op automatisch in Firefox.

De grens is solid 1px in beide browsers. Het enige wat verschilt is de border-color, die is rgb(119, 119, 119) in Chroom en grijs (of rgb(128, 128, 128), dus iets lichter) in Firefox.

De grens waarden voor de swatch bekeken in Chrome (boven) en Firefox (onder).

Merk op dat de berekende border-width in Firefox op Windows) is afhankelijk van het OS zoom-niveau, net zoals in het geval van de feitelijke invoer.

De vulling is gelukkig 0 in Chrome en Firefox.

De vulling waarden voor de swatch bekeken in Chrome (boven) en Firefox (onder).

De afmetingen worden precies wat we zouden verwachten, uitgaande van de swatch heeft betrekking op de ouders op de gehele content-box.

De box-model voor de swatch bekeken in Chrome (boven) en Firefox (onder).

In Chrome, de swatch ouder is de <div> – wrapper we eerder al zagen, waarvan de inhoud-box is 4pxx15px. Dit is gelijk aan de marge-box en de border-box van de swatch (die samenvallen, als we geen marge). Sinds de vulling is 0, de content-box en de padding-box voor de swatch zijn identiek en, af te trekken van de 1px border, krijgen we de dimensies die zijn 38pxx13px.

In Firefox, de swatch ouder is de eigenlijke ingang, waarvan de inhoud-box is 44pxx19px één. Dit is gelijk aan de marge-box en de border-box van de swatch (die samenvallen, als we geen marge). Sinds de vulling is 0, de content-box en de padding-box voor de swatch zijn identiek en, af te trekken van de 1px border, we krijgen dat hun afmetingen zijn 42pxx17px.

In Firefox, zien we dat de swatch is gemaakt ter dekking van de ouder-content-box door het hebben van zowel de afmetingen zijn ingesteld op 100%.

De size-waarden voor de swatch bekeken in Chrome (boven) en Firefox (onder).

Dit is de reden waarom de automatische waarde voor de inline-marge berekent aan 0.

Maar hoe zit het met Chrome? We kunnen niet zien een werkelijke afmetingen worden ingesteld. Nou, dit is het gevolg van de flex-lay-out en het feit dat de swatch is een flex-item dat is gemaakt om te strekken, zodanig dat het betrekking op de ouder-content-box.

De flex-waarde voor de swatch verpakking en in Chrome.

Laatste gedachten

Phew, we vallen veel van de grond hier! Hoewel het misschien lijkt uitputtend om dit te graven diep in op één specifiek element, dit is het soort oefening dat illustreert hoe moeilijk het is cross-browser ondersteuning kan worden. We hebben onze eigen stijlen, user-agent stijlen en besturingssysteem stijlen te doorkruisen en sommige van deze zijn altijd gaat om wat ze zijn. Maar, zoals we al besproken op de top, dit leidt tot toegankelijkheid probleem aan het eind van de dag, en echt iets om te overwegen als het gaat om de uitvoering van een praktische, functionele toepassing van een kleur-ingang.

Vergeet niet, een groot deel van deze rijp grondgebied te bereiken browser leveranciers en laat hen weten hoe ze een update van hun implementaties op basis van uw gemeld use cases. Hier zijn de drie kaartjes die ik eerder vermeld waar u kunt klokkenspel in of verwijzing naar een ” nieuw ticket aanmaken:

  • WebKit (Bug #194756)
  • Mozilla (Bug #1526820)
  • Pre-Chroom Rand (Issue #57, gesloten)