Cross-browser: overal hetzelfde, ook op de telefoon van je klant
Je hebt je website opgeleverd en op je eigen laptop ziet alles er perfect uit. Dan belt een klant. Bij hem staat het menu over de tekst heen. Of een knop is onzichtbaar geworden. Jij ziet niets vreemds, want jij kijkt in een andere browser.
Dit is het klassieke weergaveverschillen. Het gebeurt niet omdat iemand slecht werk levert. Het gebeurt omdat browsers dezelfde code net anders uitvoeren.
Bij Sander Douma Architects kwam dit naar boven. Ik verzorgde het webdesign en de vindbaarheid voor hun velodroomproject. Op een architectenbureau werkt vrijwel iedereen op een Mac, dus met Safari.
Een aantal onderdelen van de opmaak werkte daar net anders. Beeldverhoudingen sprongen en een blok viel op een verkeerde plek. Ik heb die stukken herschreven naar een aanpak die alle browsers gelijk uitvoeren. Sindsdien ziet de klant hetzelfde als ik.
Dezelfde pagina, andere browser. Kleine verschillen worden snel groot.
Wat betekent cross-browser?
Cross-browser betekent dat je website in elke gangbare browser goed werkt. Niet pixel voor pixel identiek, maar wel bruikbaar en herkenbaar. Dat onderscheid is belangrijk.
Streven naar exact hetzelfde is verspilde moeite. Streven naar geen kapotte onderdelen is noodzaak. Meer over het programma zelf lees je bij browser.
Waarom er verschillen zijn
Elke browser heeft een eigen motor die je code omzet naar beeld. Chrome en Edge delen dezelfde motor. Safari gebruikt een andere, Firefox weer een andere.
Die motoren volgen dezelfde webstandaarden, maar niet altijd op hetzelfde moment. Een nieuwe mogelijkheid zit soms een jaar eerder in de een dan in de ander.
Waar het meestal misgaat
Nieuwe opmaakmogelijkheden
De meeste browsercompatibiliteit ontstaan bij recente onderdelen van CSS. Wie meteen het nieuwste gebruikt, loopt tegen verschillen aan.
Lettertypen en afstanden
Browsers renderen tekst net iets anders. Een knop die precies past, valt in een andere browser over twee regels. Laat daarom altijd wat ruimte over.
Formulieren
Datumvelden en keuzelijsten zien er per systeem anders uit. Op iOS krijg je een heel ander element dan op Windows. Dat is normaal en dat moet je accepteren.
Video en audio
Automatisch afspelen werkt niet overal hetzelfde. Safari blokkeert geluid standaard. Bouw daar dus geen functie omheen.
Welke browsers test ik?
Niet allemaal, dat is niet te doen. Ik kijk naar de statistieken van de klant zelf. Daarin zie je welke browsers je bezoekers echt gebruiken.
Mijn standaardrondje
Chrome op Windows, want dat is meestal de grootste groep.
Safari op iPhone, want daar zitten de meeste mobiele bezoekers.
Safari op Mac, vooral bij creatieve en zakelijke doelgroepen.
Firefox, kort, want die wijkt soms af bij formulieren.
Edge, alleen bij klanten met veel zakelijk verkeer.
Dat rondje kost me een half uur per sjabloon. Het scheelt maanden aan losse meldingen achteraf.
Testen zonder een kast vol apparaten
Je hoeft niet elk toestel te bezitten. testen op apparaten kan grotendeels op afstand.
De ontwikkelaarstools in je eigen browser hebben een weergavestand voor telefoons en tablets. Daarmee vang je de meeste problemen met opmaak en breakpoint al af.
Voor echte browserverschillen gebruik ik een testdienst. Die draait je site in een echte Safari of Firefox in de cloud. Dat is betrouwbaarder dan een nagebootste weergave.
Hoe ver ga je terug?
oudere browsers ondersteunen kost onevenredig veel tijd. Ik kijk daarom weer naar de cijfers. Gebruikt minder dan een procent een oude versie? Dan bouw ik daar geen maatwerk voor.
Wel zorg ik dat de site dan nog leesbaar blijft. Geen kapotte pagina, maar een eenvoudiger weergave. Dat sluit aan bij hoe ik accessibility aanpak.
In WordPress ontstaan verschillen ook door plugins. Een slecht gebouwde slider werkt in Chrome en hapert in Safari. Ik test daarom na elke update opnieuw, als vast onderdeel van onderhoud.
Wat het je oplevert
Een bezoeker die een kapotte pagina ziet, komt zelden terug. Hij meldt het ook niet, hij gaat gewoon weg. Dat zie je alleen terug als een stille daling in je aanvragen.
Testen in meerdere browsers is daarom geen luxe. Het is de goedkoopste verzekering tegen omzet die je nooit hebt zien binnenkomen. Een half uur werk per sjabloon is alles wat het kost.
Meer vragen over Cross-browser
Dit zijn de vragen die ik hierover het vaakst krijg. Ik werk ze los uit.
Wat betekent cross-browser?
Waarom ziet mijn site er anders uit in Safari?
Welke browsers moet je testen?
Hoe test je zonder alle apparaten te bezitten?
Moet ik oude browsers nog ondersteunen?
Wie is verantwoordelijk voor browserfouten?
Wat betekent cross-browser?
Omdat Safari een andere motor gebruikt dan Chrome. Die motor loopt bij nieuwe opmaakmogelijkheden vaak wat achter.
De meeste verschillen ontstaan in recente onderdelen van CSS. Wie meteen het allernieuwste gebruikt, loopt daar het eerst tegenaan. Ik houd daarom bewust een paar maanden afstand van net verschenen technieken.
Een tweede oorzaak zijn lettertypen. Browsers renderen tekst net iets anders. Een knop die in Chrome precies past, valt in Safari over twee regels. Laat daarom altijd wat ruimte over in je ontwerp.
Een derde zijn formulieren. Datumvelden en keuzelijsten zien er op een iPhone heel anders uit dan op Windows. Dat is normaal gedrag en dat moet je accepteren.
En een vierde is automatisch afspelende video. Safari blokkeert geluid standaard, dus bouw daar geen functie omheen.
Vraag je klant om een schermafbeelding met de browserversie erbij. Dat scheelt vaak een half uur zoeken naar iets dat bij jou gewoon goed staat.
Waarom ziet mijn site er anders uit in Safari?
Cross-browser betekent dat je website in elke gangbare browser goed werkt. Niet pixel voor pixel identiek, maar wel bruikbaar en herkenbaar.
Dat onderscheid is belangrijker dan het lijkt. Streven naar exact hetzelfde beeld is verspilde moeite en dure moeite. Streven naar geen kapotte onderdelen is gewoon noodzaak.
De verschillen ontstaan omdat elke browser een eigen motor heeft. Die motor zet jouw code om naar wat je op het scherm ziet. Chrome en Edge delen dezelfde motor, Safari gebruikt een andere en Firefox weer een andere.
Allemaal volgen ze dezelfde afspraken over hoe het hoort. Alleen niet op hetzelfde moment. Een nieuwe mogelijkheid zit soms een jaar eerder in de een dan in de ander.
Daarom test ik altijd in meerdere browsers voordat iets live gaat. Meer over het programma zelf lees je bij browser.
Spreek vooraf af welke browsers je ondersteunt en leg dat vast. Zonder die afspraak wordt elke melding een discussie over wie er iets fout deed.
Welke browsers moet je testen?
Niet allemaal, want dat is niet te doen. Ik kijk naar de statistieken van de klant zelf. Daarin zie je welke browsers jouw bezoekers echt gebruiken.
Mijn standaardrondje bestaat uit vijf. Chrome op Windows, want dat is meestal de grootste groep. Safari op iPhone, want daar zit het grootste deel van je mobiele bezoek.
Daarnaast Safari op een Mac, vooral bij creatieve en zakelijke doelgroepen. Firefox kort, want die wijkt soms af bij formulieren. En Edge alleen bij klanten met veel zakelijk verkeer.
Dat rondje kost me ongeveer een half uur per sjabloon. Dus niet per pagina, maar per soort pagina.
Dat halve uur scheelt maanden aan losse meldingen achteraf. Een klant die belt over een kapotte knop kost altijd meer tijd dan het vooraf testen. Kijk ook naar je breakpoint instellingen.
Test per sjabloon en niet per pagina. Je homepage, een dienstenpagina, een blogartikel en het contactformulier dekken samen bijna je hele site af.
Hoe test je zonder alle apparaten te bezitten?
Je hoeft geen kast vol telefoons te kopen. Het meeste kan gewoon vanaf je eigen werkplek.
Begin met de ontwikkelaarstools in je eigen browser. Die hebben een weergavestand voor telefoons en tablets. Daarmee vang je de meeste problemen met opmaak en schermbreedtes al af.
Die stand bootst wel na, dus hij is niet perfect. Hij toont je Chrome in een klein venster, niet een echte iPhone.
Voor echte browserverschillen gebruik ik daarom een testdienst. Die draait je site in een echte Safari of Firefox in de cloud. Je krijgt een scherm te zien alsof je erachter zit.
Daarnaast vraag ik klanten regelmatig om even mee te kijken. Zij hebben apparaten die ik niet heb. Een screenshot uit hun mail is vaak genoeg om het probleem te herkennen.
Zet een vaste testronde in je oplevercheck. Zo hoef je er niet elke keer over na te denken en wordt het geen sluitpost bij tijdsdruk.
Moet ik oude browsers nog ondersteunen?
Meestal niet met maatwerk. Oude versies ondersteunen kost onevenredig veel tijd en levert weinig op.
Ik kijk daarvoor weer naar de cijfers van de site zelf. Gebruikt minder dan een procent van je bezoekers een verouderde versie, dan bouw ik daar geen aparte oplossing voor.
Maar er is een belangrijke nuance. Niet ondersteunen betekent niet dat de site stuk mag zijn. Die bezoeker moet nog steeds je tekst kunnen lezen en je nummer kunnen bellen.
Ik zorg daarom voor een eenvoudiger weergave in plaats van een kapotte pagina. Minder animatie, een simpelere indeling, maar wel volledig bruikbaar.
Dat sluit aan bij hoe ik accessibility aanpak. De basis moet overal werken, de mooie afwerking mag afhangen van wat de browser aankan.
Kijk elk jaar opnieuw naar die cijfers. Browsergebruik verschuift sneller dan je denkt, zeker als je doelgroep verandert of ouder wordt. Zet dat moment vast in je jaarplanning, dan blijft het ook echt gebeuren.
Krijg je meldingen dat je site er bij anderen anders uitziet? Stuur me je website via het formulier hieronder, met de browser erbij die je klant gebruikt. Ik draai je pagina door mijn testrondje en meld wat er precies misgaat. Vaak is het met een paar regels op te lossen. Vermeld je plaats, dan weet ik met wie ik te maken heb.
Waar kan ik je mee helpen?
Ook bekend als: Browsercompatibiliteit, cross-browser compatibility, browseronafhankelijk
