Farge Innganger: Et Dypdykk i Kryss-Nettleser Forskjeller

0
40

I denne artikkelen vil vi ta en titt på strukturen i <input type= “color” > – elementer, nettleser inkonsekvenser, hvorfor de ser på en bestemt måte i en bestemt nettleser, og hvordan å grave i det. Å ha en god forståelse av dette input gjør det mulig for oss å evaluere om en viss kryss-nettleser utseende kan oppnås, og hvordan du kan gjøre det med et minimum av innsats og kode.

Her er akkurat hva vi snakker om:

Men før vi dykke inn i dette, vi trenger for å komme inn…

Tilgjengelighet spørsmål!

Vi har et stort problem her: for de som er helt avhengige av et tastatur, denne inngangen ikke fungerer som det skal i Safari og Firefox på Windows, men det fungerer i Firefox på Mac og Linux (som jeg bare testet på Fedora, så føl deg fri til å kjefte på meg i kommentarfeltet hvis det ikke fungerer for deg ved hjelp av en annen fordeling).

I Firefox på Windows, vi kan Fanen for å inngang til å fokusere den, trykker du på Enter for å få opp en dialogboks… som vi da ikke kan navigere med tastaturet!

Jeg har prøvd tabbe, pil-tastene, og hver av de andre tastene er tilgjengelige på tastaturet… ingenting! Jeg kunne minst lukke dialogboksen med gode gamle Alt + F4. Senere, i feil billett jeg fant for dette på Bugzilla, jeg har også oppdaget en løsning: Alt + Tab til et annet vindu, og Alt + Tab tilbake og velgeren dialog kan navigere med tastaturet.

Ting blir enda verre i Safari. Inngangen er ikke engang fokuserbart (bug billett) hvis VoiceOver er ikke på. Og selv når du bruker VoiceOver, tabbe gjennom dialog innganger åpnes er umulig.

Hvis du ønsker å bruke <input type=’color’> på selve nettsiden, vennligst gi lesere vet at dette er noe som trenger å bli løst!

Hvordan til å se inni

I Chrome, må vi ta opp DevTools, gå til Innstillinger og, i Innstillinger – delen under Elementer, sjekk Vis user agent skygge DOM alternativ.

Hvordan å vise strukturen inne i en inngang i Chrome.

Så, når vi kommer tilbake for å inspisere våre element, kan vi se inne i sin skygge DOM.

I Firefox, må vi gå til ” about:config og sikre devtools.inspektør.showAllAnonymousContent flagget er satt til true.

Hvordan å vise strukturen inne i en inngang i Firefox.

Så, vi lukker DevTools og, når vi inspisere våre innspill igjen, vi kan se på innsiden av våre innspill.

Dessverre, vi synes ikke å ha et alternativ for dette i pre-Krom Kanten.

Strukturen inne

Strukturen er åpenbart i DevTools forskjellig fra nettleser til nettleser, akkurat som det gjør for spekter-innganger.

I Chrome, på toppen av skyggen DOM, vi har et <div> – wrapper som vi kan få tilgang til ved å bruke ::-webkit-farge-swatch-wrapper.

Inne i det, har vi en annen <div> vi kan få tilgang til via ::-webkit-farge-fargekartet.

Indre strukturen i Chrome.

I Firefox, kan vi bare se en <div>, men det er ikke merket på noen måte, så hvordan får vi til det?

På en anelse, gitt denne <div> har background-color satt til input-verdi-attributtet, akkurat som ::-webkit-farge-swatch komponent, jeg prøvde ::-moz-farge-fargekartet. Og det viser seg at det fungerer!

Indre strukturen i Firefox.

Men senere fikk jeg vite at vi har en bedre måte å finne dette ut for Firefox!

Vi kan gå inn i Firefox DevTools Innstillinger og, i Inspektøren delen, pass på at “Vis Nettleser Stiler” er merket av for alternativet. Deretter går vi tilbake til Inspektør og velg denne <div> i vår <input type=’color’>. Blant user agent stiler, ser vi et regelsett for input[type=’color’]::-moz-farge-swatch!

Aktivere visning nettleser stiler i Firefox DevTools.

