Hello mug

Webfont & Firefox, più altre minuzie

Ho speso un paio d’ore a fare prove di conversione da font open type/true type a webfont (nei vari formati), provando con FontXchange e con vari servizi online. Qualche post sotto citavo Fontsquirrell (che converte in base64, come piace a Firefox), ma l’output è indigesto ad iOS (che visualizza gli .svg). Allora ho provato il primo che mi è capitato a tiro, Font2Web, e sorpresa, i font vengono visti su iOS. Ma non più su Firefox.

Insomma ora i font vanno perfetti su Webkit (anche Canary), persino su Opera (dove noto che vengono caricati prima i font di default/fall-back e poi i webfont), ma su Firefox sono del tutto andati (screenshot).
Su iOS, League Gothic (titoli e meta) si fotte quando è settato in small caps :)) Perchè il font non li ha di per sè, suppongo (e infatti la visualizzazione degli small caps è approssimativa ovunque). I titoli dei link post vengono visualizzati quindi (quindi?) in… Georgia? O Georgia o PolyRegular, troppo complicato verificare su iOS. Il fall-back sarebbe Varela Round, un Google font, e i Google fonts sono tutti bulletproof, vanno ovunque. Ma Safari mobile non lo prende quando è in fall-back, mentre lo visualizza correttamente quando è impostato come primo font (i link qui a sinistra). Sembra invece che si peschi il font che è primo nella cascata css, quindi PolyRegular (o il fall-back Georgia).

Tutto questo si risolve con TypeKit o FontDeck, ma non voglio spendere un euro per un sito che uso come giocattolo e non fa accessi. E poi mi piaceva il combo League Gothic + Poly Regular/Italic. Poly è splendido, è un lavoro per una tesi di laurea di un designer argentino, ma non ha un supporto estesissimo a tutte le lingue. Con l’italiano, casca sugli accenti. Sigh. Di League Gothic non ho un sostituto degno, ho fatto qualche prova e nessuno che sia equiparabile come proporzioni, tutti con x-height troppo più basso, anche i compressed.

Per ora non ho idea (e voglia!!) di che altro posso provare per far andare questi webfont su Firefox. Posso provare altre conversioni, ma ormai mi pare che se sistemi una cosa ne scombini un’altra. Dover scegliere se supportare Firefox o iOS (e nemmeno perfettamente, su iOS) per me è fin troppo facile… Ammazzerei subito Firefox :) MA.

UPDATE

Ho sostituito Poly con la versione distribuita da Google fonts. Firefox in questa salsa lo vede regolarmente. Il problema quindi è tutto nel come si convertono i file, visto che quelli di Poly forniti in kit da usare con @font-face non andavano (parlo sempre di Firetox, Webkit era ok).
Per League Gothic, ho risolto di rinunciare agli small caps e fare gli h2 dei link post direttamente in maiuscolo. Compromessi o sconfitte? 

@font-face rendering

Con Firefox mille problemi. È schizzinoso sul file location, se i file non sono nella root del sito non li carica. Idem, root o meno, se sono dichiarati in @media screen. Idem se i webfont non sono encodati in base64. Fontsquirrel fornisce un servizio di conversione di font in webfont che usa questo encoding. Ho testato file generati con FontXChange (quello che uso quando mi do alle sperimentazioni di font illegali prima di comprare l’eventuale licenza) o forniti direttamente in un kit: effettivamente, non li digerisce. FontXChange inoltre genera un .css con sintassi un po’ approssimativa che già da sola impedisce la visualizzazione su Firefox (anche con conversioni corrette). Gli stessi file convertiti con Fontsquirrel, in base64, vanno. 

Safari:

Safari

Chrome Canary (webkit filters sulle immagini)

Opera Next!

Firefox:

E tra l’altro, you get what you pay for:

Sciatterie tipografiche

UTF-8 e caratteri unicode in HTML

Con <meta charset="utf-8"> un documento HTML dovrebbe visualizzare correttamente i caratteri unicode, opportunamente encodati. Il titolo di questo blog ad esempio, 𝓱𝓮𝓵𝓵𝓸, unicode, in HTML è tradotto con:

&#55349;&#56561;&#55349;&#56558;&#55349;&#56565;&#55349;&#56565;&#55349;&#56568;

Tuttavia, è possibile che la visualizzazione non sia sempre corretta. Reeder, Safari, e in genere tutto quello che ha un motore di visualizzazione web view su Mac visualizza i caratteri correttamente. Su iOS invece no.

Soluzione? In caso di blog su Tumblr, nessuna (o almeno, la vedo difficile). È infatti risolvibile solo tramite web server, dove generalmente l’interferenza è in Apache o .htaccess.

Navigazione da tastiera con jQuery: ci siamo ✔

Devo tutto a Federico! Dopo varie prove ha trovato la soluzione e ora va una bellezz’ ;)

$.noConflict();
jQuery(document).ready(function ($) {
    
    $(document).keydown(function(e) {
        var url = false;
        if (e.which == 37) {  // Left arrow key code
            url = $('a[rel=prev]').attr('href');
        }
        else if (e.which == 39) {  // Right arrow key code
            url = $('a[rel=next]').attr('href');
        }
        if(url)
            window.location = url;
    });
});

