Färg Ingångar: En djupdykning i Cross-Browser Skillnader

0
46

I den här artikeln, vi kommer att ta en titt på strukturen i <input type=’color’> – element, webbläsare inkonsekvenser, varför de ser ut på ett visst sätt i en viss webbläsare, och hur man gräva i det. Ha en god förståelse för denna ingång gör det möjligt för oss att bedöma om en viss cross-browser utseende kan uppnås och hur att göra så med ett minimum av ansträngning och kod.

Här är exakt vad vi pratar om:

Men innan vi dyker in här, vi måste få till…

Frågor som rör tillgänglighet!

Vi har ett stort problem här: för dem som helt förlitar sig på ett tangentbord, denna ingång inte fungerar som det ska i Safari och Firefox på Windows, men det fungerar i Firefox på Mac och Linux (som jag testade bara på Fedora, så känn dig fri att skrika på mig i kommentarerna om det inte fungerar för dig att använda en annan fördelning).

I Firefox på Windows, kan vi Flik till ingången till det fokus, tryck Enter för att få upp en dialogruta som… som vi sedan inte kan navigera med tangentbordet!

Jag har försökt tabb, piltangenterna, och alla andra viktiga tillgängliga på tangentbordet… ingenting! Jag kan åtminstone stänga dialogrutan med gamla goda Alt + F4. Senare, i fel biljett jag hittade detta på Bugzilla, jag upptäckte också en lösning: Alt + Tabb till ett annat fönster, och sedan Alt + Tabb tillbaka och picker dialogrutan kan navigera med tangentbordet.

Saker är ännu värre i Safari. Ingången är inte ens tabbindexvärden (bugg biljett) om VoiceOver är inte på. Och även när du använder VoiceOver -, tabb genom dialog ingångarna öppnas är omöjligt.

Om du vill använda <input type=’color’> på en faktisk webbplats, vänligen meddela webbläsare vet att detta är något som måste lösas!

Hur man ser ut inuti

I Chrome, vi måste få upp DevTools, gå till Inställningar och de Inställningar under avsnittet Element, kontrollera den Visar user agent skugga DOM alternativet.

Hur att visa strukturen inuti en ingång i Chrome.

Sedan när vi kommer hem för att inspektera vår del, vi kan se in i dess skugga DOM.

I Firefox, måste vi gå till about:config och säkerställa devtools.inspektör.showAllAnonymousContent flagga är satt till true.

Hur att visa strukturen inuti en ingång i Firefox.

Sedan stänger vi DevTools och, när vi granskar vår ingång igen, kan vi se i vår ingång.

Tyvärr, vi verkar inte att ha en möjlighet för detta i pre-Krom Kant.

Struktur inuti

Strukturen visade i DevTools skiljer sig åt från webbläsare till webbläsare, precis som det gör för olika ingångar.

I Chrome längst upp i skuggan DOM, vi har en <div> wrapper som vi kan få tillgång till med hjälp av ::-webkit-färg-swatch-omslag.

Inne i det, vi har en <div> kan vi komma med ::-webkit-färg-swatch.

Inre struktur i Chrome.

I Firefox, vi ser bara en <div>, men det är inte märkt på något sätt, så hur gör vi åt det?

På en magkänsla, med tanke på detta <div>: en har background-color för de där inmatade värdet för attributet, precis som ::-webkit-färg-swatch komponent, jag försökte ::-moz-färg-swatch. Och det visar sig att det fungerar!

Inre struktur i Firefox.

Men senare fick jag veta att vi har ett bättre sätt att räkna ut detta för Firefox!

Vi kan gå till Firefox DevTools Inställningar och, i den Inspektör avsnitt, se “Visa Webbläsaren Stilar” är markerat. Då går vi tillbaka till Inspector och välj detta <div> i vårt <input type=’color’>. Bland user agent stilar, ser vi en regel som för input[type=’color’]::-moz-färg-swatch!

Aktivera visning av webbläsare stilar i Firefox DevTools.