I pre-Krom Kant, vi kan ikke engang se hva slags struktur vi har inne. Jeg ga ::-ms-farge-swatch en prøve, men det fungerte ikke, og det gjorde heller ikke ::-ms-swatch (som jeg betraktet fordi, for en input type=’utvalg’, vi har ::-webkit-slider-tommel og ::-moz-området tommelen, men kun ::-ms-tommelen).

Etter mye søking, alt jeg fant var dette problemet fra 2016. Pre-Krom Kanten tilsynelatende ikke tillate oss å style hva er inni denne inngangen. Vel, det er en bummer.

Hvordan man ser på nettleseren stiler

I alle nettlesere, har vi muligheten til ikke å bruke noen stiler av våre egne, og deretter se på de beregnede stiler.

I Chrome og Firefox, kan vi også se user agent “stylesheet” regelsett som påvirker den valgte elementet (selv om vi eksplisitt trenger å aktivere dette i Firefox, som vi har sett i forrige avsnitt).

Kontrollere nettleseren stiler i Chrome og Firefox.

Dette er ofte mer nyttig enn den beregnede stiler, men det finnes unntak, og vi bør likevel alltid sjekk den beregnede verdier som godt.

I Firefox, kan vi også se CSS-filen for form-elementer på vis-kilde:resource://gre-ressurser/former.css.

Kontrollere nettleseren stiler i Firefox.

Input-elementet i seg selv

Vi vil nå ta en titt på standard verdier av noen egenskaper i ulike nettlesere for å få et klart bilde av hva vi hadde virkelig trenger å sette eksplisitt for å få en tilpasset kryss-nettleser resultat.

Den første egenskapen jeg tenker alltid å sjekke når det kommer til <input> – elementer er safe-dimensjonering. Den første verdien for denne egenskapen border-box i Firefox, men innhold-boksen i Chrome og Edge.

Boksen-dimensjonering verdier for <input type= “color” > forhold i Chrome, Firefox og Edge (fra topp-til-bunn).

Vi kan se at Firefox er å sette den til border-box på <input type=’color’>, men det ser ut som Chrome er ikke sette det i det hele tatt, så det er venstre med den opprinnelige verdien av innhold-boksen (og jeg mistenker at det samme er sant for Kant).

I alle tilfelle, hva dette betyr er at hvis vi skal ha en ramme eller en padding på dette elementet, må vi også eksplisitt safe-dimensjonering, slik at vi får et jevnt resultat på tvers av alle disse nettleserne.

Skriften eiendommens verdi er forskjellig for hver nettleser, men siden vi ikke har teksten i dette inngang, alle vi virkelig bryr seg om er font-størrelse, noe som er konsistent på tvers av alle nettlesere jeg har sjekket: 13.33(33)px. Dette er en verdi som virkelig ser ut som det kom fra å dele 40px av 3, minst i Chrome.

Skriften verdier for <input type= “color” > forhold i Chrome, Firefox og Edge (fra topp-til-bunn).

Dette er en situasjon der den beregnede stiler er mer nyttig for Firefox, fordi hvis vi ser på nettleseren stiler, får vi ikke mye i form av nyttig informasjon:

Noen ganger nettleseren stiler er ganske mye unyttig (Firefox skjermbilde).

Marginen er også konsekvent på tvers av alle disse nettleserne, databehandling til 0.

Marginen verdier for <input type= “color” > forhold i Chrome, Firefox og Edge (fra topp-til-bunn).

Grensen er forskjellig for hver enkelt nettleser. I både Chrome og Kant, vi har en solid 1px en, men grensen-en annen farge (rgb(169, 169, 169) for Chrome og rgb(112, 112, 112) til Kant). I Firefox, grensen er en begynnelsen 2px ett, med en kant-farge av… ThreeDLightShadow?!

Grensen verdier for <input type= “color” > forhold i Chrome, Firefox og Edge (fra topp-til-bunn).

Hva er greia med ThreeDLightShadow? Hvis det ikke høres kjent ut, trenger du ikke å bekymre deg! Det er en (nå utdatert) CSS2-systemet verdi, som Firefox på Windows viser meg å være rgb(227, 227, 227) i den Beregnede stiler kategorien.

Beregnet border-color for <input type=’color’> i Firefox på Windows.

