Safari krijgt vertaalfunctie en ondersteuning voor WebExtensions-api

Apple gaat zijn Safari-browser met de introductie van macOS 11 Big Sur van een grote update voorzien. Er komt ondersteuning voor de WebExtensions-api, zodat ontwikkelaars bestaande extensies naar Safari kunnen brengen. Ook bouwt Apple een vertaalfunctie in.

Apple legt bij de komst van meer extensies naar Safari de nadruk op privacy. De externe toevoegingen kunnen volgens het bedrijf een risico vormen en gebruikers kunnen bijvoorbeeld aangeven dat een extensie maar een dag actief mag zijn, of op een bepaalde site.

Omdat Safari ondersteuning krijgt voor de WebExtensions-api, kunnen ontwikkelaars hun bestaande extensies voor andere browsers gemakkelijk overzetten. Onder andere Firefox gebruikt die api. Apple gaat de Safari-extensies via zijn Mac App Store aanbieden.

De nieuwe versie van Safari wordt later dit jaar uitgebracht samen met macOS 11 Big Sur. Apple claimt dat de vernieuwde browser sneller is en dat veelbezochte websites 50 procent sneller laden dan in Chrome. Ook het ontwerp van tabs wordt aangepast. Die tonen nu meer informatie, waaronder een favicon. Als gebruikers de muis over een tab bewegen, wordt een preview weergegeven van de inhoud.

Ook krijgt Safari een aanpasbare startpagina en een ingebouwde vertaalfunctie. Laatstgenoemde werkt met zeven talen. De aankondigingen van Safari vallen samen met de introductie van macOS 11 Big Sur. Die versie van het besturingssysteem krijgt een grote designupdate en bevat onder andere een Control Center, dat lijkt op dat van iPad OS. De nieuwe macOS-versie werkt zowel op Macs met ARM-chips als met Intel-processors.

Safari in macOS 11 Big Sur
macOS Big Sur met vernieuwde Safari-browser

Door Julian Huijbregts

Nieuwsredacteur

22-06-2020 • 21:42

60

Reacties (60)

60
58
13
2
0
43
Wijzig sortering
Een correctie, het lijkt er op dat Safari niet direct ondersteuning krijgt voor de Web Extension standaard maar dat er een conversie plaats kan vinden via xcode. Zie de nieuwe documentatie hier en ook deze pagina. Wellicht een stap in de goede richting voor extensie ontwikkelaars ten opzichte van wat het was maar nog steeds een hoop extra moeite.

In een open source project waar ik aan mee werk zijn we het een beetje aan het volgen omdat we verwachten dat gebruikers nu weer extra zullen vragen om Safari support. Maar je hebt nog steeds een macOS machine nodig en $100 per jaar en er is nog veel onduidelijk. Het is nog even afwachten of er sprake is van volledige support (al dan niet via conversie) want anders is het alsnog een tweede code base bijhouden.

[Reactie gewijzigd door Creesch op 26 juli 2024 11:56]

Safari is een fantastische browser maar er zijn toch enorm veel beperkingen waardoor gebruikers naar Chrome of iets anders geduwt wordt. Bijvoorbeeld de mogelijkheid op te videochatten via sites, daarvoor moet ik altijd naar Chrome gaan.
Safari is nog lang niet volwassen als je het mij vraagt.
Ik denk niet dat dit een beperking is van de browser, maar eerder van de developer van de web applicatie. Safari heeft op zich een goede ondersteuning voor de APIs die nodig zijn voor video bellen op het web, maar het lage marktaandeel zorgt ervoor dat veel developers (en ik heb vooral de indruk dat google zelf zich hier schuldig aan maakt) een suboptimale versie voor safari neerzetten. Het marktaandeel zorgt er tevens voor dat google de 'macht' heeft om onofficiële standaarden te introduceren die websitebakkers vervolgens gaan gebruiken, met als gevolg dat niet alle andere browsers goed ondersteund worden...
Yup, maar ik weiger Chrome te gebruiken want ik vertrouw het voor geen cent en wil het niet op mijn Mac hebben. Ik gebruik wel Firefox, werkt prima voor Google Meet.

