Reflexiones de Mark Crutch sobre el formato SVG

En la primera parte de su habitual columna sobre Inkscape, en las páginas 27 a 30 de la edición 118 de Full Circle, Mark Crutch hizo una pequeña disgresión y reflexionó sobre el pasado, presente y futuro del formato abierto que utiliza Inkscape, el de los Gráficos Vectoriales Escalables (SVG).
Es una reflexión muy clara e interesante, por lo que con la ayuda de Google translate más algunos ajustes y correcciones propios, la traduje y aquí está:

Voy a tomar un pequeño desvío del formato habitual para la primera parte del artículo de este mes y voy a  hablar de política. No sobre Trump, el Brexit o el surgimiento del populismo, sino más bien de la política de los formatos abiertos y los navegadores.
En primer lugar, una lección de historia muy breve (y simplificada): SVG, el formato de archivo utilizado por Inkscape, fue creado bajo los auspicios de la World Wide Web Consortium (W3C) - la organización que también se encargó de crear las especificaciones de HTML y CSS.
HTML ya era un lenguaje establecido, pero vagamente definido, y con una gran cantidad de diferencias entre las distintas implementaciones de los desarrolladores de navegadores. El W3C ordenó las cosas, pero al final decidió que la mejor manera de hacer que todo el mundo escribiera bien HTML para todos los navegadores, era efectivamente abandonar el lenguaje indisciplinado en el que se había convertido y pasarse a una alternativa definida y rigurosamente estructurada: el XHTML . Esto también fue parte de un plan más amplio para promover XML, que puede ser pensado como un lenguaje para definir lenguajes. XHTML fue HTML reeditado como un lenguaje XML, o sea con más posibilidades de interoperabilidad con otros lenguajes XML, incluyendo el SVG.

Tan académicamente puros como fueran los objetivos de XHTML, cayeron en el mundo real. HTML había prosperado tanto, en parte, por su laxitud. Los navegadores harían lo posible por interpretar incluso la sintaxis más malformada, lo que reduciría considerablemente la barrera de entrada para que los no-programadores crearan sus propias páginas web. Bajándola aún más estaban las aplicaciones como Dreamweaver y HoTMetaL, las que permitían a los usuarios crear páginas web con la misma facilidad con la que hacían un documento de texto en Word. HTML continuó proliferando en línea, y habría sido un suicidio comercial para cualquier navegador pasarse exclusivamente a XHTML. A pesar de su pureza y superioridad técnica, XHTML perdió inevitablemente frente al estándar más holgado, y el trabajo de la W3C se volvió, en gran medida, irrelevante. Estaba claro que el enfoque de definir primero una serie de estándares para escribir las especificaciones, y sólo después que los navegadores las implementaran, no era el que funcionaría en la práctica.

Lo que siguió fue un período de estancamiento para la web. Ningún navegador quería introducir una sintaxis radicalmente nueva en HTML o CSS por temor a volver a encender los malos viejos tiempos de las extensiones propietarias. Pero finalmente, las compañías de navegadores comenzaron a discutir entre sí sobre formas de hacer avanzar a la web otra vez. El resultado fue la formación de otro organismo de normalización: WHATWG, cuyo objetivo era mejorar las antiguas especificaciones HTML, documentando lo que los navegadores ya hacían, facilitando a todos los proveedores la compatibilidad de sus programas con el mismo nivel de cumplimiento. También agregaron algunas características nuevas al HTML, rebautizándolo como "HTML5". Aunque ya hace varios años de eso, muchas de sus ideas más útiles aún no han sido implementadas universalmente (¿cómo va eso de los recolectores de la fecha y hora, Mozilla?).



Dadas las circunstancias, el W3C renunció a su enfoque filosófico hacia la pureza del XHTML, y se sumó al trabajo de WHATWG, de tal manera que el estándar HTML ahora está nominalmente de vuelta en sus manos. Pero estructuralmente, las cosas han cambiado: el W3C ya no puede escribir especificaciones y esperar que los navegadores las implementen; ahora las empresas de navegadores acuerdan entre sí sobre qué implementar y luego se escribe la especificación para que coincida con esas implementaciones. Es cierto que lo simplifiqué mucho y que en la práctica tiene más matices, pero el punto central es que, en estos días, las especificaciones están, en gran parte, impulsadas por lo que los navegadores están preparados para implementar.