Merk at i Firefox (i alle fall på Windows), operativsystemet zoom-nivå (Innstillinger → System → Vis → Skalering og Layout → Endre størrelsen på tekst, apper og andre ting) som kommer til å påvirke den beregnede verdi av grensen-bredde, selv om dette ikke ser ut til å skje andre ting jeg har sjekket, og det ser ut til å være delvis knyttet til grensen-stil.

Zoom-alternativer i Windows.

De rareste ting er beregnet border-width verdier for ulike zoomnivåer, ser ikke ut til å gjøre noe fornuftig. Hvis vi holder den første border-style: begynnelsen, har vi:

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

Hvis vi setter border-style: solid, vi har en beregnet border-width av 2px, akkurat som det ble satt, for zoom verdier som er multipler av 50%, og den eksakte samme beregnede verdier som for border-style: utgangspunktet for alle de andre zoom-nivåer.

Polstringen er den samme for Chrome og Edge (1px 2px), mens Firefox er den odde en ut igjen.

Polstringen verdier for <input type= “color” > forhold i Chrome, Firefox og Edge (fra topp-til-bunn).

Det kan se ut som Firefox padding er 1px. Det er hva den er satt til, og det er ingen indikasjon på alt overordnet it — dersom en eiendom er overstyrt, da det er vist som grå og med en strek gjennom.

Spotting overstyrer i Firefox.

Men den beregnede verdi er faktisk 0 8px! Videre, dette er en verdi som ikke avhenger av operativsystemet zoom-nivå. Så, hva den hårete pokker er det som skjer?!

Beregnet verdi for polstring i Firefox, ikke stemmer overens med verdien som ble satt på innspill.

Nå, hvis du har faktisk prøvd å inspisere en farge inngang, tok en nærmere titt på stilsett på det, og hjernen din fungerer annerledes enn min (som betyr at du må lese hva som er foran deg, og ikke bare søker etter den ene tingen som interesserer deg, helt ignorerer alt annet…), så du har sikkert lagt merke til at det er noe overstyrer 1px polstring (og skal merkes som sådan) — flyt-i forhold polstring!

Strømning-i forhold polstring overstyrer i Firefox.

Dang, som kjente de egenskaper med masse bokstaver var egentlig relevant? Takk til Zoltan for å legge merke til og la meg vite. Ellers, er det sannsynligvis ville ha tatt meg to dager å finne ut dette.

Dette reiser spørsmålet om den samme slags overstyre ikke kunne skje i andre nettlesere og/eller for andre egenskaper.

Kant ikke støtter CSS-logiske egenskaper, så svaret er “nei” i det hjørnet.

I Chrome, ingen av de logiske egenskaper for margin, kantlinje eller polstring er eksplisitt angitt for <input type=’color’>, så vi har ingen overstyring.

Om andre egenskaper i Firefox, så kunne vi ha funnet oss i samme situasjon for margin eller for grensen, men med disse to, det bare så skjer flyt-relative egenskaper som ikke er eksplisitt angitt for våre innspill, så igjen, det er ikke overstyring.

Selv så, det er definitivt noe å se opp for i fremtiden!

Flytte til dimensjoner, og våre innspill er bredden er 44px i Chrome og Kanten og 64px i Firefox.

Bredde-verdier for <input type= “color” > forhold i Chrome, Firefox og Edge (fra topp-til-bunn).

Høyden er 23px i alle tre nettlesere.

Høyden verdier for <input type= “color” > forhold i Chrome, Firefox og Edge (fra topp-til-bunn).

Merk at siden Chrome og Kanten har en boks-dimensjonering av innhold-boksen, bredde og høyde og verdier som ikke inkluderer polstring eller grensen. Imidlertid, siden Firefox har safe størrelse satt til border-box, dens dimensjoner er den padding og border.

Oppsettet bokser for <input type= “color” > forhold i Chrome, Firefox og Edge (fra topp-til-bunn).

Dette betyr at innholdet-boksen er 44pxx23px i Chrome og Kanten og 44xpxx19px i Firefox, padding-boksen er 48pxx25 i Chrome og Kanten og 60pxx19px i Firefox og border-box er 50pxx27px i Chrome og Kanten og 64pxx23 i Firefox.