Su JSFiddle (che è troppo comodo) c’è il suo snippet commentato che spiega dove era l’inghippo e come l’ha risolto. 
Ovviamente, ça va san dire, non dimenticate di attaccare jquery.js nell’head :)) O su un vostro server direttamente (io faccio così), scaricandolo da jQuery.com. O pescandolo da Google (come Federico): 
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>.

Che sudata :) 

Navigazione da tastiera con js/jquery

Come in Flickr, ad esempio. Snippete:

document.onkeyup = KeyCheck;
   function KeyCheck(e)
       {
           var KeyID = (window.event) ? event.keyCode : e.keyCode;
           switch(KeyID)
           {
              case 37: window.location = "{PreviousPage}";
              case 39: window.location = "{NextPage}";
           }
        }

Dovrebbe abilitare la navigazione da tastiera tra pagina successiva (freccetta dx) e pagina precedente (freccetta sx). Invece fa ricaricare la pagina. Chi sa dirmi perchè, mail o ヒwiﾋﾋer.

Ho provato anche altre soluzioni (una l’ho messa su JSFiddle), credo che il mio problema sia che non so bene come indirizzare quel window.location sul link preciso. Qui ho lasciato direttamente i tag di Tumblr, convertiti vengono fuori come <a rel="prev" href="precedente.html"> e  <a rel="next" href="successivo.html">.

Signora, a sua figlia mancano proprio le basi.

Update
Mi hanno dato una mano, anzi, varie mani, @MisterJack e @federicoq e nessuna soluzione funziona. A questo punto credo che sia Tumblr. Probabile che intercetti left/right per i post multiphoto (che io non ho nemmeno implementato perchè non mi interessano). Del resto non trovo temi nemmeno su ThemeForest che abbiano abilitata la navigazione da tastiera.  RISOLTO. [vedi] 

Geo metadata

Google li ignora, Bing no.
Sebbene un’utilità pratica e immediata non sia scontata per il “sito medio”, è un modo di presentare dati in forma strutturata (e interoperabile1), fornire un’informazione non direttamente pertinente al contenuto del documento, una marcatura semantica in più. The semantic web is a web of data2.
Filosofia a parte. Come si fa? Con questi metatags nell’<head>, per una marcatura generale, o con microformats altrove dove serva (un post, una pagina about o contact).

<meta name="DC.title" content="The Quartiers"/>
<meta name="geo.region" content="IT-NA" />
<meta name="geo.placename" content="Napoli" />
<meta name="geo.position" content="40.8;14.2" />
<meta name="ICBM" content="40.8, 14.2"/>

Le coordinate sono ricavabili da un generatore qualsiasi (Geo Tag Generator, ad esempio).
Il primo meta DC.title fa riferimento allo standard Dublin Core.

Enjoy responsibly ;) Occhio alle coordinate, che non puntino dritte dritte al bagno di casa vostra.

  1. accessibili cioè da software che non siano esclusivamente il browser, come ad esempio un’applicazione calendario o contatti: se inseriamo metadata relativi a una data o a nostre informazioni (tipo vCard), queste saranno accessibili al di là del contenuto del documento HTML ↩

  2. The Semantic Web is a web of data. There is lots of data we all use every day, and it is not part of the web. […] The Semantic Web is about two things. It is about common formats for integration and combination of data drawn from diverse sources, where on the original Web mainly concentrated on the interchange of documents. It is also about language for recording how the data relates to real world objects. — da W3C.org, 2001 ↩

Automatic feed detection in Safari

In HTML5 la dichiarazione dell’attributo type nei elementi link e script è superfluo, e quindi il loro uso andrebbe deprecato.
Tuttavia, Safari non rileva la presenza di un feed automaticamente se la sintassi usata, in un doc HTML5, omette di dichiarare un  type="application/rss+xml".

Nella pratica, nella barra degli indirizzi verrà visualizzata solo l’icona della funzione reader di Safari, tenendo premuto non apparirà la voce di menù per sottoscrivere il feed.

E quindi che volevo dire? Uno, che mi pare una ca**ta da parte di Apple privilegiare una loro funzione specifica (reader) su una funzione standard (RSS). Due, che è ridicolo che il loro browser richieda una sintassi sorpassata per far accedere l’utente a una funzione. HTML5 dilaga da almeno un anno e Safari su questo ancora non si adegua.

Velo pietoso su quei browser (su quel browser, Chrome) che i feed nemmeno li rilevano e lasciano all’utente la ricerca sulla pagina di un link, e a chi sviluppa l’obbligo di metterlo.

Favicon & Feedburner

Se in un newsreader il feed del vostro bloggolo/tumbolo non appare associato a una favicon benchè voi ce l’abbiate messa nell’head del vostro template, è perchè Feedburner va a cercarsi un .ico, antiquato formato proprietario Microsoft, roba da 90’s. Se non lo trova niente icona, nonostante voi abbiate messo la vostra favicon.png.

Stupisce sempre la cura dei dettagli che hanno in Google.


pagina 1 di 2, puoi navigare da tastiera con ← e →

Following:

© 2007–2013 Gustomela.net heart Don't believe the hype.