Google boycot Safari op wel meer websites; onder meer de Firebase docs renderen ("wonderbaarlijk" genoeg) niet altijd lekker in Safari: bepaalde teksten worden bijvoorbeeld ineens verticaal weergegeven en sommige links zijn niet of moeilijk klikbaar, en dat terwijl het nou niet van die heel bijzondere webpagina's zijn. Ik heb het gevoel dat er een stukje javascript draait die het voor Safari verstiert en probeert om zoveel mogelijk users naar Chrome te lokken.
Yup, maar ik weiger Chrome te gebruiken want ik vertrouw het voor geen cent en wil het niet op mijn Mac hebben.
Ik ook niet. Daarom gebruik ik Edge, dat is ook Chromium, maar dan 99% van de Google spyware eruit gesloopt. Brave is ook een optie.
Waarbij de spyware van Google is vervangen door die van Microsoft. Nee daar bedank ik ook voor.
Als ik hier kijk missen er bij Safari toch nog diversie zaken op media en codec gebied. Apple heeft de afgelopen jaren wel Safari flink op de schop genomen (na lange tijd geen onderhoud te plegen) maar volgens mij ondersteunt Safari diverse zaken nog niet die al wel door Firefox en Chrome worden ondersteund.
Je linkt mist een zoekopdracht, dus je claim is wat lastig te beoordelen. Google heeft hard hun codec gepusht, terwijl Safari weer andere codecs ondersteunt. Het criterium voor Apple is dat hardwareacceleratie mogelijk is waardoor batterijduur goed is. Te zien aan Chrome is dat bij Google bijvoorbeeld niet het geval.
Iets fout gegaan in het kopiëren van de url, maar het is relatief eenvoudig om de huidige versie safari aan te vinken hoor ;)

Lijkt er op dat tweakers iets weg poetst


https://caniuse.com/#compare=edge+83,firefox+77,safari+13.1

[Reactie gewijzigd door Creesch op 26 juli 2024 11:56]

Safari ondersteunt volgens het lijstje deze codecs niet: WebM, WebP, Opus, Ogg, Theora, AV1. Deze staan allemaal onder "Other" omdat ze niet onderdeel zijn van de html-standaard. Dus van "missen" zou ik niet spreken in dit geval, maar een keuze om andere codecs te ondersteunen.
Nee, dat is nou net het punt. Je zou helemaal geen versie van Safari moeten bouwen. Als developer bouw ik iets voor de Web APIs. Als Apple er voor kiest dat Safari de standaarden niet ondersteund, ga ik echt geen aparte versie bouwen voor Safari.
In theorie heb je gelijk; in theorie zijn er standaarden en tests die de standaarden controleren (o.a. ACID3). In de praktijk zijn er helaas kleine verschillen in interpretatie van die standaarden, waardoor je verschillen krijgt in renderen.