Vi kan tydelig se hvordan målene ble satt i Chrome, og jeg vil anta at de var i den samme direkte måte i Kanten så godt, selv om Kant ikke tillate oss å spore denne ting. Firefox viser ikke disse dimensjonene som har vært eksplisitt og ikke engang gir oss mulighet til å spore hvor de kom fra i de Beregnede kategorien (som det gjør for andre egenskaper som grensen, for eksempel). Men hvis vi ser på alle stiler som er angitt på input[type= “color”], oppdager vi den dimensjoner har blitt definert som kontantstrøm-forhold de (inline-størrelse og blokk-størrelse).

Hvordan <input type=’color’> mål har blitt satt i Firefox.

Den siste egenskapen vi kontrollerer for normal tilstand av den faktiske inndata er bakgrunnen. Her, Edge er den eneste nettleseren til å ha et bakgrunnsbilde (satt til en topp til bunn fall), mens Chrome og Firefox har begge en bakgrunn-farge satt til ButtonFace (en annen deprecated CSS2 system-verdi). Det som er merkelig er dette bør være rgb(240, 240, 240) (i henhold til denne ressursen), men den beregnede verdi i Chrome er rgb(221, 221, 221).

Bakgrunnen verdier for <input type= “color” > forhold i Chrome, Firefox og Edge (fra topp-til-bunn).

Hva som er enda merkeligere er at hvis vi faktisk se på våre innspill i Chrome, at det ser ut som det har en gradient bakgrunn! Hvis vi skjermbilde det, og deretter bruke en velger, får vi at den har en topp til bunn gradient fra #f8f8f8 til #ddd.

Hva som er de faktiske inndata ser ut som i Chrome. Det ser ut til å ha en tonet, på tross av den informasjonen vi får fra DevTools å fortelle oss er det ikke.

Vær også oppmerksom på at hvis du endrer bare background-color (eller annen eiendom som ikke er knyttet til dimensjoner som border-radius) i Kanten, endres også bakgrunnen-bilde, background-origin, kant-farge eller border-style.

Edge: side virkninger av å endre bakgrunn-farge.

Andre land

Vi kan ta en titt på hvilke stiler som brukes for en rekke andre tilstander for et element ved å klikke :hov – knappen i Maler-panelet for Chrome og Firefox og en: knappen i samme Maler-panelet for Kant. Dette avslører en seksjon hvor vi kan krysse av for ønsket tilstand(s).

Ta en titt på andre stater i Chrome, Firefox, Edge (fra øverst til nederst).

Merk at i Firefox, sjekker en klasse bare visuelt gjelder brukeren stiler på det valgte elementet, ikke nettleseren stiler. Så, hvis vi sjekker :hover for eksempel, vi vil ikke se den :hover stiler som er brukt på våre element. Vi kan imidlertid se user agent stiler å matche den valgte staten for vår valgte elementet vises i DevTools.

Også, vi kan ikke teste for alle stater som dette, og la oss starte med en slik tilstand.

:deaktivert

For å se hvordan endre stiler i denne tilstanden, vi trenger å manuelt legge til funksjonshemmede attributtet til vår <input type= “color” > – element.

Hmm… ikke mye endringer i en annen nettleser!

I Chrome, ser vi background-color er litt annerledes (rgb(235, 235, 228) i :deaktivert tilstand versus rgb(221, 221, 221) i normal tilstand).

Chrome :deaktivert styling.

Men forskjellen er bare klart å se på info i DevTools. Visuelt, kan jeg fortelle si det er en liten forskjell mellom en inngang som er :deaktivert, og en som ikke hvis de er sidestilte, men hvis jeg ikke vet på forhånd, at jeg ikke kunne se hva som er der bare ved å se på dem, og hvis jeg bare så en, kunne jeg ikke si om det er aktivert eller ikke uten å klikke på den.

Deaktivert (venstre) versus aktivert (høyre) <input type=’color’> i Chrome.

I Firefox, vi har de samme verdiene som er angitt for :deaktivert tilstand som for normal tilstand (vel, bortsett fra for markøren, som realistisk, ikke kommer til å gi ulike resultater lagre for spesielle tilfeller likevel). Hva gir, Firefox?!

Firefox :deaktivert (øverst) versus normal (nederst) styling.

I Kanten, både kant-farge og bakgrunn gradient er forskjellige.

Edge :deaktivert styling (ved å kontrollere beregnede stiler).

Vi har følgende stiler for normal tilstand:

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

Og for det :deaktivert tilstand:

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

