Apple, Google, Microsoft en Mozilla werken samen aan browserinteroperabiliteit

Apple, Google, Microsoft en Mozilla introduceren Interop 2022, een testsuite om de interoperabiliteit van browsers te verbeteren. Het uiteindelijke doel is dat pagina's en webapps er in alle browsers hetzelfde uitzien.

Interop 2022 is een benchmark waar afgevaardigden van Apples WebKit, Google, Microsoft en Mozilla aan hebben meegewerkt. Daarnaast zijn de softwareconsultancybureaus Bocoup en Igalia betrokken. De testsuite richt zich op zogenoemde focus areas, testen die aangeven of webstandaarden consistent geïmplementeerd zijn bij browsers. In totaal zijn er vijftien van zulke testonderdelen, waarvan er vijf zijn overgenomen van een eerder initiatief van Google en Microsoft.

De bedrijven hebben met feedback van webontwikkelaars in kaart gebracht welke interoperabiliteitsproblemen er speelden. Die feedback is gebaseerd op onder andere onderzoeken van MDN’s Web DNA Report en bugrapporten, via onder meer webcompat.com. Daar bleek ook uit dat sommige problemen voortkomen uit het feit dat er geen standaard is of dat standaarden onduidelijk zijn.

De makers van Interop 2022 hebben deze onderdelen aangewezen als investigate areas, als teken dat verder onderzoek van de gezamenlijke partijen nodig is om deze problemen op te lossen. Het gaat hierbij om drie segmenten. Elke focus area telt bij succesvol doorlopen van de test mee voor 6 procent voor een totaal van 90 procent, de resterende 10 procent in de totale score komt van de investigate-testonderdelen. De test geeft scores voor stabiele en experimentele releases van browsers en het dashboard van de tool toont de progressie die browsers in de loop van het jaar maken.

Interop 2022 - Focus Areas	Interop 2022/Compat 2021 - Focus Areas	Interop 2022 - Investigate areas
Cascade Layers	Aspect Ratio	Editing, contentEditable, and execCommand
Color Spaces and Functions	Flexbox	Pointer and Mouse Events
Containment	Grid	Viewport Measurement
Dialog Element	Sticky Positioning
Forms	Transforms
Scrolling
Subgrid
Typography and Encodings
Viewport Units
Web Compat

Reacties (61)

[janbaarda]

Wat ik mis is de betrokkenheid van de clubs die over webstandaarden gaan:

• W3C (HTML, CSS, XML, HTTP en DOM)
• IETF (MIME)
• ISO (HTML)
• ECMA (javascript)

Lijkt er op of deze club eigen standaarden wil. Hopelijk zijn de webstandaard organisaties via Mozilla vertegenwoordigd.

[RobinR]

Nu mag jij eens raden welke 4 grote partijen betrokken zijn bij elk van deze standaarden

[beerse]

De genoemde partijen: W3C, IETF, ISO en ECMA

Of bedoel je dat deze vrije standard-beschrijvende organisaties allemaal naar de pijpen van apple, microsoft, google en mozilla dansen? Dan heb je het mis, dat zijn effectief maar 2 organisaties die de standaarden implementeren: Google en Mozilla. Waarbij google qua lobby kracht dus 3 keer zo veel stem heeft als Mozilla.

[Reactie gewijzigd door beerse op 23 juli 2024 20:23]

[CivLord]

Het gaat niet over het invoeren van nieuwe standaarden. Het gaat om de implementatie van vastgestelde standaarden.

Google heeft de neiging om een eigen interpretatie van een standaard (of uitbreiding daarop) alvast in Chrome te implementeren, wanneer in de organisaties die over die standaarden gaan nog gesproken wordt hoe die implementatie plaats moet gaan vinden. Vaal verschilt de Google implementatie dus iets van de officiële standaard.
Dan moet je als browser-maker dus beslissen of je je aan de officiële standaard houdt, of aan de Google implementatie daarvan. Als website-developer moet je beslissen of je aan de Google implementatie voldoet en daarmee de beste prestatie neerzet voor het grootste deel van de gebruikers, of dat je de officiële standaard volgt, die mogelijk voor op Chrome gebaseerde browsers niet optimaal werkt. Of dat je beide implementaties volgt en elke bezoeker de juiste implementatie voorschotelt, maar dat levert weer extra werk op.

Je ziet het ook in de testresultaten terug. Firefox scoort het beste, omdat die de officiële standaarden het beste volgt. Maar de beste browse ervaring heb je met Chrome/ Edge/ andere op chromium gebaseerde browsers, omdat de meeste sites eoptimaliseerd zijn voor de Google implementatie.