Dat gezegd hebbende, een andere reactie in deze thread geeft aan dat een Google-product niet lekker werkt in Safari. Google doet een paar dingen om ervoor te zorgen dat niet-Chrome browsers "stuk" lijken of "niet lekker werken". Youtube is bijvoorbeeld historisch langzaam in Firefox - omdat het gebouwd is met technologie dat nooit gestandaardiseerd is (zie bijv. https://www.theverge.com/...osoft-edge-safari-firefox)
Ik weet het, ik gebruik Firefox. Google en Chrome zijn de nieuwe Microsoft en Internet Explorer. Maar de issue bij Safari is niet dat het standaarden anders interpreteert, maar gewoon dat het ze niet ondersteunt, tot vele jaren later. Compleet onbruikbaar als moderne browser.
Nee, dat is nou net het punt. Je zou helemaal geen versie van Safari moeten bouwen. Als developer bouw ik iets voor de Web APIs.
Nee.
Als developer bouw je iets wat aan de webstandaarden voldoet. Plugins zijn voor bijzondere dingen, zoals password managers en ad blockers. De tijd van Flash is voorbij!

Pas als er echt iets mist wat iedereen nodig heeft, kun je aan extensies beginnen. Dat zou eigenlijk alleen zo moeten zijn voor zaken die camera en/of microfoon nodig hebben.
Als ik een paar jaar geleden iets netjes volgens de standaard bouwde, dan wist ik 100% zeker dat het in Safari in ieder geval NIET ging werken.
Wat zijn dan volgens jou "de standaarden"?
HTML 5? XML? AJAX? TLS?
HTML5, CSS3 (Destijds), WebRTC, FlexBox. Als ik nu op caniuse kijk staat Safari nog steeds vrijwel onderaan qua API ondersteuning.
Ik vind dat b19a het mooi verwoord heeft:
Het probleem is dat ontwikkelaars niet kijken naar welke standaarden breed in de industrie gedragen worden, maar datgeen wat Chrome toevallig ondersteunt. En Chrome wil nog wel eens iets toevoegen wat helemaal nog geen standaard is, ontwikkelaars gaan het gebruiken, en vervolgens klagen dat anders browsers de "standaard" niet ondersteunen. Uiteindelijk met als gevolg hetzelfde als met Internet Explorer: "This website only works in Internet Explorer 6 Google Chrome."
HTML5, flexbox en WebRTC zijn gewoon standaarden beheerd door W3C.
HTML5?
Safari had het in 2013, net als Chrome en FF. Edge in 2015.

Flexbox?
Chrome: 2012
Safari: 2013
FF: 2014
Edge: 2015

WebRTC?
Ja, daar liep Safari net als Edge achter, maar ook dat hebben ze al sinds 2017. Dat was bovendien het jaar dat de browser prefixes in Chrome en FF wegvielen, en dus vermoedelijk het jaar dat WebRTC een W3C standaard werd.


Net als Gadget Freak ben ik van mening dat b19a het mooi heeft verwoord. Vanuit dat perspectief ontwikkel ik regelmatig websites bewust in Safari. Zaken bijstellen in Chrome of FF is zelden nodig. IE11 blijft natuurlijk een verhaal apart.

edit: typo

[Reactie gewijzigd door Solinx op 26 juli 2024 11:56]

Het probleem is dat ontwikkelaars niet kijken naar welke standaarden breed in de industrie gedragen worden, maar datgeen wat Chrome toevallig ondersteunt. En Chrome wil nog wel eens iets toevoegen wat helemaal nog geen standaard is, ontwikkelaars gaan het gebruiken, en vervolgens klagen dat anders browsers de "standaard" niet ondersteunen. Uiteindelijk met als gevolg hetzelfde als met Internet Explorer: "This website only works in Internet Explorer 6 Google Chrome."
Ik bouw zelf alles tegen Firefox aan exact om deze reden. Zoals ik al eerder zei zijn Google en Chrome de nieuwe Microsoft en Internet Explorer. Developers die zeggen "it works in Chrome!" zijn inderdaad een slecht ding.
Je hebt deels gelijk. Maar als ik op caniuse.com kijk en zie dat 3 van de 4 grote browsers API's goed ondersteunen, en alleen Safari loopt (weer) achter. Dan ga ik vrolijk die API's gebruiken hoor. Anders blijft functionaliteit die al 10 jaar beschikbaar is in andere gangbare browsers voor altijd achter slot en grendel. Laat Apple hun browser maar gewoon fixen naar een Niveau vergelijkbaar met hun concurrenten. En als je dit blijft doen zo dan krijgt Apple nooit een prikkel om er eindelijk eens wat aan te gaan doen.
Als het API's betreft die een standaard zijn (b.v. html4 / html / es6 / whathaveyou), dan ben ik het met je eens dat Apple moet zorgen dat ze die implementeren. Of je ze zou moeten gebruiken is een ander punt. Ik gebruik Safari en als jouw website niet werkt, dan klik ik wel de concurrent aan. (Tenzij jouw website zo belangrijk voor me is dat ik er speciaal Firefox voor open, maar die kans is nihil.)
Dat snap ik voor jou als 'consument', jij wilt natuurlijk dat de boel gewoon werkt in je browser naar keuze en gelijk heb je. Aan de andere kant wil ik als developer met enig recente API's en functionaliteit kunnen werken, geen uren en uren bezig zijn om één browser te ondersteunen die (destijds) letterlijk jaren achterliep op de concurrentie of functionaliteit achterhouden voor de andere browser gebruikers (80% of meer van de gebruikers dus).

Ik had destijds voor mijzelf die afweging gemaakt en ervoor gekozen om Safari niet te ondersteunen. Voor bepaalde (video) tools was het zelfs niet eens mogelijk om deze geschikt te maken voor Safari en had ik geen keus, of een toffe tool / website die werkt op meer dan 80% van gebruikers, of helemaal niks voor niemand. Die keuze was voor mij redelijk snel gemaakt.

Ik snap echt waar je vandaan komt en ben het zelfs met je eens. Maar hiervoor zou ik toch echt naar Apple kijken en niet naar de developers van websites/tools.
Vroeger ging het W3C over webstandaarden, nu is het Google, en dat is een slecht teken...
Dat ben ik helemaal met je eens. Daarom noem ik ook 3 van de grote vier, waar alleen Safari het buitenbeentje is. Daarnaast de API's / functionaliteit die ik benoem zijn allen W3C standaarden en Safari ondersteunde ze niet. Edge, Firefox en Chrome wel. (en daarnaast, veel van de ondersteuning van Safari week ook af van de W3C standaard!)

[Reactie gewijzigd door !GN!T!ON op 26 juli 2024 11:56]

Edge en Chrome zouden wat engine betreft identiek moeten zijn, blijven Chromium en Firefox over.

Als Safari niet aan de W3C standaarden voldoet, dan moet ik jou gelijk geven, want wat zijn standaarden als je je er niet aan houdt?
Op papier heeft Safari net genoeg support, maar in de praktijk zitten er nogal wat haken en ogen aan (lees: bugs). Dat geldt niet enkel voor WebRTC en de bijbehorende API's, maar in z'n algemeen. Safari is geen geweldig stabiele browser vanuit ontwikkelaars gezien. Heel veel dingen worden maar deels ondersteund.

Een veel groter probleem is echter Apple's release beleid. Safari krijgt nooit veel updates en zelfs de jaarlijkse updates worden niet hard gepusht. Gelukkig heeft Apple het inmiddels wel enigszins losgekoppeld van de macOS releases (Safari 10 was de eerste versie die op "vorige" macOS versies te krijgen was), maar dan nog zijn sommige features gebonden aan het OS waar het op draait. En nee, Mac gebruikers updaten bij lange na niet allemaal elk jaar. Die adoption rates klopt geen moer van* :p

Het gevolg is dat je als web developer meer op Safari moet testen dan op Chrome. Apple maakt dat ook niet gemakkelijk, want je móet een Mac hebben; en oudere versies van Safari kun je niet echt draaien.

Er worden tegenwoordig overigens maar zelden onofficiële standaarden gebruikt, tenzij het voor proof of concepts is. Apple maakt zich daar trouwens even goed schuldig aan, zij hebben ook eigen standaarden. Dat doen alle browser fabrikanten, hoewel dat tegenwoordig veel minder een probleem is dan voorheen. Maar waar Chrome/FF** vaak heel rap zijn met nieuwe standaarden, is Apple heel erg traag. WebRTC werd dan wel door Google voorgesteld (kwam echter uit een overname), ze gooiden het wel meteen in de WG, waar Apple ook gewoon deel van uit maakt. In 2010 kwamen ze met het voorstel, in 2011 kwam de eerste draft en in 2012 zat het in Chrome. Half jaartje later in FF. Safari? 2017. En zo gaat dat met heel veel dingen die Apple zelf niet zo boeiend vindt. Vind je het gek dat wij ontwikkelaars Safari als een randproduct zien en het niet als hoofdgroep behandelen? :P

Als ontwikkelaar is Safari tegenwoordig gewoon het grootste struikelblok. Los van bugs en feature support, is de browser gewoon niet voor iedereen toegankelijk. Dat is waar Apple keihard de mist in gaat. En waar veel Apple gebruikers ook de mist in gaan. Je kunt niet van elke ontwikkelaar verwachten dat ze zomaar een Mac hebben.


* op een site met 60% Mac gebruikers, waarvan 25% Safari (70% Chrome), zie ik dit qua versies):

