Nice small detail:

This emoji does not show in the title bar of Safari, presumably to prevent less-reputable sites pretending to be secure (encrypted using HTTPS) when they are not.

Chris Thoburn:

It’s awesome that Chrome had this feature, right?

If that last thought was actually your last thought… congrats, you just mentally accepted years of torture doing exactly this to fix the other “most feature rich browsers”… IE6, 7, 8, and 9. …but “Standards!”. Yes, these features are on standards tracks, and thankfully far enough along they aren’t likely to be rejected. But guess what, a lot of IE’s ideas were proposals too, and a lot of them are only just now being accepted as standards today, just under different names and with improved APIs. Being first does not make you the best.

Safari è più lento nell’adottare feature che ancora sono in discussione e devono diventare standard. Chrome, nel frattempo, adotta tutto in un lampo preoccupandosi poco delle prestazioni.

Posto in altri termini: Safari è più preoccupato col soddisfare gli utenti, Chrome col soddisfare gli sviluppatori.

Simile negli intenti a Chrome Canary, Safari Technology Preview è una versione di Safari per sviluppatori web, con funzionalità sperimentali — le cose che abilita sono elencate in questa pagina del sito di Apple.

Dal blog di WebKit:

Safari Technology Preview is a standalone application that can be used side-by-side with Safari or other web browsers, making it easy to compare behaviors between them. Besides having the latest web features and bug fixes from WebKit, Safari Technology Preview includes the latest improvements to Web Inspector, which you can use to develop and debug your websites. Updates for Safari Technology Preview will be available every two weeks through the Updates pane of the Mac App Store.

Un miliardo di dollari solo per il 2014, riporta Bloomberg:

Google Inc. is paying Apple Inc. a hefty fee to keep its search bar on the iPhone.

Apple received $1 billion from its rival in 2014, according to a transcript of court proceedings from Oracle Corp.’s copyright lawsuit against Google. The search engine giant has an agreement with Apple that gives the iPhone maker a percentage of the revenue Google generates through the Apple device, an attorney for Oracle said at a Jan. 14 hearing in federal court.

Jeff Atwood, lo sviluppatore di Discourse[1. Per alcuni mesi lo utilizzati su questo blog]:

It seems the Android manufacturers are more interested in slapping n slow CPU cores on a die than they are in producing very fast CPU cores. And this is quite punishing when it comes to JavaScript.

This is becoming more and more of a systemic problem in the Android ecosystem, one that will not go away in the next few years, and it may affect the future of Discourse, since we bet heavily on near-desktop JavaScript performance on mobile devices. That is clearly happening on iOS but it is quite disastrously the opposite on Android.

Chrome su desktop però mostra performance pari se non migliori di Safari. La ragione risiede piuttosto in Android, nel processore: il migliore device Android in circolazione ha una performance peggiore dell’iPhone 5.

Notava John Gruber, nella sua recensione dell’iPhone 6S:

Take a look at Geekbench’s aggregate results for Android devices. In terms of single-core performance, there isn’t a single Android phone that beats the two-year-old iPhone 5S. Android devices fare better in multi-core benchmarks, because they have more cores (some have eight, many have four — the iPhones 6S still have only two cores), but single-core performance is a better measure for the sort of things you can feel while using a device. Apple is literally years ahead of the industry.

Maximiliano Firtman ha riportato tutto quello che c’è da sapere, di nuovo e utile, riguardo a Safari su iOS 9 per uno sviluppatore web.

Due cose interessanti: una libreria/API Javascript che permette ad una webapp di accedere ai dati dell’utente su iCloud, e App Search, che permette a chi ha un sito e un’app corrispondente al sito di far trovare e vedere i propri contenuti a Siri:

Apple has just entered the search market with its own web spider that we need to support to increase our visibility inside the new Spotlight iOS search and Siri. It’s also important when we have both a website and an app, because now Apple will index the content on our website but it might lead the user to the app instead.

While this will open a new chapter in SEO, it’s quite simple. You need to use markup standards, such as Web Schemas, AppLinks, OpenGraph or Twitter Cards with an App Banner with an app-argument if you have your own native app.

Apple has just released an App Search Validation Tool that will help you understand what do you need to add in your own website to support Apple Search

Mancano ancora — se non altro io ne sento la mancanza — le notifiche push per i siti web (contrariamente a Safari su Mac, che da tempo le supporta).

Se fate uso di content blocker è possibile che a volte una pagina non vi funzioni come dovrebbe. Può succedere per un errore — perché il content blocker sta bloccando cose che non dovrebbe — o anche perché il sito visitato sta tentando di impedirvi l’accesso al contenuto, come conseguenza dell’aver impedito alla pubblicità di caricarsi (capita spesso, con i video).