Wil dit werken moet óf Google zich inbinden en zich aan de afgesproken standaarden houden, óf de andere browserbouwers moeten zich de implementatie door Google laten dicteren. Ik zie weinig kans in beiden. Het zal hooguit een beetje geven en nemen worden in de marge.

[mOrPhie]

Dan vergeet je nog WHATWG die basically het beheer over de HTML5 standaard overnam van W3C.

[watercoolertje]

Ik zie nergens terug dat deze instantie standaarden gaat maken, adhv welke tekst denk jij dat precies, misschien lees ik er overheen.

[watercoolertje]

Ik denk dat Apple Google Microsoft en Mozilla wel weten wat ze doen. Indien niet kunnen ze nog altijd bij jou terecht.

Hoe staat dat in relatie met de vraag die ik aan iemand hier stel waar hij bepaalde info vandaan heeft die ik zelf niet in het artikel terug kan vinden?

[aldieaccounts]

Ik denk ook dat Apple en Microsoft weten wat ze doen.

Maar wat ze doen in het algemeen belang is waag ik te betwijfelen. :-D

[Aaargh!]

Waarom niet gewoon samen 1 open-source HTML render engine ontwikkelen ? Zeker als ze toch allemaal uiteindelijk hetzelfde resultaat moeten opleveren, wat is dan de toevoegde waarde van het werk 4 keer doen ?

[usr101]

Waarom zou je dat willen? We hebben vandaag er al zo weinig in vergelijking met 10 jaar terug.
Ik ben juist daarom blij dat naast Blink en WebKit er nog Mozilla is.

[memphis]

Waarom zijn die verschillen onstaan ondanks HTML standaarden die er in de jaren 90 al waren?

[Frame164]

Geen enkele standaard is 100% zwart wit. Ik heb al over heel veel RFC's discussies gehad met mijn klanten (als de andere kant het net iets anders doet) en na grondige analyse moet iedereen concluderen dat eigenlijk beide partijen een punt hebben. Het werkt alleen niet. En dan is het zaak om tot elkaar te komen. Dit consortium probeert nu dr grijze gebieden in de standaarden glad te strijken zodat het overal hetzelfde werkt.

[latka]

Omdat je met het volgen van een standaard geen marktaandeel kan winnen en behouden. Embrace-extend-extuingish was, zeker in de jaren 90, een veel gehoorde kreet: implementeer X voeg feature Y toe (liefst iets wat je met patenten dicht kan zetten of alleen op je eigen platform werkt (hallo ActiveX)) en zorg ervoor dat een paar key websites feature Y nodig hebben. Binnen de korste keren heb je een eigen variant van HTML gemaakt en hopelijk veel gebruikers gestrikt. Standaarden volgen is saai en is bijna nooit iemand rijk van geworden.

[Oon]

Waarom? Liever één open source engine waar iedere browser gebruik van kan maken, of die zelfs los van de browser updates kan krijgen, zodat nieuwe features ook meteen overal beschikbaar zijn.

Niks frustrerender als web developer dan erachter komen dat iets in Firefox gewoon kan met een vendor prefix, in Chrome kan zonder vendor prefix, maar dan in Safari gewoon helemaal niet mogelijk is, terwijl je werkgever wel Safari als ondersteuningseis stelt.

[latka]

Of je controleert vooraf (caniuse) of wat je wilt doen al breed gesupport is. Niet iedereen draait overal en altijd evergreen browsers. Niet is frusterender voor een gebruiker dan een site die het weer eens niet doet in Firefox en wel in Chrome. 9 van de 10 keer is het wegens een niet relevante feature op de site waar ik als gebruiker zowiezo al niet blij van werd, dus meestal niet echt een gemis.

[Oon]

Het gaat er vooral om dat er veel features zijn die überhaupt nooit ondersteund gaan worden in alle browsers, maar wel heel handig zouden zijn.

Een goeie developer bouwt altijd fallbacks in zodat alles gewoon 100% werkt, maar je kan vaak een website toch net een beetje extra geven door die nieuwe features te gebruiken. Wij ondersteunen op het werk alle gangbare browsers die nog officiële ondersteuning krijgen, maar soms moeten gebruikers ook gewoon even updates draaien.

[Aaargh!]

Waarom zou je dat willen?

Minder testen nodig (zowel aan de kant van de web-developers als aan de kant van de engine developers), alle developer-resources kan je in de ontwikkeling van 1 engine stoppen, waardoor je die veel sneller kan ontwikkelen.

