De volgorde van filters verandert het resultaat

filter is een pijplijn, geen lijst met opties. Elke functie krijgt de pixels die de vorige opleverde, dus grayscale(1) sepia(1) eindigt sepia en sepia(1) grayscale(1) eindigt grijs: in de eerste haalt grayscale de kleur eruit en kleurt sepia wat overblijft, in de tweede kleurt sepia eerst en haalt grayscale het er meteen weer uit. Bijna elke filtergenerator zet de volgorde vast en verbergt dit, en daarom is de lijst hierboven te herordenen en zijn de pijltjes de nuttigste knop op de pagina.

Hetzelfde geldt voor het duo waar mensen het vaakst naar grijpen: brightness() voor contrast() tilt het hele beeld op en rekt het daarna rond het nieuwe midden uit, terwijl contrast() eerst rond het oorspronkelijke midden uitrekt en daarna optilt, wat de lichte partijen eerder afkapt. Geen van beide is fout. Het zijn andere bewerkingen.

De grenzen zijn die van de specificatie, niet van ons

grayscale(), sepia(), invert() en opacity() zijn begrensd op 0 en 100%, want voorbij vol hebben ze geen betekenis. brightness(), contrast() en saturate() niet: alles vanaf 0 omhoog is toegestaan, en voorbij 100% gaan is precies waarom je ze gebruikt. saturate(300%) is een geldige, nuttige, stevige bewerking. hue-rotate() neemt elke hoek en loopt rond, dus 380deg en 20deg zijn dezelfde rotatie.

Een functie die op de waarde staat waar hij niets doet, valt helemaal uit de uitvoer weg. Daarom leveren een stap uitzetten en hem op zijn neutrale waarde zetten dezelfde CSS op, en daarom staat er in de gekopieerde declaratie nooit saturate(100%).

filter en backdrop-filter zijn verschillende properties

filter bewerkt het element en alles erin. backdrop-filter bewerkt wat erachter getekend is en laat de eigen inhoud van het element scherp, en dat is het hele matglaseffect. Twee dingen bijten hier: het element heeft een deels doorzichtige achtergrond nodig, anders valt er niets doorheen te zien, en Safari vraagt nog steeds -webkit-backdrop-filter naast de standaardproperty. Allebei de regels staan in de uitvoer hierboven als de schakelaar aanstaat.

Veelvoorkomende problemen

De blur heeft een zachte, vervaagde rand.blur() bemonstert transparante pixels van buiten het element, dus de rand vervaagt. Zet de blur op een kind met overflow: hidden op de ouder, en schaal het kind net iets voorbij zijn vak.
Een kind met vaste positie is niet meer vast. Elk filter behalve none maakt een containing block voor nakomelingen, net als een transformatie, dus position: fixed daarbinnen haakt zich in plaats daarvan aan het gefilterde element vast.
drop-shadow ziet er hetzelfde uit als box-shadow. Op een rechthoek is dat ook zo. drop-shadow() volgt het alfakanaal, dus op een transparante PNG of een SVG-icoon trekt hij de tekening na en trekt box-shadow het vak na. Hij kost meer om te tekenen, en hij neemt geen spread.
Scrollen hapert. Een filter tekent opnieuw in elk frame waarin het samengesteld wordt. Een grote geblurde backdrop-filter over een scrollende lijst is de gebruikelijke boosdoener; verklein de blurstraal of het gefilterde vlak, niet de framerate.

Veelgestelde vragen

Wordt mijn afbeelding geüpload?

Nee, en hij wordt niet eens gelezen. Het bestand wordt een object-URL, en dat is een verwijzing die de browser lokaal oplost, dus er wordt niets gedecodeerd, opnieuw gecodeerd of verstuurd. Daarom verschijnt een grote foto ook meteen, en daarom laat de link die je kopieert de voorbeeldscène zien in plaats van jouw foto: een object-URL betekent buiten dit tabblad niets.

Waarom levert de tool een gewone declaratie voor Tailwind?

De filterutilities van Tailwind worden samengesteld uit aparte custom properties in een vaste volgorde, dus de volgorde die je hier zet zou dat niet overleven. De vorm met een arbitraire property, [filter:…], is één declaratie en houdt de pijplijn precies zoals getoond.

Kan ik maar een deel van een element filteren?

Niet met deze property. Gebruik een pseudo-element of een kind dat het gebied bedekt, filter dat, en knip het af. Voor alles met een vorm is filter: url(#id) dat naar een inline SVG-filter wijst de volledige versie van dezelfde functie.

Zijn deze filters kleurbeheerd?

Ze werken standaard in sRGB, en daarom kan een stevige saturate() op een afbeelding met een breed gamut er anders uitzien dan dezelfde bewerking in een fotobewerker. De SVG-filterequivalenten laten je linearRGB kiezen, en het verschil is het duidelijkst in blurs en in alles wat de lichte partijen raakt.