I pre-Krom Kant, vi kan inte ens se vilken typ av struktur som vi har inne. Jag gav ::-ms-färg-swatch ett försök, men det fungerade inte och det gjorde inte heller ::-ms-swatch (som jag ansåg därför att, för en input type= “utbud”, har vi ::-webkit-reglaget-tumme och ::-moz-utbud tummen, men bara ::-ms-tumme).

Efter en hel del sökande, allt jag hittade var den här frågan från och med 2016. Pre-Krom Kant tydligen inte tillåter oss att styla det som finns innanför denna ingång. Tja, det är en besvikelse.

Hur man ser på webbläsaren stilar

I alla webbläsare, vi har möjlighet att inte tillämpa någon stilar av våra egna och tittar sedan på den beräknade stilar.

I Chrome och Firefox, kan vi också se user agent stylesheet regeluppsättningar som påverkar den valda element (även om vi behöver inte uttryckligen att detta i Firefox, som vi sett i föregående avsnitt).

Kontrollera webbläsaren stilar i Chrome och Firefox.

Detta är ofta mer användbart än det beräknade stilar, men det finns undantag och vi bör ändå kontrollera alltid de beräknade värdena också.

I Firefox kan vi också se att CSS-filen för den form element på visa-källa:resurs://gre-resurser/blanketter.css.

Kontrollera webbläsaren stilar i Firefox.

Input-element i sig

Vi ska nu ta en titt på de förvalda värdena för ett fåtal fastigheter i olika webbläsare, för att få en tydlig bild av vad vi verkligen skulle behöva för att ange uttryckligen i syfte att få en egen cross-browser resultat.

Den första egenskapen jag har alltid tänka på att kontrollera när det kommer till <input> – element är box-sizing. Det ursprungliga värdet för den här egenskapen är border-box i Firefox, men innehållet-rutan i Chrome och Edge.

Box-sizing-värden för <input type=’color’> jämföras i Chrome, Firefox och Edge (från topp-till-botten).

Vi kan se att Firefox är satt till border-box på <input type=’color’>, men det ser ut som Chrome är inte ställa den till alla, så det är vänster med det ursprungliga värdet av innehåll-box (och jag misstänker att det samma är sant för Edge).

I alla fall, vad det betyder är att, om vi ska ha en gräns eller en utfyllnad på detta element har vi också behov av att uttryckligen ange box-sizing, så att vi få ett konsekvent resultat inom samtliga dessa webbläsare.

Teckensnitt värdet som är olika för varje webbläsare, men eftersom vi inte har text inuti denna ingång, alla vi som verkligen bryr sig om är font-size, som är konsekvent över alla webbläsare jag har kontrollerat: 13.33(33)px. Detta är ett värde som verkligen ser ut som om det kom från att dela 40px av 3, åtminstone i Chrome.

Teckensnitt värden för <input type=’color’> jämföras i Chrome, Firefox och Edge (från topp-till-botten).

Detta är en situation där det beräknade stilar är mer användbara för Firefox, för om vi ser på webbläsaren stilar, får vi inte mycket i termer av nyttig information:

Ibland webbläsaren stilar är ganska meningslöst (Firefox skärmdump).

Marginalen är också konsekvent över alla dessa webbläsare, datorer till 0.

Marginalen värden för <input type=’color’> jämföras i Chrome, Firefox och Edge (från topp-till-botten).

Gränsen är olika för varje webbläsare. I både Chrome och Edge, vi har en solid 1px en, men gränsen-färg är olika (rgb(169, 169, 169) för Krom och rgb(112, 112, 112) för Edge). I Firefox, gränsen är en början 2px en, med en border-color av… ThreeDLightShadow?!

Gränsen värden för <input type=’color’> jämföras i Chrome, Firefox och Edge (från topp-till-botten).

Vad är det med ThreeDLightShadow? Om det inte låter bekant, oroa dig inte! Det är ett (nu borttagna) CSS2 systemet värde, som Firefox på Windows visar mig att vara rgb(227, 227, 227) i den Beräknade stilar fliken.

Beräknad border-color till <input type=’color’> i Firefox på Windows.

Observera att i Firefox (åtminstone på Windows), operativsystemet zoom-nivå (Inställningar → System → Display → Skala och Layout → Ändra storlek på text, program och andra objekt) kommer att påverka det beräknade värdet av border-width, även om det inte verkar hända för någon annan egenskap jag har kollat och det verkar vara delvis relaterade till border-style.