[list]
• 13.1: 61,5%
• 13: 15%
• 12.1: 10%
• 12: 5%
• 11.1: 5%
[/list]

Die 20% met 11-12 kunnen wij niet negeren, ook al is het maar een paar procent van het gehele aantal. En het verschil tussen 13.1 en 13.0 maakt qua features ook wel iets uit.


** MS negeer ik hier heel bewust, want zij zijn vreemd. IE < 11 was gewoon ruk, klaar. Die browsers liepen constant achter en deden niets volgens spec. IE11 liep nog steeds achter, maar volgde de specs over het algemeen wel erg goed. Edge was een stuk moderner én volgde de specs goed, dus met Edge heb ik minder problemen gehad dan met Safari. Inmiddels natuurlijk ook geen punt meer, met ChromiumEdge :P
Dit dus. Inmiddels ben ik geen webdev meer (bijhalve voor hobby), vroeger altijd de haren uitgetrokken over IE en daarna een hele lange periode had Safari dat stokje overgenomen. Hoop dat het beter is nu, of gaat worden. Wat heb ik op die browser lopen vloeken vroeger :p
Dat is niet veranderd en zal voorlopig niet veranderen. De manier waarop Apple software bouwt is daar vooralsnog te star voor. Ze lopen ook altijd achter op hun eigen WebKit development. We zullen wel zien hoe het met macOS 11+ gaat, maar ik betwijfel of het iets verandert.

