Secondo me l’approccio è piuttosto interessante. Evidenzia i due momenti principali di come funziona la lettura: fissazioni e saccadi. Il grassetto porta l’occhio a fissare quella/e lettera/e; il grassetto successivo è l’atterraggio della saccade sulla nuova fissazione.
Il fatto di poter modulare la lunghezza delle saccadi (e quindi non evidenziare tutte le parole ma solo alcune ogni tanto) così come l’intensità della fissazione (il numero di lettere evidenziate) dovrebbe adattarsi alle esigenze diverse dei lettori o delle situazioni di lettura.

Per la leggibilità questi sono solo due di tanti parametri. Nella demo offerta infatti l’autore ne inserisce molti altri (anche se ancora ne mancano a mio avviso!)

Ho provato l’API e il codice che restituisce l’aggiunta di tag b con due classi assegnate

<b class="b bionic">Lo</b>rem <b class="b bionic">ip</b>sum.

Per gestire diversamente le singole lettere (magari con diversi valori di un font variabile o con altre modalità di evidenziazione) non è possibile farlo solo con il CSS (raggiungo solo la prima lettera con ::first-letter) per le lettere successive mi sa che devo ricorrere a JavaScript…

Sono curiosa di vedere come sarà l’estensione per browser che hanno annunciato.

Contesto: secondo me va visto come uno strato successivo ad una pagina web per leggere meglio un testo lungo, che ciascuno deve calibrare a proprio modo. Non ha senso pubblicare una pagina con scelte predefinite su questo piano di saccadi e fissazioni (per tutto il resto della web typography sì eh però!)

Visto che mi hai chiamato in causa Giorgio, buttò lì un punto per le principali caratteristiche visive che un sito dovrebbe avere.

Io ai primi posti della lista dei desiderata metterei la dimensione dei font. Mi sembra che sia determinante per la leggibilità (assieme ad un buon contrasto di colore con lo sfondo).

Ancora prima di pensare di adattare la dimensione alle varie dimensioni dello schermo e dunque alla presunta distanza di lettura (Responsive Web Typography) bisognerebbe rispettare le volontà espresse dall'utente.
Per la dimensione del font occorre abbandonare la pratica di utilizzare i pixel come unità di misura.
Meglio usare unità di misura relative come rem/em/ch.
Si può assegnare a :root o html il valore font-size in rem e poi tutti gli altri elementi a cascata ad esempio in em, così saranno relativi al primo valore che non è deciso dal designer ma dall’utente nelle preferenze del proprio browser.

È vero che gli utenti possono ormai in tutti i browser utilizzare lo zoom, ma perché costringerli a questa pratica quando si può rispettare “nativamente” lo loro scelta?

Ora però viene la domanda vera: in quanti oggi modificano le impostazioni del browser relativamente alle dimensioni dei font?
Alcuni hanno provato a misurare questa percentuale di utenti (l’anno scorso si parlava del 3%).
Voi che impressione avete? Ad esempio voi, da utenti, lo fate (per i browser desktop intendo)?

Sì, credo che se desideri testare anche la resa dei font ti servano non degli emulatori ma ti occorra proprio fare un test possibilmente sui device reali, o almeno macchine virtuali che riproducano i vari sistemi operativi. Credo che servizi come Browser Stack o Sauce Labs o simili facciano questo, o almeno offrono un mix di questo.

Ciao Muvadi,
ho indagato un po’ meglio la questione subsetting su Google Fonts creando un test.
Lo trovi qui: jsfiddle.net/webmatter/t8coLd6h/
Poi ho fatto delle prove di visualizzazione su iPhone4 e iPad2 a seconda del subset caricato.

Ecco cosa ho testato in particolare:
(1) subset solo Cyrillic
(2) subset solo Cyrillic-ext
(3) subset come suggerito da Google: Cyrillic, Cyrillic-ext, Latin
(4) nessun subset (il caso che avevi tu all’inizio mi pare di capire)

Ecco l’esito su iPhone/iPad
(1) Nel primo caso alcuni glifi non si vedono ma quelli che si vedono sono in Roboto Slab
(2) Nel secondo caso si vedono bene tutti i glifi e sono in Roboto Slab
(3) Nel terzo caso si vedono bene tutti i glifi e sono in Roboto Slab
(4) Nel quarto caso alcuni glifi hanno un quadratino, quelli che si vedono non sono in Roboto Slab