Zoom-nivå alternativ på Windows.

Det märkligaste är den beräknade border-width värden för olika zoom-nivåer som inte verkar göra något vettigt. Om vi behåller den ursprungliga border-style: början, vi har:

  • 1.6 px för 125%
  • 2px för 150%
  • 1.7 px för 175%
  • 1,5 px 200%
  • 1.8 px för 225%
  • 1.6 px för 250%
  • 1.66667 px för 300%

Om vi sätter border-style: solid, vi har ett beräknat border-width av 2px, exakt som det var, för zoom-värden som är multiplar av 50% och exakt samma beräknade värden för border-style: början för alla andra zoom nivåer.

Fyllningen är samma för Chrome och Edge (1px 2px), medan Firefox är den udda ett ut igen.

Stoppning värden för <input type=’color’> jämföras i Chrome, Firefox och Edge (från topp-till-botten).

Det kan se ut som Firefox utfyllnad är 1px. Det är vad den är inställd på och det är ingen indikation på något övervägande om en fastighet är åsidosätts, då är det som visas som grå och med en överstruken.

Spotting åsidosätter i Firefox.

Men det beräknade värdet är faktiskt 0 8px! Dessutom, detta är ett värde som inte beror på operativsystemet zoom-nivå. Så, vad hårig fan är det som händer?!

Beräknat värde för utfyllnad i Firefox som inte matchar det värde som sattes på ingång.

Nu, om ni har faktiskt försökt att inspektera en färg ingång, tog en närmare titt på de stilar som anges på den, och din hjärna fungerar annorlunda än mig (vilket innebär att du läser vad som finns i framför dig och inte bara söka efter en sak som intresserar dig, helt ignorerar allt annat…) så har du säkert märkt att det är något tvingande 1px utfyllnad (och bör markeras som sådana) — flow-i förhållande utfyllnad!

Flow-i förhållande utfyllnad åsidosätter i Firefox.

Dang, som kände dessa egenskaper med massor av bokstäver var faktiskt relevant? Tack till Lennart för att märka och låta mig veta. Annars förmodligen skulle ha tagit mig två dagar att lista ut.

Detta väcker frågan om samma typ av åsidosätta kunde inte hända i en annan webbläsare och/eller för andra fastigheter.

Edge inte har stöd för CSS logiska egenskaper, så är svaret “nej” i det hörnet.

I Chrome, ingen av de logiska egenskaper för marginal -, kant-eller utfyllnad ligger uttryckligen <input type=’color’>, så vi har ingen överskrivning.

Om andra fastigheter i Firefox, vi skulle ha befunnit oss i samma situation för marginal eller för gränsen, men med dessa två, det bara händer så flödet-relativa egenskaper har inte varit explicit är satt för vår insats, så återigen, det finns ingen överskrivning.

Ännu så det är definitivt något att se upp för i framtiden!

Vi går vidare till mått, våra ingång bredd är 44px i Chrome och Kant och 64px i Firefox.

Bredd värden för <input type=’color’> jämföras i Chrome, Firefox och Edge (från topp-till-botten).

Dess höjd är 23px i alla tre webbläsare.

Höjd värden för <input type=’color’> jämföras i Chrome, Firefox och Edge (från topp-till-botten).

Observera att eftersom Chrome och Edge har en box-sizing av innehåll-låda, bredd och höjd värden som inte inkluderar padding eller border för. Men eftersom Firefox har en box-sizing inställd på att border-box, dess dimensioner inkluderar padding och border.

Layouten lådor till <input type=’color’> jämföras i Chrome, Firefox och Edge (från topp-till-botten).

Detta innebär att innehållet-box är 44pxx23px i Chrome och Kant och 44xpxx19px i Firefox, padding-box är 48pxx25 i Chrome och Kant och 60pxx19px i Firefox och border-box är 50pxx27px i Chrome och Kant och 64pxx23 i Firefox.