Esto tiene un impacto en Inkscape porque, como editor SVG que es, su conjunto de funcionalidades sigue las capacidades escritas en la especificación SVG. Pero la especificación SVG, en la práctica, no puede agregar ninguna nueva capacidad sin el apoyo de las empresas que desarrollan los navegadores.
Sin embargo, estas empresas están reacias a implementar muchas de las nuevas características dado que hay escasos archivos en línea que los utilizan. Los usuarios, por su parte, son igualmente reacios a crear contenido utilizando estas nuevas características, ya que ningún navegador las soporta. Las herramientas de creación (como Inkscape) desean implementarlas, pero sin el soporte de los navegadores, es poco probable que la especificación sea finalizada y soportada, ya que cualquier trabajo que hagan podría quedar obsoleto si la especificación cambiase.

Y así vamos dando vueltas en círculos: sin archivos en línea que utilicen las nuevas funciones no hay soporte para las mismas de parte del navegador; sin soporte por parte del navegador las especificaciones no se estabilizan; las especificaciones inestables hacen que las herramientas de creación sean menos propensas a soportar las nuevas características; sin soporte de las nuevas características en las herramientas de creación hace que los usuarios tengan menos probabilidades de crear y publicar archivos que utilicen esas nuevas funciones; sin archivos en línea que utilicen las nuevas funciones no hay soporte para las mismas de parte del navegador... y así sucesivamente.

Para ser justos, un soporte limitado para las nuevas características SVG ha sido agregado a los navegadores - pero sobre todo en las áreas donde el Grupo de Trabajo SVG ha renunciado a la propiedad con el fin de mover la función a las CSS. Esto es tanto una buena como una mala noticia: CSS es una de las piedras angulares de la web, por lo que añadir características allí, en lugar de en el SVG, hace que sean más propensas a ser adoptadas por los navegadores; por otra parte, debilita aún más la posición del SVG como un formato autónomo, y requiere que las aplicaciones que no sean del navegador cumplan con estándares que a menudo no se acomodan fácilmente fuera del entorno web, debilitando la posición del SVG como un formato de archivo independiente.

Con más características trasladándose a las CSS y con los desarrolladores mostrando poco interés en la implementación de aquellas que siguen siendo parte del SVG, se ha llegado a hablar de no renovar la concesión al Grupo de Trabajo SVG más allá de un corto período para estabilizar el trabajo que se ha hecho en la especificación SVG 2 en el último par de años. Eso significaría  que no habría SVG 3, ni nuevas características en el futuro. Teniendo en cuenta cuántas buenas ideas fueron quitadas del SVG 2 con la promesa de que podrían ser instauradas en especificaciones posteriores, esto sería una tragedia.
Claro, es probable que Inkscape continúe, incluso agregando extensiones propietarias al SVG para soportar nuevas características en el tiempo por venir. Pero la promesa de un formato vectorial abierto que podría ser utilizado en distintas aplicaciones y renderizado de forma nativa en la web, habría muerto.

¿Hay algo que nosotros, usuarios y defensores de los formatos abiertos, podamos hacer para ayudar a asegurar que el SVG tenga un futuro? Dado que está, en gran parte, en manos de los desarrolladores de navegadores, lo mejor que podemos hacer es mostrarles que existe una demanda por ese formato y por las nuevas características que se le están haciendo.
Necesitamos crear más documentos SVG que, en particular, hagan uso de características propias de la especificación SVG 2, y publicarlos en línea. Y tenemos que motivar a otros a hacer lo mismo. Aunque este enfoque no está exento de problemas.

La especificación SVG 2 aún no está finalizada. La creación de documentos utilizando la versión actual podría hacerlos obsoletos si hay cambios adicionales en la especificación antes de la ratificación final. Por lo tanto, dentro de un año, cualquier archivo que cree ahora puede requerir algunas correcciones y ajustes  (esperemos que menores) si todavía está en uso. Un problema más grande para la mayoría de la gente es, en primer lugar, cómo crearlos. La codificación manual de SVG es ciertamente posible, pero probablemente no sea una opción práctica para la mayoría de la gente, lo que significa que la única manera de obtener nuevas funciones en sus archivos es esperar a que estén disponibles en las herramientas de creación. Afortunadamente, Inkscape está, en cierta medida, liderando el camino en este enfoque.

La reciente versión 0.92 de Inkscape agrega soporte para renderizar varias funciones del SVG 2, aunque, lamentablemente, el soporte de la interfaz de usuario para crearlas en primer lugar es algo más limitado.
Sin embargo, hay un par de características del SVG 2 que ya puede empezar a utilizar en sus dibujos de Inkscape: la primera de las cuales trataré en este artículo y la segunda en el próximo.

Para completar la lectura de este artículo en su versión original (en inglés) lo invito a descargar el pdf de la edición 118 de la Full Circle Magazine. El artículo se encuentra en las páginas 27 a 30.