El estándar Unicode define más de mil puntos de código que admiten dos presentaciones: textual o como emoji. La elección entre una y otra depende de un carácter invisible llamado selector de variación (Variation Selector-15, U+FE0E, para forzar texto; Variation Selector-16, U+FE0F, para forzar emoji). El problema es que la mayoría de programas no insertan estos selectores de forma automática, así que el mismo carácter puede aparecer como pictograma en un navegador de escritorio y como emoji en un lector RSS o un dispositivo móvil.
El artículo parte de un caso concreto: la flecha de retroceso a nota al pie (U+21A9) que el autor de un blog veía correctamente en su escritorio pero se transformaba en emoji en su teléfono. Aunque para casos técnicos la solución más fiable es añadir el selector de variación U+FE0E directamente en el HTML —algo posible si se controla la herramienta que genera las páginas, como hace el autor con Kramdown—, la pieza también examina alternativas menos fiables.
Entre ellas, la propiedad CSS font-variant-emoji (todavía no soportada en Safari) permite indicar la presentación preferida por elemento del DOM, y usar font-family: monospace en algunos contextos fuerza la versión textual, aunque solo en una dirección y con resultados visuales variables.
El autor, Benjamin Wil, documenta además una muestra de los más de mil codepoints afectados —desde © hasta símbolos como ⌨, ☃ o 🍼— y recuerda que el propio Unicode Technical Committee ha reconocido que los selectores de variación se han vuelto un mecanismo más complejo de lo deseable. Para quienes escriben en la web, no existe aún una experiencia de usuario clara: ni el autor ni el lector saben con certeza qué apariencia verá el otro.