Vi kan tydligt se hur de mått som anges i Chrome och skulle jag antar att de var inställda på samma direkta sätt i Kanten också, även om Kanten inte tillåter oss att spåra det här. Firefox visar inte dessa dimensioner som har varit uttryckligen har angett och inte ens tillåta oss att spåra var de kom ifrån i de Beräknade fliken (som det gör för andra egenskaper som gräns, till exempel). Men om vi tittar på alla de stilar som har ställts in på input[type=’color’], upptäcker vi de dimensioner som har fastställts som flow-förhållande som (inline-storlek och block-size).

Hur <input type=’color’> > mått har fastställts i Firefox.

Den sista egenskapen som vi in för det normala tillståndet i det faktiska bidrag är bakgrunden. Här, Kanten är den enda webbläsaren till bakgrunden-bild (set till en topp till botten gradient), medan Chrome och Firefox har båda en bakgrund-färg på ButtonFace (en annan utfasade CSS2 systemet värde). Det märkliga är att detta ska vara rgb(240, 240, 240) (enligt denna resurs), men dess beräknade värdet i Krom är rgb(221, 221, 221).

Bakgrunden värden för <input type=’color’> jämföras i Chrome, Firefox och Edge (från topp-till-botten).

Vad som är ännu konstigare är det att, om vi faktiskt titta på vår insats i Chrome, det säkert inte ut som det har en tonad bakgrund! Om vi skärmdump på det och sedan använda en datumväljare, får vi att den har en toppen till botten gradient från f8f8f8 till #ddd.

Vad det faktiska bidrag ser ut i Chrome. Det verkar ha en lutning, i trots av den information vi får från DevTools berättar det inte.

Också, observera att ändra bara background-color (eller annan egendom som inte är relaterade till dimensioner som border-radius) i Kanten, ändras även bakgrunden-bild, bakgrund, ursprung, border-color eller border-style.

Kant: sida-effekter av att ändra background-color.

Andra stater

Vi kan ta en titt på de stilar som tillämpas för en massa andra stater av ett element genom att klicka på :hov – knappen i panelen Formatmallar för Chrome och Firefox och en: – knappen på samma Stilar panel för Kanten. Detta avslöjar ett avsnitt där vi kan kontrollera att det önskade tillståndet(s).

Ta en titt på andra länder i Chrome, Firefox, Edge (från topp till botten).

Observera att det i Firefox, kontrollera att en klass bara visuellt gäller användaren stilar på det markerade elementet, inte webbläsaren stilar. Så, om vi kontrollera :hover till exempel, vi kommer inte se den :hover formatmallar på våra element. Vi kan dock se user agent stilar som matchar den valda staten för våra valda elementet visas i DevTools.

Också, att vi inte kan testa för alla stater som denna och låt oss börja med en sådan stat.

:funktionshindrade

För att se hur stilar förändring i detta tillstånd, vi måste manuellt lägga till funktionshindrade attribut till vår <input type=’color’> – elementet.

Hmm… inte mycket förändringar i alla webbläsare!

I Chrome, ser vi background-color är något annorlunda (rgb(235, 235, 228) i :inaktiverat tillstånd jämfört med rgb(221, 221, 221) i normalt tillstånd).

Chrome :funktionshindrade styling.

Men skillnaden är bara tydligt ser på info i DevTools. Visuellt, kan jag berätta berätta att det är en liten skillnad mellan en ingång som är funktionshindrade och en som inte är om de är sida-vid-sida, men om jag inte vet på förhand, kunde jag inte säga vilken som är vilken genom att bara titta på dem, och om jag såg bara en, jag kunde inte berätta om det är aktiverat eller inte utan att klicka på den.

Avaktiverad (vänster) jämfört med aktiverad (höger) <input type=’color’> i Chrome.

I Firefox, vi har exakt samma värden som fastställts i :inaktiverat tillstånd som för det normala tillståndet (ja, med undantag för markören, som på ett realistiskt sätt, inte kommer att ge olika resultat utom för exceptionella fall som i alla fall). Vad ger, Firefox?!

Firefox :funktionshindrade (överst) jämfört med normal (längst ned) och styling.

I Kanten, både gräns-färg och bakgrunden gradient är olika.

Kant :funktionshindrade styling (genom att kontrollera beräknad stilar).