Esito su desktop
Su desktop sembra che anche il semplice default (caso 4 = no subsetting) invece di fornire il consueto insieme Latin offra già Cyrillic-ext. Questo probabilmente ti ha tratto in inganno perché sul desktop vedevi comunque i caratteri senza averli esplicitamente richiesti all’api.

Quindi, a seconda di quali caratteri ti servono puoi scegliere in teoria fra la soluzione 1 o la 2.

Ora si apre una questione: meglio indicare solo il subset che interessa o tutti i subset a costo di essere ripetitivi?
La soluzione 3 è quella suggerita da Google anche se Cyrillic-ext dovrebbe comprendere Cyrillic che a sua volta dovrebbe contenere Latin (e infatti il peso nel “velocimetro” non cambia).
Se Google suggerisce di esplicitare tutte le voci anziché indicare l’insieme più grande avrà dei suoi motivi. Non mi è chiaro…
Qualcuno ha notizie/esperienze in merito?

Ciao, metto lì un’ipotesi.

Se non visualizzi il font come roboto slab SOLO per i caratteri cirillici e SOLO su iPhone/iPad probabilmente il problema riguarda la versione SVG del/dei font che non forniscono il subsetting dei glifi del cirillico.
Mi è capitato di leggere che talvolta c’è una discrepanza fra i glifi mostrati e il subsetting effettivamente fornito dall’api di Google.

Ti chiedo: puoi specificare la stinga esatta usata per richiamarli?
In particolare mi sembra rilevante capire quale subset stai usando: cyrillic o cyrillic-ext e quali pesi.

Per capire se il problema è di Google potresti fare una prova installando sul server il webkit di FontSquirrel selezionando tutti i glifi (no subsetting). Se così funziona allora mi sa che il problema è del font sul servizio di Google Font e non di roboto slab o della tua specifica implementazione.

Ciao, mi sa che ci ha pensato Google
Il problema che riscontri è su Chrome per Windows?

Se così, è un problema noto agli sviluppatori di Chrome e dovrebbe riguardare molti font (non solo l’ottimo Raleway – piace molto anche a me). Sembra che con la versione 37 (uscita in beta pochi giorni fa: blog.chromium.org/2014/07/chrome-37-beta-directwrite-on-windows.html) l’annoso problema sia finalmente risolto poiché hanno cambiato il motore di rendering.
Fin ora le tecniche usate per ovviare al problema erano più o meno di due tipi.
Tecniche valide solo nel caso di web font self-hosted riguardanti il comando @font-face.
Ad esempio:

1. usando solo EOT e TTF (no SVG, no WOFF) - Pablo Carrau
2. caricando nell'ordine EOT,WOFF,TTF,SVG e poi ricaricando SVG sotto media query - Jaime Fernandez
3. caricando in questo ordine: EOT,SVG,WOFF,TTF – Fontspring
   Oppure, per i font ospitati su siti di terze parti, si cercava di migliorare la resa con alcune proprietà CSS come text-stroke, text-shadow, font-smoothing.
   Trovi molto bene spiegato qui: stackoverflow.com/questions/11487427/is-there-any-font-smoothing-in-google-chrome.

Nel frattempo se hai la versione di Chrome inferiore alla 37, puoi fare dei test.
Se ti va, prova questo che ho allestito su jsfiddle.net/webmatter/QK2Np/ con text-stroke e text-shadow su nero o su bianco con font Raleway a vari pesi. Sembra incidere molto anche la dimensione del font oltre al contrasto con lo sfondo.
Occorre trovare una tecnica/combinazione di colori, spessori, sfumature per ciascun caso mi sa. Se trovi qualcosa che ti soddisfa mi piacerebbe saperlo.

Nome e Cognome: Giulia Laco
Titolo: Webfont: un potenziale ancora inespresso - come sceglierli, acquistarli, proporli
Descrizione: I webfont sono utilizzabili già dal 2010, ma perché non sono ancora sfruttati appieno nel web contemporaneo? Eppure sono un’opportunità esaltante per la grafica, la brand identity, l’usabilità, l’accessibilità, la leggibilità, il multilingua, il multidevice, i siti CMS-driven, la SEO e la performance dei siti. Excursus su come scegliere, acquistare, proporre i webfont consapevolmente in un mercato in crescita esplosiva. Per SEO e non solo.
Tipo: Tecnico
Sala: Aspetto e Contenuti