Conforme se van asentando las bases de un nuevo modelo de producción de sitios y aplicaciones con la llegada de HTML5, nacen nuevas necesidades a las que grandes empresas como Google, como no, ya tenían previsto dar soporte o van solventando sobre la marcha.

Nuevos recursos, nuevas necesidades

Éste es el caso de nuevas propiedades de las hojas de estilos en cascada de tercer nivel, que desde hace ya aproximadamente un par de años vienen proponiendo soluciones desde el código CSS para problemáticas estrictamente visuales que se han ido asentando en la nueva cultura visual de la web participativa (bordes redondeados, sombras en los elementos, un mayor catálogo tipográfico, etc).

En concreto y actualmente, la regla @font-face —a través de la que el diseñador web puede proponer una mayor riqueza tipográfica para la web— tiene un soporte mayoritario por los actuales navegadores. Pero no todo es jauja. De esta ventaja nacen los siguientes problemas que se han de solventar:

• Cargar un archivo de fuente aumenta notablemente la tasa de transferencia de un sitio ya que cada visita suma al servidor las peticiones del archivo. Teniendo en cuenta las actuales velocidades de conexión, en principio esto afectaría sólo a sitios con un contrato modesto en su servicio de hospedaje.
• Al igual que otro tipo de material, los catálogos tipográficos cuentan con licencias y derechos de autor que no siempre promueven la filosofía del Creative Commons

De dónde venimos, a dónde vamos

Teniendo en cuenta estos factores y que anteriormente la regla @font-face tenía un soporte minoritario, dos grandes alternativas han sido hasta ahora sIFR o Cufón. Su continuidad es incierta, pero podríamos teorizar con su paulatino desuso por los siguientes motivos:

• sIFR depende de Flash —y Flash tiene un futuro incierto—. Además el juego completo de sIFR (archivos css, javascript, actionscript y objetos flash) es tanto o más pesado que embeber el archivo de fuente original.
• Cufón es menos pesado que sIFR, pero su implementación sigue siendo más tediosa que usar la regla @font-face.

Font Directory: las soluciones de Google y las posibles soluciones de otros

Así pues, es en este justo momento en que @font-face tiene mayor soporte por todos los navegadores y sitios de referencia implementan su aparición (p. ej: Smashing Magazine, algunas plantillas en Tumblr), cuando Google sorprende —no nos extraña, coincidiendo con su evento Google I/O 2010— con Google Font Directory: un catálogo tipográfico libre que podemos utilizar aplicando la regla @font-face sin necesidad de realizar las peticiones del archivo fuente a nuestro propio servidor. Solventando de esta manera las dos limitaciones que señalábamos anteriormente.

Dando un pequeño salto en el futuro y conociendo el rechazo que provoca el esfuerzo de omnipresencia que hace Google por acompañarnos en todas nuestras tareas como diseñadores y desarrolladores —y aún peor: en nuestro momentos de ocio en la red—, no sería de extrañar que algún aventurado emprendedor abra una cuña de mercado dando alternativas a este servicio.

Imaginad una empresa mediadora entre los derechos de autor de los catálogos tipográficos que ofrece servicios premium de gestión de fuentes (un buen catálogo y hospedaje) a desarrolladores; una especie de YouTube de las tipografías. Esta es la primera idea, si hay algún emprendedor en la sala seguro que se le ocurre alguna más.

Conclusiones

En cualquier caso queda patente que la llegada de HTML5 y el soporte total de CSS3 ofrecerán las ventajas que ya hemos releído en infinidad de sitios, abrirán la puerta a nuevos modelos de negocio —o el fomento de algunos ya existentes— y sobre todo enriquecerán el diseño de la red.