[latka]

En voor je het weet is 1 security bug goed voor 100% besmetting. Nee dank je. Op het moment dat dat gebeurt installeer ik op mijn machine en de machines waar ik verantwoordelijk voor ben een alternatief. Tevens is alle concurentie en daarmee innovatie ineens verdwenen. Het klinkt als IE6 hell.

[foxforgames]

Waarschijnlijk omdat er dan niet genoeg concurrentie is op de markt, aangezien google dan het voortouw gaat nemen i.v.m. hun marktaandeel.

[Aaargh!]

Waarschijnlijk omdat er dan niet genoeg concurrentie is op de markt

Waarom zou je concurrentie willen op de markt van HTML render engines. Op welk vlak wil je concurreren als ze toch allemaal dezelfde features moeten ondersteunen ? Dit is gewoon een standaard component wat iedereen nodig heeft en waar iedereen precies hetzelfde wil. Waarom niet de krachten bundelen ?

[GekkePrutser]

Omdat het zo'n belangrijk component is dat het dan een gevecht wordt om invloed. Chrome levert Google op zich helemaal niks op, maar ze zetten er zo hard op in omdat ze de controle willen.

Zie bijvoorbeeld het hele verhaal rondom FLoC en nu weer het nieuwe gedoe waar ze mee bezig zijn. Dit is precies waarom we dat niet moeten willen. De engie reden dat Google dit soort dingen kan doordrukken is chrome.

Bovendien, het voordeel van alternatieve engines is dat ze zich focussen op andere prioriteiten. Beveiliging, en niche dingen zoals goede werking in een tekst-browser voor slechtzienden.

Een web engine is gewoon de sleutel tot het web en dus big bucks... Daar zijn standaarden juist een goede verdediging tegen.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 20:23]

[Aaargh!]

Zie bijvoorbeeld het hele verhaal rondom FLoC en nu weer het nieuwe gedoe waar ze mee bezig zijn. Dit is precies waarom we dat niet moeten willen

Juist de reden om het wel te doen. Nu bepaalt Google dat in z'n eentje. Als je de ontwikkeling in 1 onafhankelijke stichting stopt kan je dat juist voorkomen.

Beveiliging, (...) niche dingen zoals dat.

Beveiliging is geen niche en zou voor elke render engine de hoogste prioriteit moeten zijn.

[Reactie gewijzigd door Aaargh! op 23 juli 2024 20:23]

[GekkePrutser]

Maar wie controleert die stichting dan? Daar wordt dan gewoon achter de schermen een heel gevecht om gevoerd.

Zelfs met de echte standaard organisaties zoals W3C is dat nu zo. Het is alleen nog maar Google, MS enz die de richting bepalen. Ik zie het als toch weer een stapje achteruit.

FLoC is nu juist niet van de grond gekomen omdat mensen een keuze hebben, ze kunnen gewoon naar Firefox (zoals ik doe, ik gebruik nooit chrome).

Op zich is samenwerken aan 1 product heel goed, maar dan moet je elkaar wel kunnen vertrouwen en dat kan bij bijvoorbeeld Google niet. Microsoft heeft ook bewezen niet met deze verantwoordelijkheid om te kunnen gaan.

Beveiliging is geen niche en zou voor elke render engine de hoogste prioriteit moeten zijn.

Nee ik bedoel niche dingen zoals tekstrendering voor screen readers. Beveiliging inderdaad niet. Ik zal die zin even verduidelijken.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 20:23]

[Aaargh!]

Maar wie controleert die stichting dan? Daar wordt dan gewoon achter de schermen een heel gevecht om gevoerd.

Als er maar genoeg leden zijn kan er niet 1 iemand z'n zin doordrukken. Of het kan gewoon een geheel onafhankelijke organisatie zijn die zelf z'n koers bepaalt. Kijk naar b.v. ARM, die zelf bepaalt hoe hun CPU ontwerpen eruit zien welke vervolgens door iedereen gebruikt worden. Nu is ARM commercieel, maar een non-profit zou dit prima kunnen doen.

[CivLord]

Maar wie dwingt bv. Google om daar deel van uit te maken en er niet uit te stappen?