Helt klart annerledes hvis vi ser på koden og visuelt bedre enn Chrome, selv om det likevel ikke være nok:

Deaktivert (venstre) versus aktivert (høyre) <input type=’color’> i Kanten.

:fokus

Dette er en tilstand vi kan teste ved å skifte den DevTools pseudo-klasser. Vel, i teorien. I praksis, er det egentlig ikke hjelpe oss i alle nettlesere.

Starter med Chrome, kan vi se at vi har en disposisjon i denne staten og outline-color regner ut til rgb(77, 144, 254), som er en slags blå.

Chrome :fokus styling.

Ganske grei, og lett å få øye på.

Flytte til Firefox, ting begynner å bli hårete! I motsetning til Chrome, kan du skifte den :fokus pseudo-klasse fra DevTools gjør ingenting på input-elementet, men ved å fokusere på det (av-fanen klikker), grensen blir blå og vi får en stiplede rektangelet i — men det er ingen indikasjon i DevTools om hva som skjer.

Hva skjer i Firefox når tabbe til våre innspill til :fokus på det.

Hvis vi sjekker Firefox former.css, det gir deg en forklaring for den stiplede rektangelet. Dette er den stiplede grensen av en pseudo-element, ::-moz-fokus-indre (en pseudo-element som, for noen grunn, ikke vises i DevTools inne i vårt innspill som ::-moz-farge-swatch er). Denne grensen er i utgangspunktet åpen og deretter blir synlig når input er fokusert — pseudo-klasse som er brukt her (:-moz-focusring) er ganske mye en gammel Firefox versjon av den nye standarden (:fokus-synlig), som for tiden støttes bare av Chrome bak Eksperimentelle Web-Platform-funksjoner flagg.

Firefox: der hvor den indre stiplede rektangelet på :focus kommer fra.

Hva om den blå ramme? Vel, synes dette ikke er satt av et stilark, men på en OS-nivå i stedet. Den gode nyheten er at vi kan overstyre alle disse stilene bør vi velge å gjøre det.

I Kanten, vi står overfor en lignende situasjon. Ingenting skjer når du skifte den :fokus pseudo-klasse fra DevTools, men hvis vi faktisk tab for våre innspill til fokus det, kan vi se en indre stiplede rektangelet.

Hva skjer i Kanten når tabbe til våre innspill til :fokus på det.

Selv om jeg har ingen måte å vite sikkert, jeg mistenker at, akkurat som i Firefox, dette indre rektangelet er på grunn av en pseudo-element som blir synlig på :fokus.

:hover

I Chrome, kan du veksle denne pseudo-klasse ikke avslører noen :hover-bestemte stiler i DevTools. Videre, faktisk svever input synes ikke å endre noe visuelt. Så det ser ut som Chrome egentlig ikke har noen :hover-bestemte stiler?

I Firefox, skifte den :hover pseudo-klasse fra DevTools avslører en ny regel i maler-panelet:

Firefox :hold styling sett i DevTools.

Når faktisk svever innspill, vi ser bakgrunnen blir lys blå og grensen blå, så først trodde ville være som lys blå -moz-buttonhoverface verdi og at de blå ramme er igjen satt på en OS-nivå, akkurat som i :fokus tilfelle.

Hva skjer egentlig i Firefox på :hover.

Imidlertid, hvis vi ser på de beregnede stiler, ser vi den samme bakgrunnen har vi i normal tilstand, slik at blå bakgrunn er trolig virkelig satt på en OS-nivå også, til tross for at regelen i former.css-stilark.

Firefox: beregnet bakgrunn-farge av en <input type=’color’> på :hover.

I Kanten, skifte den :hover pseudo-klasse fra DevTools gir våre innspill en lys blå (rgb(166, 244, 255)) bakgrunn og blå (rgb(38, 160, 218)) grensen, som eksakte verdier som vi kan finne i den Beregnede kategorien:

Edge: beregnet bakgrunn-farge og border-color-av en <input type=’color’> på :hover.

:aktiv

Kontrollere :aktiv stat i Chrome DevTools gjør ingenting visuelt og viser ingen spesielle regler i Maler-panelet. Imidlertid, hvis vi faktisk klikk våre innspill, ser vi at bakgrunnen gradient som ikke engang dukker opp i DevTools i normal tilstand blir reversert.