Vi har följande stilar för det normala tillståndet:

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

Och för funktionshindrade status:

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

Helt klart annorlunda om vi tittar på koden och visuellt bättre än Chrome, även om det kanske ändå inte riktigt räcker till:

Avaktiverad (vänster) jämfört med aktiverad (höger) <input type=’color’> i Kanten.

:fokus

Detta är ett tillstånd som vi kan testa att växla DevTools pseudo-klasser. Jo, i teorin. I praktiken är det egentligen inte hjälper oss i alla webbläsare.

Börjar med Chrome, kan vi se att vi har en disposition i denna stat och kontur, färg beräknar att rgb(77, 144, 254), vilket är någon typ av blå.

Chrome :fokus styling.

Ganska enkelt och lätt att upptäcka.

Moving on till Firefox, saker börjar få hårig! Till skillnad från Krom, växla fokus pseudo-klass från DevTools gör ingenting på input-element, men genom att fokusera den (genom att klicka), gränsen blir blå och vi får en streckad rektangel inom — men det är ingen indikation på DevTools om vad det är som händer.

Vad händer i Firefox när du tabbar till vår ingång att :fokusera på det.

Om vi kontrollera Firefox former.css, den ger en förklaring till den streckade rektangeln. Detta är den streckade gränsen för en pseudo-element, ::-moz-fokus-inre (en pseudo-element som, av någon anledning, som inte visas i DevTools inuti vår ingång som ::-moz-färg-swatch är). Denna gräns är ursprungligen transparent och sedan blir synlig när ingången är fokuserad — pseudo-klass som används här (:-moz-focusring) är ganska mycket en gammal Firefox-version av den nya standarden (:fokus är synligt), som för närvarande stöds endast av Chrome bakom Experimentell Plattform för Webben har flaggan.

Firefox: där den inre streckade rektangeln på :fokus kommer ifrån.

Vad sägs om blå gränsen? Tja, verkar detta inte är satt av en formatmall, men på en OS-nivå istället. Den goda nyheten är att vi kan åsidosätta alla dessa stilar bör vi välja att göra så.

I Kanten, vi står inför en liknande situation. Ingenting händer när växla fokus pseudo-klass från DevTools, men om vi faktiskt fliken till vår ingång att fokusera det vi kan se en inre streckade rektangeln.

Vad händer i Kanten när du tabbar till vår ingång att :fokusera på det.

Trots att jag har inget sätt att veta säkert, jag misstänker att, precis som i Firefox, denna inre rektangel är på grund av en pseudo-element som blir synlig på :fokus.

:hover

I Chrome, växla denna pseudo-klass avslöjar inte några :hover-specifika stilar i DevTools. Dessutom, faktiskt svävar input ” inte visas att ändra något visuellt. Så det ser ut som Chrome har inte riktigt någon :hover-specifika stilar?

I Firefox, växla :hover pseudo-klass från DevTools visar en ny regel i panelen formatmallar:

Firefox :hover styling som kan ses i DevTools.

När faktiskt svävar in, ser vi att bakgrunden blir ljuset blått och gränsen blå, så den första tanken skulle vara att ljus blå -moz-buttonhoverface värde och att den blå gräns är åter inställt på en OS-nivå, precis som i :fokus fall.

Vad som egentligen händer i Firefox på :hover.

Men om vi tittar på de beräknade stilar, ser vi samma bakgrund har vi i det normala tillståndet, så att blå bakgrund är nog egentligen inställt på en OS-nivå, trots att ha som regel i olika former.css-stilmall.

Firefox: beräknade background-color av en <input type=’color’> på :hover.

I Kanten, att växla :hover pseudo-klass från DevTools ger vårt bidrag till en ljus blå (rgb(166, 244, 255)) bakgrund och blå (rgb(38, 160, 218)) gränsen, vars exakta värden som vi kan hitta i den Beräknade fliken:

Kant: beräknade background-color och border-color av en <input type=’color’> på :hover.

:aktiv

Kontrollera :aktiv stat i Chrome DevTools gör ingenting visuellt och visar inga specifika regler i panelen Formatmallar. Men om vi faktiskt klickar på vår insats, vi ser att bakgrunden lutning som inte ens visa upp i DevTools i normalt tillstånd får återkallas.