Invece di aggiungere il sito in questione in una whitelist, o disabilitare completamente i content blocker, è utile sapere che Safari per iOS offre un’opzione per ricaricare la pagina in questione momentaneamente senza alcun content blocker.

Per farlo è sufficiente premere sull’icona refresh, a lungo.

Peace, il content blocker di Marco Arment

Marco Arment ha rilasciato Peace, un content blocker per iOS 9. Peace utilizza il database di regole di Ghostery (che uso su Mac, e raccomando) per decidere cosa bloccare e cosa ignorare, che a dire di Marco si è rivelato quello più affidabile e che dava meno problemi di compatibilità.

Uso Peace da poche ore e già mi pare che Safari sia più veloce e i siti che visito meno fastidiosi. A 2,99 euro vale l’investimento.

Provate a copiare uno dei risultati di ricerca di Google e vi accorgerete — io me ne accorgo spesso, con fastidio — che l’indirizzo che otterrete non sarà quello del sito selezionato, ma un URL illeggibile che re-indirizza al sito in questione. Google, come Facebook, usa JavaScript per rimpiazzare il link diretto, originale, che volete copiare, con un altro che inizia con google.com e prosegue con molti caratteri — in modo da tracciare in maniera più accurata le visite e i click.

DirectLinks è una magnifica estensione per Safari che disabilita il JavaScript in questione, e vi permette di copiare quello che volete copiare.

Dean Murphy sta lavorando a un’applicazione per sfruttare i nuovi content blockers di Safari. Crystal, tale applicazione, uscirà appena iOS 9 sarà disponibile ma Murphy nel frattempo la sta testando su vari siti di news, per vedere quali sono i guadagni per l’utente in termini di performance.

I risultati parlano da sé:

On average, pages loaded 74% faster with Crystal and used 53% less bandwidth. Just by having Crystal installed, I saved a total of 70 seconds and 35MB of data on these 10 pages.

10 siti di news (come The Verge, Vice e Wired), 35MB di traffico dati risparmiati. Chi crede che gli utenti non sfrutteranno questa nuova opportunità, perché è sbagliato farlo, si illude (oltretutto, è altrettanto sbagliato far sprecare ai propri visitatori tempo e dati).

Perché non è immorale bloccare la pubblicità sul web

A Settembre uscirà iOS 9, che introdurrà i “content blockers”: gli sviluppatori potranno scrivere estensioni per Safari per bloccare un determinato contenuto. In altre parole, all’improvviso a Settembre sarà possibile, su iPhone e iPad, bloccare la pubblicità su Safari, e gli effetti di strumenti come AdBlock si moltiplicheranno. Agli utenti sarà sufficiente installare un’estensione per liberarsi in poco tempo di tutti i fastidi del web: pubblicità invasiva e sovrapposta al contenuto, video con autoplay e porcate varie avranno un brutto tempo. All’improvviso milioni di utenti realizzeranno quanto un web senza pubblicità sia più veloce e comporti più privacy (i content blocker potranno bloccare anche i vari strumenti di tracking, di cui i grandi editori abusano). Come ben scrive Charles Arthur, “mobile is the biggest platform. Adblocking is coming to a key mobile platform in September“.

La situazione sarà interessante. Come riporta il New York Times, già adesso l’uso di ad-blocker sta costando agli editori parecchi soldi:

In a report last week, Adobe and PageFair, an Irish start-up that tracks ad-blocking, estimated that blockers will cost publishers nearly $22 billion in revenue this year. Nearly 200 million people worldwide regularly block ads, the report said, and the number is growing fast, increasing 41 percent globally in the last year.

Il punto è, è immorale questa cosa? Secondo alcuni è ingiusto che i lettori decidano di bloccare la pubblicità, dato che è l’unico modo per certi siti di generare un guadagno e sopravvivere. Dal mio punto di vista, c’è pubblicità e pubblicità. I content blockers non sono altro che la risposta ai pop-up moderni: così com’è stato giusto, anni fa, offrire agli utenti la possibilità di bloccare gli abusati pop-up, è oggi giusto spiegare a quei siti che fanno uso di pratiche altrettanto indecenti che non siamo costretti a subire qualsiasi stronzata decidano di infilare nelle loro pagine. Un conto è un banner, tutto un altro conto è un banner che rimbalza sullo schermo, si chiude a fatica, inizia a riprodurre un video e mi blocca il contenuto che stavo tentando di leggere mentre nel frattempo mi scheda e inserisce in un database.