Bij ARM moet iedereen die van de architectuur gebruik wil maken een licentie nemen. Wanneer je iets wilt maken dat ARM-compatible is moet je die licentie afnemen en betalen. (Of het mogelijk is om buiten de licenties een eigen architectuur te ontwikkelen die voor software exact hetzelfde werkt als ARM weet ik niet, maar dat zou sowieso veel werk zijn en kostbaar worden.)
Webstandaarden zijn openbaar. Iedereen kan een HTML render-engin maken die aan de huidige standaarden voldoen (of een eigen implementatie daarvan). Nieuwe standaarden kunnen gepatenteerd en/ of gecopywritet worden zodat alleen de deelnemers in de organisatie deze kunnen implementeren én exact moeten implementeren zoals afgesproken (al gaat dat zo'n beetje tegen alle internet-principes in). Maar niets staat Google in de weg om die standaarden links te laten liggen en een eigen weg in te slaan met eigen verbeteringen en nieuwe mogelijkheden. Met Chrome als de browser met het grootste marktaandeel en grote sites als Google Search, Youtube en Gmail is het niet al te moeilijk te voorspellen hoe een dergelijke browseroorlog af gaat lopen.

[latka]

Omdat het uitbreiden van een standaard vereist dat je er goed over nadenkt. Als je ziet dat bijv. WebComponents v0 door Google heel hard gepushed zijn en ook in Chrome/Chromium zaten en Firefox zei: die implementatie die jullie daar gedaan hebben is zo brak, dat doen we gewoon niet in Firefox. Gevolg: het kon niet in de HTML standaard opgenomen worden want er was maar 1 implementatie van en Google is terug gegaan naar de tekentafel voor WebComponents v1 die wel ok in elkaar staken (en inmiddels dus ook in Firefox zitten). Op het moment dat er 0 concurrentie is heb je binnen de kortste keren te maken met allerlei extensie die alleen voor de grootste sponsor interresant zijn.

[TheVivaldi]

[...]

Waarom zou je concurrentie willen op de markt van HTML render engines. Op welk vlak wil je concurreren als ze toch allemaal dezelfde features moeten ondersteunen ?

Auto's moeten ook allemaal aan dezelfde eisen voldoen. Betekent dat dat jij wil dat er nog maar één autofabrikant overblijft?

[gimbal]

Innovatie, voornamelijk. Als het er maar eentje is dan remt dat per direct de noodzaak af om vooruitstrevend te zijn.

[Aaargh!]

Juist niet. Nu moet je alles 4 keer doen en je moet door een ellenlang standaardisatie process om nieuwe features toe te voegen, allemaal dingen die de boel afremmen. Het is juist de bedoeling dat ze allemaal gelijk zijn, daar gaat dit hele artikel over dus een browser die in z'n eentje nieuwe niet-standaard dingen gaat toevoegen wil je juist niet.

[latka]

Lees nog even de discussie rondom webcomponents na: daar was 1 implementatie van (wel lekker snel beschikbaar) die gewoon slecht was. Dat is wat je krijgt als 1 partij verantwoordelijk is voor de HTML standaard + HTML implementatie.

[GekkePrutser]

Vind ik geen goed plan. dan ben je juist een groot deel van je standaarden kwijt en het gevaar is dat een commerciele partij dan het geheel naar zich toetrekt zoals nu de facto met chrome gebeurd is.

In de tijd van Internet Explorer hebben we kunnen zien wat het risico daarvan is. Zodra het marktaandeel niet meer hoger kan, gooit men de handdoek in de ring en laat het geheel rustig verder sudderen met alle interoperabiliteits- en beveiligingsproblemen vandien.

[Aaargh!]

In de tijd van Internet Explorer hebben we kunnen zien wat het risico daarvan is.

IE was closed-source. Je moet dit juist open-source doen en laten ontwikkelen door een onafhankelijke organisatie. Dat is nu precies een van die dingen waar OSS erg geschikt voor is: het ontwikkelen van standaard, 'saaie' componenten die iedereen nodig heeft maar waar je je totaal niet op kan onderscheiden.

Het Linux kernel is hier ook een goed voorbeeld van: Iedereen heeft een kernel nodig voor z'n OS, maar geen consument die zich hier voor interesseert dus het is geen onderscheidende feature van je product. Dan kan je dit beter samen ontwikkelen.

[GekkePrutser]

Maar Linux is niet de enige optie op de OS markt. Ik gebruik juist FreeBSD omdat ik vind dat Linux een speelbal is geworden van Big Data. Als je kijkt naar hoeveel de grote cloud partijen aan Linux lopen te sleutelen: https://i0.wp.com/news.it...ers-stats.png?w=525&ssl=1

Dan zie ik toch een hoop partijen waarvan ik absoluut niet wil dat ze aan mijn OS lopen te rommelen (zie bovenaan bijvoorbeeld, Huawei)..

Ik ben juist voor keuzemogelijkheden op dit gebied.

[mOrPhie]

Innovatie. Als je dat samen gaat doen gaat de ontwikkeling van de browser straks net zo langzaam als de ontwikkeling van de standaard zelf.

[Aaargh!]

Jij denkt dat alles 4 keer doen sneller is dan alles 1 keer doen ?

[mOrPhie]

Ja, natuurlijk is dat sneller. Je hebt minstens het cartesisch product minder aan communicatiekanalen. Parallelle ontwikkeling heeft ook het voordeel dat je meerdere uitwerkingen krijgt, waardoor er competitie ontstaat. De concurrentie tussen gecko, WebKit en Blink heeft ons heel veel versnelling van de adoptie van HTML5 opgeleverd. Puur omdat iedereen het eerst wilde zijn.

Of het efficiënter is, is een andere discussie. Ik denk dat het efficiënter is, omdat innovatie een grotere kans krijgt en omdat zo enorm veel mensen er gebruik van maken, wordt elke innovatie enorm versterkt keer het aantal gebruikers en webdevelopers.

Consortiums zijn inherent inefficiënt. Nodig en noodzakelijk voor interoperabiliteit, maar omdat ze inherent inefficiënt zijn, moet je het takenpakket ze hebben dan ook zo klein mogelijk houden.

[Neocortex-re]

Omdat wat nu modern is over tien jaar het legacy probleem is.

[Lapjespoes]

Concurrentie. Als je concurrent een browser met betere prestaties heeft, verlies jij aandeel op de markt. Als iedereen dezelfde engine gebruikt, krijg je nooit dezelfde mate van verbeteringen. Immers ervaren ze dan geen druk om te verbeteren.

[jared9]

Het webkit team is goed bezig op Twitter:

https://twitter.com/jensimmons/status/1491064075987873792

Ik verwacht dat ze met de experimental versie van Safari een flinke inhaalslag gaan maken.

[R4gnax]

Ik verwacht dat ze met de experimental versie van Safari een flinke inhaalslag gaan maken.

De vraag is nog steeds hoeveel van de features in de experimental versie uiteindelijk ook in de stable terecht komen.

De experimental is eigenlijk de pure Webkit met de Apple branding er op en waar het Webkit team praktisch gezien de scepter zwaait.
De stable ligt zwaarder onder het bewind van Apple als bedrijf, en als de bedrijfslijn zegt dat het uitbrengen van een bepaalde feature niet goed uitlijnt met de bedrijfsdoelen - lees: bepaalde toepassingen op het web-platform blijven frusteren, om native apps een vereistte te houden - dan verdwijnen die mooie nieuwe features alsnog achter een vlag die standaard uit staat; of worden ze helemaal niet overgenomen.

[dotnoting]

Ben benieuwd of andere browsers (partijen) zoals duckduckgo zich ook aan deze testsuite (willen) gaan conformeren...

[darknessblade]

Dus ze willen hetzelfde doen als met PDF bestanden, waarbij het niet uitmaakt of je het bekijkt op een 3 inch scherm of op een 50 inch scherm. waarbij het doccument er hetzelfde uitziet ongeacht het scherm

[watercoolertje]

Nee er staat niet dat ze op elke resolutie gelijk moeten zijn, maar op elke browser, dus welke van de 4 je gebruikt zou dan hetzelfde weergeven op een fullhd resolutie maar de website kan er op een smartphone wel anders uit zien maar juist wel hetzelfde als de andere browsers op datzelfde scherm zouden doen.

[Rub3s]

Nee, alle browsers zouden hetzelfde resultaat moeten geven als je een bepaalde website bekijkt.

Looking at you Safari

[Ramoncito]

Moet zeggen dat zelfs grote websites als Marktplaats het gewoon niks interesseert als er een onderdeel van de website niet werkt in een bepaalde browser, of icm met bepaalde AV-software. Heb dat een paar keer meegemaakt met Firefox icm mijn Kaspersky. Dan moet je wat rare fratsen uithalen om het werkend te krijgen. Soms moet je dan maar gewoon opgeven en met een incomplete website verder, of de hele cookie/tracking reut accepteren...

[Bender]

Hadden we daar niet HTML en CSS voor?

[Godson-2]

Eindelijk eens goed nieuws op het gebied van browser interoperability!!

[Linksquest]

Als dit alleen maar ten goede komt om beter en stabieler te werken, dan vind ik het allemaal prima.

[HertogJan]

FireFox: nice