Hva som er de faktiske inndata ser ut som i Chrome-i :aktiv tilstand. Det ser ut til å ha en gradient (reversert fra normal tilstand), på tross av den informasjonen vi får fra DevTools å fortelle oss er det ikke.

I Firefox DevTools, skifte den :aktiv tilstand på gjør ingenting, men hvis vi også veksle :hover staten på, så får vi et regelsett som endrer inline polstring (blokk padding er satt til samme verdi på 0 det har i alle andre stater), grensen-stil og setter background-color tilbake til vår gamle venn ButtonFace.

Firefox :aktiv styling sett i DevTools.

I praksis, derimot, er den eneste som samsvarer med den informasjonen vi får fra DevTools er inline skift gitt av endring i logiske polstring. Bakgrunnen blir det en lysere blå enn den :hover staten og den grensen er blå. Begge disse endringene er sannsynligvis skjer på en OS-nivå.

Hva skjer egentlig i Firefox i en :aktiv tilstand.

I Kanten, aktivere den :aktiv klasse fra DevTools gir oss nøyaktig samme stiler vi har for :hover staten. Imidlertid, hvis vi har både :hover og :aktive stater på, ting endrer litt. Vi har fortsatt en lys blå bakgrunn og en blå ramme, men begge er mørkere nå (rgb(52, 180, 227) for background-color og rgb(0, 137, 180) for border-color (farge):

De beregnede bakgrunn-farge og border-color-av en <input type=’color’> på :aktiv sett i Kanten.

Dette er den take away: hvis vi ønsker en konsekvent kryss-nettleser resultater for <input type=’color’>, bør vi definere vår egen klart identifiserbare stiler for alle disse landene selv fordi, heldigvis, nesten alle nettleser-standarder — med unntak for det indre rektangelet vi får i Kanten på :fokus — kan overstyres.

Swatch wrapper

Dette er en komponent som vi bare se i Chrome, så hvis vi vil ha en kryss-nettleser resultat, bør vi trolig sikre at det ikke påvirker swatch inne — betyr dette for å sikre at den har ingen margin, border, polstring eller bakgrunnen, og at dens dimensjoner lik de av den faktiske inndata innhold-boksen.

For å vite om vi trenger å rote med disse egenskapene (og kanskje andre som et resultat) eller ikke, la oss se hva leseren standardverdier for dem.

Heldigvis, vi har ingen margin eller grensen, så vi trenger ikke å bekymre deg for dette.

Margin og grenseverdier for swatch wrapper i Chrome.

Vi har imidlertid en ikke-null polstring (av 4px 2px), så dette er noe vi trenger til null ut hvis vi ønsker å oppnå en konsistent kryss-nettleser resultat.

Polstringen verdier for swatch wrapper i Chrome.

Dimensjonene er både praktisk satt til 100%, noe som betyr at vi ikke trenger å rote med dem.

Størrelsen verdier for swatch wrapper i Chrome.

Noe vi trenger å merke seg her er at vi har safe størrelse satt til border-box, så polstringen blir trukket fra mål satt på denne wrapperen.

Boksen-dimensjonering verdi for swatch wrapper i Chrome.

Dette betyr at mens padding-boksen, border-box og margin-boksen av våre pakker (alle like, fordi vi har ingen margin eller grensen) er identisk med innholdet-boksen av faktiske <input type=’color’> (som er 44pxx23px i Chrome), og få wrapper innhold-boksen innebærer å trekke fra polstring fra disse dimensjonene. Det resulterer i at denne boksen er 40pxx15px.

Boksen modell for swatch wrapper i Chrome.

Bakgrunnen er satt til gjennomsiktig, så det er en annen eiendel vi ikke trenger å bekymre deg for å tilbakestille.

Bakgrunnen verdier for swatch wrapper i Chrome.

Det er en mer eiendom beliggende på dette element som fanget min oppmerksomhet: – skjerm. Det har en verdi av flex, noe som betyr at barn er flex elementer.

Displayet verdi for swatch wrapper i Chrome.

Swatch

Dette er en komponent som vi kan stil i Chrome og Firefox. Dessverre, Edge, ikke utsett det til å tillate oss å style det, så vi kan ikke endre egenskapene vi ønsker kanskje å, for eksempel grensen, border-radius eller box-shadow.

Boksen-dimensjonering eiendom er en vi trenger å sette eksplisitt hvis vi har tenkt på å gi swatch en ramme eller en padding fordi dens verdi er innholdet-boksen i Chrome, men grensen-boksen i Firefox.

Boksen-dimensjonering verdier for swatch sett i Chrome (øverst) og Firefox (nederst).

Heldigvis, font-size er arvet fra input seg selv, så det er det samme.

Font-size-verdier for swatch sett i Chrome (øverst) og Firefox (nederst).

Marginen regner ut til 0 i både Chrome og Firefox.

Marginen verdier for swatch sett i Chrome (øverst) og Firefox (nederst).

Dette er fordi de fleste marginene har ikke vært sett, så ender de opp med å bli 0 som er standard for <div> – elementer. Men Firefox er å sette inline marginer til auto, og vi skal komme til hvorfor det regner ut til 0 på bare et lite øyeblikk.

Inline-margin for swatch blir satt til auto i Firefox.

Grensen er 1px solid i begge nettlesere. Det eneste som er forskjellig er border-color, som er rgb(119, 119, 119) i Chrome og grå (eller rgb(128, 128, 128), så litt lysere) i Firefox.

Grensen verdier for swatch sett i Chrome (øverst) og Firefox (nederst).

Vær oppmerksom på at den beregnede border-width i Firefox (i alle fall på Windows) avhenger av OS zoom-nivå, akkurat som det er i tilfelle den faktiske inndata.

Polstringen er heldigvis 0 i både Chrome og Firefox.

Polstringen verdier for swatch sett i Chrome (øverst) og Firefox (nederst).

Dimensjoner ende opp med å bli akkurat hva vi ville forvente å finne, forutsatt swatch dekker sine foreldre hele innholdet-boksen.

Boksen modell for swatch sett i Chrome (øverst) og Firefox (nederst).

I Chrome, swatch forelder er <div> wrapper vi så tidligere, hvis innhold-boksen er 4pxx15px. Dette er lik margin-boksen og border-box i fargekartet (som er sammenfallende så vi har ingen margin). Siden polstring er 0, – innhold-boksen og padding-boksen for swatch er identiske, og trekke fra 1px grensen, får vi mål som er 38pxx13px.

I Firefox, swatch forelder er den faktiske inndata, hvis innhold-boksen er 44pxx19px en. Dette er lik margin-boksen og border-box i fargekartet (som er sammenfallende så vi har ingen margin). Siden polstring er 0, – innhold-boksen og padding-boksen for swatch er identiske, og trekke fra 1px grensen, får vi at deres mål er 42pxx17px.

I Firefox ser vi at swatch er gjort for å dekke sine foreldres innhold-boksen ved å ha begge sine dimensjoner er satt til 100%.

Størrelsen verdier for swatch sett i Chrome (øverst) og Firefox (nederst).

Dette er grunnen til at auto verdi for innebygde margin regner ut til 0.

Men hva om Chrome? Vi kan ikke se noen faktiske mål som settes. Vel, dette resultatet er grunn til flex layout og det faktum at swatch er en flex-element som er laget for å strekke slik at det dekker sine foreldres innhold-boksen.

Flex-verdi for swatch wrapper i Chrome.

Avsluttende tanker

Puh, vi dekket mye av bakken her! Mens det kan virke utfyllende grave dette dypt inn i ett bestemt element, dette er den form for trening som illustrerer hvor vanskelig kryss-nettleser støtte kan være. Vi har våre egne stiler, user agent stiler og operativsystem stiler til å komme seg gjennom, og noen av dem er alltid kommer til å være det de er. Men, som vi diskuterte på toppen, denne vinden opp med å bli en tilgjengelighet problemet på slutten av dagen, og noe å virkelig vurdere når det kommer til å implementere en praktisk, funksjonell anvendelse av en farge-inngang.

Husk at mye av dette er moden territorium for å nå ut til nettleseren leverandører og la dem få vite hvordan de kan oppdatere sine implementasjoner basert på rapporterte tilfeller. Her er tre billetter som jeg nevnte tidligere hvor kan du enten ringe inn eller referanse for å opprette en ny billett:

  • WebKit (Bug #194756)
  • Mozilla (Bug #1526820)
  • Pre-Krom Kant (Issue #57, stengt)