Questi siti la cui strategia è infastidire il lettore infestando le loro pagine con pubblicità invasiva, e raccogliere quante più informazioni sul lettore (ignaro), probabilmente avranno seri problemi a partire da Settembre. Ma è un problema mio o nostro? È un problema di Apple? Apple punta a offrire la migliore esperienza utente possibile, e questi metodi stanno davvero rovinando il web e la navigazione da Safari: il web è più lento, meno piacevole, e ricco di rischi a causa di queste pratiche. Le pubblicità spesso non sono semplici pubblicità ma pezzi di software, per non dire una specie di malware che raccoglie senza alcun consenso quanti più dati possibili sul visitatore. E questi malware costano traffico dati e privacy.

Per rubare le parole a Marco Arment:

Publishers, advertisers, and browser vendors are all partly responsible for the situation we’re all in. Nobody could blame the users of yesteryear for killing pop-up ad rates, and nobody should blame the users of 2015 for blocking abusive, intrusive, misleading, and privacy-stealing ads and trackers, even if it’s inconvenient for publishers and web developers. […]

Modern web ads and trackers are far over the line for many people today, and they’ve finally crossed the line for me, too. Just as when pop-ups crossed the line fifteen years ago, technical countermeasures are warranted.

Web publishers and advertisers cannot be trusted with the amount of access that today’s browsers give them by default, and people are not obligated to permit their web browsers to load all resources or execute all code that they’re given.

Ho resistito alla tentazione di bloccare la pubblicità a lungo, ma pochi mesi fa ho cambiato idea (sul Mac uso Ghostery). Credo non sia un dovere del lettore accettare qualsiasi cosa l’editore imponga, spesso in maniera poco trasparente. I content blocker permetteranno ai lettori di sapere cosa succede dietro le quinte e di intervenire se necessario. Ed è giusto così.

Se sei un utente Mac perdi all’incirca un’ora di batteria scegliendo Chrome invece di Safari, come i test di BatteryBox hanno dimostrato:

We measured the power consumption of watching videos on YouTube, browsing Reddit, streaming on Netflix vs Putlocker, creeping on Twitter and FaceBook, composing emails on services like Gmail and Hotmail, and searching for stuff on Google, Bing (yup, surprisingly, it’s still used), and DuckDuckGo. We used a factory-restored MacBook Pro Retina 13” to test each website on one internet browser at a time. No programs other than the browser were open.

Magari chi dice che Safari è il nuovo IE si dimentica che oltre all’aggiunta di features c’è altro?

Recentemente diversi sviluppatori web si sono lamentati dello stato di Safari — e della lenta adozione di tecnologie web che altri browser (come Chrome) sono più celeri nel supportare. Il problema, suggerisce Kenneth Auchenberg, si fa più accentuato perché Apple ancora non permette, nel 2015, di impostare un browser diverso da Safari su iOS — né esiste un’alternativa, dato che Chrome su iOS non è davvero Chrome: è sempre Safari, ma con una UI diversa.

Ciò costringe l’intera piattaforma a rimanere ferma allo stato del web che Apple ritiene soddisfacente:

It’s limiting the browser-vendor competition on Apple’s iOS platfrom, as Apple are the only one allowed to innovate within the browser engine. […]

It’s creates a big overhead for web developers as they forced to cater for mobile Safari’s slow update cycle, with hacks and workarounds for bugs and issues, that are fixed in other browsers. This is where the “new IE” reasoning has it’s roots.

La cosa è ridicola e sinceramente questa imposizione di stock apps (client di posta, anche) sarebbe ora che finisse.

Nolan Lawson si lamenta della lentezza e reticenza con cui Safari sta adottando tecnologie web emergenti (volte soprattutto alla creazione di single-page applications) che altri browser — non solo Chrome, ma pure IE — già da diverso tempo supportano:

I think there is a general feeling among web developers that Safari is lagging behind the other browsers. All of the APIs I mentioned above are not implemented in Safari, and Apple has shown no public interest in them. When you start browsing caniuse.com, the list goes on and on. […]

In recent years, Apple’s strategy towards the web can most charitably be described as “benevolent neglect.” Although performance has been improving significantly with JSCore and the new WKWebView, the emerging features of the web platform – offline storage, push notifications, and “installable” webapps – have been notably absent on Safari.

Dean Murphy, dopo aver sperimentato per pochi minuti con i content blockers:

After turning off all 3rd party scripts, the homepage took 2 seconds to load, down from 11 seconds.

Mi sembra chiaro da ciò perché Apple li abbia aggiunti su Safari. C’è un guadagno sostanziale in privacy e velocità.