Vad det faktiska bidrag ser ut som i Chrome i :aktivt tillstånd. Det verkar ha en lutning (omvänd från det normala tillståndet), trots den information vi får från DevTools berättar det inte.

I Firefox DevTools, växla mellan den aktiva staten gör ingenting, men om vi också växla :hover state på, då får vi en regel som att förändringar inline utfyllnad (blocket utfyllnad är satt till samma värde på 0 om det har i alla andra stater), border-style och sätter background-color tillbaka till vår gamla vän ButtonFace.

Firefox :aktiv styling som kan ses i DevTools.

I praktiken däremot, det enda som stämmer överens med den information vi får från DevTools är inline-skift som ges av förändringen i logiska utfyllnad. Bakgrunden blir en ljusare blå än :hover state och den gränsen är blå. Båda dessa förändringar är förmodligen händer på en OS-nivå.

Vad som egentligen händer i Firefox i ett aktivt tillstånd.

I Kanten för att aktivera den :aktiv klass från DevTools ger oss exakt samma stil som vi har för de :hover state. Men om vi har både sväva och :aktiv på, saker och ting förändras lite. Vi har fortfarande en ljus blå bakgrund och en blå kant, men båda är mörkare nu (rgb(52, 180, 227) för background-color och rgb(0, 137, 180) för border-color):

De beräknade background-color och border-color av en <input type=’color’> på :aktiv ses i Kanten.

Detta är den take-away: om vi vill ha en konsekvent cross-browser resultat för <input type=’color’>, bör vi definiera vår egen klart urskiljbara stilar för alla dessa stater själva eftersom lyckligtvis nästan alla webbläsare defaults — med undantag för den inre rektangel vi får i Kanten på :fokus — kan åsidosättas.

Swatch omslag

Detta är en komponent som vi bara ser i Chrome, så om vi vill ha en cross-browser resultat, vi ska nog se till att det inte inverkar på swatch inne — och det innebär att det inte har någon margin, border, padding eller bakgrund och att dess mått motsvarar de faktiska ingång innehåll-rutan.

För att veta om vi behöver bråka med dessa egenskaper (och kanske andra som ett resultat) eller inte, låt oss se vad webbläsarens standardinställningar för dem.

Lyckligtvis har vi inga marginaler eller gränsen, så vi behöver inte bry dig om dessa.

Marginal och gränsvärdena för swatch omslag i Chrome.

Vi har dock en icke-noll utfyllnad (av 4px 2px), så detta är något vi behöver för att nolla ut om vi vill uppnå en konsekvent cross-browser resultat.

Stoppning värden för swatch omslag i Chrome.

Måtten är både bekvämt in till 100%, vilket innebär att vi inte behöver bråka med dem.

Storlek värden för swatch omslag i Chrome.

Något vi behöver för att notera här är att vi har en box-sizing inställd på att border-box, så att stoppningen blir subtraheras från de mått som på detta omslag.

Box-sizing värde för swatch omslag i Chrome.

Detta betyder att medan padding-box -, gräns-rutan och marginalen-box av vår wrapper (alla är lika, eftersom vi inte har någon marginal eller kant) är identiska till innehåll-box av den faktiska <input type=’color’> (som är 44pxx23px i Chrome), att få omslaget innehåll-rutan innebär att subtrahera utfyllnad från dessa mått. Det leder till att denna ruta är 40pxx15px.

Rutan modell för swatch omslag i Chrome.

Bakgrunden är genomskinliga, så det är en annan egenskap som vi inte behöver oroa dig för återställning.

Bakgrunden värden för swatch omslag i Chrome.

Det finns en mer egendom som i detta element som fångade min uppmärksamhet: displayen. Det har ett värde av flex, vilket innebär att dess barn är flex objekt.

Visa värdet för swatch omslag i Chrome.

Swatch

Detta är en komponent som vi kan stil i Chrome och Firefox. Tyvärr, Edge inte utsätta den för att tillåta oss att styla det, så att vi inte kan ändra på egenskaper som vi kanske vill, till exempel gräns, border-radius eller box-shadow.