Ik hoef gelukkig niet al te vaak client-side werk te doen, maar het zijn dan wel meestal van die gekke dingen in Safari; en als je dan niet eens dezelfde versie als de klant kan draaien krijg ik af en toe wel de neiging de Mac Mini van het balkon af te donderen. Zolang je binnen Apple's ecosysteem blijft is alles soepel, maar daarbuiten is het rampzalig. Dat geldt voor ondersteuning van elders geaccepteerde standaarden, maar ook bijvoorbeeld voor dingen die ze zelf naar andere systemen willen krijgen. Sign In with Apple is een zooi van jewelste. Dat is een PoC dat een executive op de markt wilde hebben en 5 minuten voor de aankondiging besefte er ergens iemand dat ze het ook elders moesten aanbieden.
Ik denk het wel, tenzij er in het afgelopen jaar iets is veranderd. Ik heb nog niet al te lang geleden zelf een videochat tool gebouwd o.b.v. WebRTC en JS. Netjes volgens de standaard werken en het werkt in firefox en chrome. Safari heeft nooit gewerkt (geen ondersteuning voor API's), tenzij je met allemaal ouderwetse fallbacks ging werken. Ook op caniuse.com destijds stond Safari echt achter qua API ondersteuning.
Edge is even erg of erger dan chrome betreft privacy inbreuk.
Heb je daar bewijs van, of is dat onderbuikgevoel?
Dat zijn drie links die over hetzelfde onderzoek gaan die niet echt een heel duidelijke conclusie biedt..
Safari is de nieuwe IE. Je moet best wel vaak dingen net iets anders doen om het te laten werken in Safari (net zoals vroeger in Internet Explorer).
Chrome is de oude IE, veel zaken worden voor de Chrome standaard ontwikkeld. Firefox en Safari gebruikers worden verzocht Chrome te gebruiken voor verschillende functies. Dit is voornamelijk het geval voor videochats.
Wat je zegt kan prima met Safari hoor. Check bijvoorbeeld whereby.
Helaas kan ik in iOS de twilio api (voor voip) niet op chrome gebruiken, enkel op Safari...
Muv ZiggoGo gebruik ik alleen maar Safari.
Weet niet waar het bij jou misgaat maar ik zit regelmatig in videochats/calls in safari.
(BlackBoard en Jitsi weet ik in ieder geval zeker van dat ze werken, Teams weet ik niet zeker of ik daar de eigen app van heb gebruikt.)
Raar, Bij Jitsi kan ik geen camera toegang geven.
Apart.

XS4All TV werkt nl. ook niet bij mij in Safari en is dan ook de enige reden om Chrome even op te starten.
Denk dat er iets meer nadruk gegeven mag worden op het ‘privacy’ aspect van de nieuwe safari in het artikel. Zoals in de presentatie zelf.

Althans, dat vind ik dan weer het belangrijke.

[Reactie gewijzigd door slijkie op 26 juli 2024 11:56]

Dat is idd belangrijk, evenals het review-proces voor Safari addons - in Chrome en Firefox zijn er teveel frauduleuze of low-effort addons, of addons die worden overgenomen om als spy/adware ingezet te worden.
Als daarmee weer extensies zoals uBlock origin mogelijk worden onder Safari, denk ik dat Apple weer op de goede weg zit.
Ik hoop dat dat vertalen intuiver werkt dan in Chrome die gewoon op iedere pagina een lompe balk laat zien met of je het wilt vertalen. :o }:O
Ja, het gaat via een klein knopje naast de URL-balk waar je nu ook al de website-specifieke instellingen kan beheren. Dus dat is wel prettig. Bij ondersteuning dan wel alleen support voor 7 talen en de functie wordt vooralsnog alleen in de VS en Canada aangeboden.
Ik hoop dat dat vertalen intuiver werkt dan in Chrome die gewoon op iedere pagina een lompe balk laat zien met of je het wilt vertalen. :o }:O
Kan je uit zetten in instellingen menu hier de uitleg ervan :
https://www.howtogeek.com...tion-on-or-off-in-chrome/
ik zie die balk nooit en als ik een site wil vertalen doe ik rechtermuisklik > vertalen. Simpeler wordt het niet.
Jawel hoor, linkermuisklik. Simpeler dan rechts, als je het voor het eerst doet.
Ik ervaar niet zoveel problemen met Safari, zo nu en dan een keer een probleem op een website. Over het algemeen vind ik het een prettige browser en soms doe ik een uitstapje maar kom altijd weer terug bij Safari. Ook de ingebouwde leeslijst is erg handig en qua accu-duur op mijn Macbook scheelt het echt wel met chrome! Zoals slijkie ook aangeeft is privacy ook wel degelijk een goede reden om safari te blijven gebruiken.

Wanneer de extensies nu ook nog een keer echt op gang gaan komen met de nieuwe API dan ben ik helemaal blij. Tot nu toe is het aanbod namelijk echt wel heel minimaal.
De beste extensie is Dynamo waarmee je commercials kan skippen.

[Reactie gewijzigd door Maverick2001 op 26 juli 2024 11:56]

Ik vond de web performance claim t.o.v. Chrome nogal gewaagd, dus dat wordt testen... Daarbij verwacht ik niet dat ze gaan inlopen op marktaandeel, maar wie weet :*)

https://netmarketshare.co...ments%22%3A%22-1000%22%7D
Ondersteuning voor favicons in tabs zit er in de huidige Safari versies al in, geen idee wat daar nieuw aan is..
De grap is dat Apple favicons een paar jaar terug in de ban heeft gedaan. Een jaar later was het weer toegevoegd, maar staan ze standaard uit. In deze release lijken favicons weer een prominentere rol te krijgen.
Safari 14 gaat ook eindelijk WebP ondersteunen. Dat vind ik persoonlijk veel interessanter.
Blijkbaar gaan die MCSE speldjes met een pakje boter blijkbaar. Je hele betoog raakt kant nog wal.. Sorry..

Op dit item kan niet meer gereageerd worden.