Ya comentamos el concepto y el origen de los vendor prefixes, prefijos agregados a las propiedades de nuestras hojas de estilo para usar características CSS en fase de prueba. Los vendor prefixes siempre son recomendables para garantizar una mejor compatibilidad cross-browser, pero son especialmente importantes cuando sabemos que nuestros usuarios nos visitarán desde navegadores desactualizados. Al mismo tiempo, los desarrolladores de motores (los vendors en cuestión) usan estos prefijos para proponer implementaciones o sintaxis de características que pueden mejorar las que existen actualmente. En algunos casos, incluso «inventan» características tan buenas que terminan siendo adoptadas oficialmente. Sin embargo, los vendor prefixes son motivo de debate por varias razones:

• Hacen más repetitiva la hoja de estilos, volviéndola más pesada y difícil de mantener. Además, una vez que la propiedad adquirió la categoría de estándar y es ampliamente soportada por los browsers de nuestros usuarios, ya no tiene sentido conservar los prefijos, pero son pocos los desarrolladores que se toman el trabajo de eliminarlos.
• Algunos prefijos se orientan a motores utilizados por varios browsers al mismo tiempo, y esta variedad de browsers puede introducir diferencias visuales. Un caso especial es el prefijo -webkit-, que abarca a Chrome, Opera y Safari. Cabe destacar que, si bien Safari usa el motor WebKit, los dos restantes usan Blink, que es un desprendimiento de aquel.
• Algunas características son exclusivas de un motor y no terminan utilizándose en otros. En estos casos, la propiedad sólo funcionará para los usuarios de ese motor, lo cual supone una inconsistencia.

A pesar de estos problemas, los vendor prefixes seguirán existiendo en la medida en que los browsers incorporen propiedades CSS aún no estandarizadas por el W3C, un proceso que suele ser muy lento. Por eso, es bueno conocer algunas maneras de incorporar vendor prefixes a nuestros estilos:

Agregado manual

A través de las tablas de compatibilidad de Can I use podemos saber qué propiedades CSS necesitan prefijo, y para qué casos. Así podremos agregar manualmente solo los prefijos que creamos pertinentes en función de los browsers que utilizan nuestros usuarios, repitiendo la menor cantidad de código posible. Este proceso, sin embargo, es muy trabajoso cuando nuestra hoja de estilo tiene un volumen considerable.

Agregado automático

Hay varias aplicaciones que procesan nuestra hoja de estilo, originalmente sin prefijos, para agregarlos donde sea necesario:

• Prefixr. Con esta herramienta online, solo es cuestión de copiar y pegar nuestro código CSS para obtener una versión con los prefijos agregados. Tiene la ventaja de no requerir de ninguna biblioteca externa, pero es necesario repetir el proceso ante cada modificación importante de nuestro CSS.
• Autoprefixer. Este plugin tiene la ventaja de que podemos configurarlo para que soporte un rango de browsers determinado. Además, evalúa la necesidad de usar prefijos a partir de la base de datos de Can I use, confiable y en permanente crecimiento.
• -prefix-free. Este script no es tan configurable, pero es liviano y solo basta con invocarlo desde nuestro markup para que agregue prefijos a toda propiedad posible.

A pesar de que los vendor prefixes satisfacen una necesidad, algunos vendors están empezando a eliminarlos: hay una tendencia a deshabilitar por defecto las propiedades experimentales (el usuario tiene la opción de habilitarlas) y a usar solo aquellas cuya implementación ya esté suficientemente establecida.

Durante muchos años, los desarrolladores web trabajaron sobre la premisa de que la enorme mayoría de los usuarios entraba a sus sitios desde Internet Explorer, a través de una computadora de escritorio. Con la aparición de nuevos navegadores, que podían presentar diferencias enormes al mostrar la misma página, muchos optaron por desarrollar versiones alternativas de sus sitios o, peor aun, exigir la instalación del browser de Microsoft como condición excluyente para una buena experiencia de usuario. Hoy, que la diversidad de navegadores y dispositivos parece crecer sin límite, no hay mejor opción que el enfoque cross-browser: intentar que el mismo sitio funcione bien, y de manera uniforme, en la mayor cantidad de plataformas posible.

Las diferencias visuales entre navegadores vienen dadas por sus motores de renderizado: piezas de software que se encargan de representar las páginas web interpretando el código escrito en lenguajes de marcas (HTML, XML, etc.) y de estilos (CSS, XSL, etc.), además de cargar otros tipos de contenido (como archivos de imagen, sonido u otros, para los cuales puede ser necesario un plug-in). Estos motores están programados en lenguajes con características de bajo nivel y se comunican, generalmente a través de alguna aplicación intermedia, con el sistema operativo sobre el cual se ejecuta el browser.

Algunos browsers diferentes utilizan el mismo motor de renderizado, lo que determina que muestren las páginas de manera similar. Por ejemplo, Chrome y Opera usan el motor Blink, que a su vez es un desprendimiento del motor WebKit, utilizado actualmente por Safari. Sin embargo, esto no es razón para confiarse, ya que los browsers principales tienden a desarrollar sus propios motores. Así, Firefox usa Gecko e Internet Explorer, Trident.

Cada motor suele introducir características de CSS no aceptadas oficialmente, o bien todavía en fase experimental. Sin embargo, otro motor puede no haber introducido estas características, o bien haberlas implementado de manera totalmente diferente. Para evitar conflictos es necesario aclarar, en la sintaxis, para qué motor en particular estamos escribiendo la regla. Esto se logra anteponiéndole a cada propiedad un prefijo que indique el browser o el motor de destino. Estos prefijos son conocidos como vendor prefixes. Por ejemplo, cuando los navegadores todavía no habían adoptado ampliamente los bordes redondeados, era indispensable usar esta propiedad de la siguiente manera:

-moz-border-radius: 12px 6px;              /* Sólo Firefox */
-webkit-border-top-left-radius: 12px;      /* Sólo Webkit */
-webkit-border-top-right-radius: 6px;           /* Sólo Webkit */
-webkit-border-bottom-right-radius: 12px;       /* Sólo Webkit */
-webkit-border-bottom-left-radius: 6px;    /* Sólo Webkit */
border-radius: 12px 6px;             /* sintaxis correcta */

Hoy, a cualquier navegador le basta con la última línea, que no tiene ningún prefijo, para representar bordes redondeados. Sin embargo, muchas propiedades todavía no han sido estandarizadas, y siempre habrá usuarios que ingresen desde navegadores desactualizados. Por eso, en el próximo artículo comentaremos algunos métodos para facilitar el agregado de vendor prefixes.