Box-sizing egendom är något som vi måste anges explicit om vi planerar på att ge swatch en gräns eller en utfyllnad eftersom dess värde är innehåll-rutan i Chrome, men gränsen-rutan i Firefox.

Box-sizing-värden för swatch visas i Chrome (överst) och Firefox (botten).

Lyckligtvis font-size är ett arv från den input sig så att det är samma.

Font-size värden för swatch visas i Chrome (överst) och Firefox (botten).

Rörelsemarginalen beräknar att 0 i både Chrome och Firefox.

Marginalen värden för swatch visas i Chrome (överst) och Firefox (botten).

Detta beror på att de flesta marginaler har inte ställts in, så att de till slut blir 0, vilket är standard för <div> – element. Men Firefox är inställningen inline marginaler till auto och vi kommer att få till varför som beräknar till 0 på bara en liten stund.

Inline-marginalen för swatch är inställd på auto i Firefox.

Gränsen är solid 1px i båda webbläsarna. Det enda som skiljer är border-color, som är rgb(119, 119, 119) i Krom och grå (eller rgb(128, 128, 128), så något ljusare) i Firefox.

Gränsvärdena för swatch visas i Chrome (överst) och Firefox (botten).

Observera att de beräknade border bredd i Firefox (åtminstone på Windows) beror på OS-zoom-nivå, precis som det är i fallet med den faktiska bidrag.

Stoppningen är som tur är 0 i både Chrome och Firefox.

Stoppning värden för swatch visas i Chrome (överst) och Firefox (botten).

Mått hamna exakt vad vi skulle förvänta sig att hitta, om man antar swatch täcker sin förälders hela innehållet-rutan.

Rutan modell för swatch visas i Chrome (överst) och Firefox (botten).

I Chrome, swatch förälder som <div> omslaget som vi såg tidigare, vars innehåll-box är 4pxx15px. Detta är lika med den marginalsäkerhet-rutan och border-box av swatch (som sammanfaller eftersom vi inte har någon marginal). Eftersom stoppningen är 0, innehåll-rutan och padding-box för swatch är identiska, och att subtrahera 1px border får vi ett mått som är 38pxx13px.

I Firefox, swatch förälder är det faktiska bidrag, vars innehåll-box är 44pxx19px en. Detta är lika med den marginalsäkerhet-rutan och border-box av swatch (som sammanfaller eftersom vi inte har någon marginal). Eftersom stoppningen är 0, innehåll-rutan och padding-box för swatch är identiska, och att subtrahera 1px border får vi att deras dimensioner är 42pxx17px.

I Firefox ser vi att swatch är gjorda för att täcka sin förälders innehåll-box med båda sina mått till 100%.

Storlek värden för swatch visas i Chrome (överst) och Firefox (botten).

Detta är anledningen till att auto värde för inline beräknar marginal till 0.

Men vad om Chrome? Vi kan inte se några verkliga mått är inställt. Tja, detta resultat är på grund av flex layout och det faktum att swatch är en flex objekt som är gjort för att stretcha så att det täcker sin förälders innehåll-rutan.

Flex värde för swatch omslag i Chrome.

Slutliga tankar

Puh, vi täckt en hel del av marken här! Medan det kan tyckas vara uttömmande för att gräva här djupt in en viss del, detta är den typ av motion som illustrerar hur svårt cross-browser stödja kan vara. Vi har våra egna stilar, user agent stilar och operativsystem stilar för att korsa och några av dem kommer alltid att vara vad de är. Men, som vi diskuterade i toppen, detta vindar upp som en fråga tillgängligheten i slutet av dagen, och något att verkligen tänka på när det gäller att genomföra en praktisk, funktionell ansökan av en färg ingång.

Kom ihåg, en hel del av detta är mogna territorium för att nå ut till leverantörer av webbläsare och låt dem veta hur de kan uppdatera sina implementationer baserat på din rapporterade användningen fall. Här är de tre biljetter som jag nämnde tidigare där du antingen kan klämta i eller referens för att skapa en ny biljett:

  • WebKit (Fel #194756)
  • Mozilla (Fel #1526820)
  • Pre-Krom Kant (Fråga #57, stängt)