Hmmm ... no. Si el único problema es el hecho de que   (U + 2009) todavía se está rompiendo, yo prefiero usar:
<span style="white-space:nowrap"> </span>
para corregir el comportamiento de ruptura. ¿Por qué?
Debido a que el francés bien está eficazmente usando una anchura de casi fija entre un sexto a un cuarto de un cadratin (0,166 ca. a 0,25 ca., cuando el espacio estándar es de 0,5 ca.) La elección de el ancho depende del enfoque ya presente dentro de los glifos definidos en una fuente determinada.
Fuentes se hacen para ajustar la anchura de su espacio delgado (U + 2009): si estas fuentes fueron hechas por typographs franceses (para la representación francesa), los approche (o espacios entre las letras en palabras) es más estrecho que en las fuentes diseñadas para inglés: esto es porque los textos franceses generalmente contienen más letras que textos equivalentes en inglés (por ejemplo, la Biblia impresa), y para evitar aumentar el número de páginas impresas, los glifos en las fuentes francesas se hicieron un poco más estrechos y con un enfoque reducido; para compensar esta reducción, se aumentó el tamaño del francés. (A menudo se dice que U + 2009 es una quinta parte de un cadratin, es decir, 0,2 ca., pero esto es incorrecto ya que este valor es solo un valor medible razonable, que debe ajustarse efectivamente en fuentes de acuerdo con su diseño).
En Inglés con una tipografía Inglés, los espacios entre caracteres es ya lo suficientemente grande como para justificar el hecho de que un espacio fino se utiliza en la mayoría de los textos cerca dobles signos de puntuación. Sin embargo, si se representa el francés con una fuente que utiliza una tipografía en inglés (que tiene espacios entre caracteres más grandes), fine debe ser más estrecha y debe reducirse a 1/6 de cadratin.
Así que sí, U + 2009 (  en el repositorio SGML) es ligeramente ajustable, dependiendo de las fuentes.
Además, puede estar justificado en parte (cuando se usa una justificación completa, donde no solo aumentan el ancho de los espacios interpalabras habituales, sino también todos los espacios entre caracteres y espacios normales o "finos" (pero los demás espacios quad no debe tener su anchura ajustada: que realmente están fijos)
Cuando se renderiza un documento cuyo diseño de página ya está previamente calculados (con fuentes conocidas y con métricas exactas), el espacio delgada (. U + 2009) ya es lo que desea (porque no tendrá que preocuparse por el comportamiento de ruptura.
Desafortunadamente, Unicode olvidó para asignar a estos espacios cuádruples U + 2000..U + 2006 (y al espacio delgado U + 2009) el comportamiento de no interrupción en las propiedades de salto de línea.
La única forma de que Unicode lo corrigiera (para documentos de texto sin formato), era agregar otro carácter, a saber U + 202F (el ESPACIO NO ESTRECHO ESTRECHO) en Unicode 5.1, que más tarde recibió el nombre simbólico SGML "nnbsp" para referencias de caracteres (pero el mapeo de esta entidad de caracteres nombrada a U + 202F no forma parte de ningún estándar HTML o XML, por lo que esta entidad nombrada no debe utilizarse también, a menos que su documento lo defina explícitamente en su DTD incrustada) !)
Pero desafortunadamente, la mayoría de los navegadores han olvidado aplicar esta adición y por qué fue necesaria: suponen que el carácter debe estar en las fuentes, pero claramente este no es el caso.
TODOS los navegadores DEBERÍAN tratar el U + 202F como no rompible (este ya es el caso, incluso si no conocen el carácter en su copia interna del UCD).
Sin embargo, los navegadores NO DEBEN depender del hecho de que U + 202F se defina en una fuente, en su lugar, DEBEN dar una respuesta a U + 2009 (ESPACIO DELGADO) al representarlo, cada vez que U + 202F no se mapea en la fuente actual, pero U + 2009 está mapeado en la misma fuente (este es generalmente el caso con muchas fuentes).
Este es un problema en los visualizadores HTML (es decir, los navegadores); También creo que esto es más que un simple problema de fuentes, es realmente un ERROR de navegadores (en lugar de un error o un límite en las fuentes), si no proporcionan tales retrocesos para los espacios en blanco. Por supuesto, todas las fuentes nuevas deben asignar U + 202F al mismo glifo que U + 2009.
Dado que el espacio delgado (U + 2009, o  ) está muy bien admitido en muchas fuentes, y tiene el ancho correcto para representar textos franceses con fuentes hechas con métricas tipográficas francesas, o para representar textos en inglés con inglés las métricas tipográficas, esta debería ser la alternativa correcta para usar cada vez que el espacio estrecho sin interrupción no esté disponible.
Puede emular perfectamente el comportamiento deseado de U + 202F en HTML, simplemente usando U + 2009 y haciendo que no se rompa utilizando CSS "white-space: nowrap". Siempre será mejor que cambiar el tamaño de fuente para mostrar un semitimizar de espacio (porque esto no es correcto con muchas fuentes para las que esto seguirá siendo demasiado grande, y también porque esto no funciona como se esperaba en tramos de texto que tienen fondos de colores: cambiar el tamaño de la fuente modifica la altura de la línea).
Así que por favor utilice este código en su lugar en el código HTML o SVG documentos (mantener a U + 202F sólo para documentos de texto sin formato):
<span style="white-space:nowrap"> </span>
Puede guardar esta secuencia en una plantilla reutilizable, que puede nombrar Template:nnbsp en MediaWiki, por ejemplo, para transcribirlo en sus páginas como {{nnbsp}}.
Tenga en cuenta que todavía es preferible hacer referencia al espacio delgado simbólicamente como   en lugar de forzar un punto de código Unicode exacta como  : la entidad con nombre puede reasignar por el procesador, o de acuerdo con las preferencias del usuario a otro espacio en blanco de trabajo.
Tenga en cuenta que MS-word realmente usa U + 2009 y no U + 202F para representar su propio bien. Es correcto, dado que los documentos de Word tienen un diseño precalculado, y dado que MS-Word aplica localmente el comportamiento de no interrupción al calcular el diseño de la página. Los documentos de Word no son documentos de texto plano.
- Exemple de renderizado (usando colores de fondo para mostrar que la línea de altura no se modifica, pero por desgracia, este sitio no permite el ajuste de colores de fondo excepto en
<code> secciones como aquí, que utilizan fuentes de espacio sencillo):
Exemple de « fine » insécable française correctement codée !
- la misma sin el contenedor
<code> no muestra el color de fondo, pero doe s utilizar las fuentes proporcionales normales, por lo que el espacio se vuelve delgada delgada efectivamente como:
Exemple de «Y thinsp; fina y thinsp;» française insécable y thinsp ;; correctement codée & thinsp ;!
- Ejemplo usando
  (NNBSP que por lo general no es compatible con la mayoría de las fuentes, pero esto puede llegar a trabajar con su navegador actual y las fuentes instaladas en el sistema, como DejaVu Sans):
Ejemplo de «& # x202F; fino & # x202F;» insécable française & # x202F ;; correctement codée & # x202F ;!
- Ejemplo usando
  (SEXTA CADRATIN, pueden funcionar, pero puede ser demasiado estrecha para sus fuentes, y no puede exhibir la propiedad de no separación):
Exemple de «& # x2006 ; fine & # x2006; »insécable française & # x202F ;; correctement codée & # x2006 ;! (hmmm ...en realidad no)
- Ejemplo usando
(que casi siempre es demasiado grande):
Exemple de « bien» française insécable ; correctement codée ! (hmm ... no realmente)
No solo es útil su respuesta (si es un poco larga), también parece bastante educada y bien justificada. Gracias por tu ayuda. Hace que nuestra vida sea miserable en el negocio de localizar sitios web, ya que los mensajes que solían ser de texto plano ahora pueden convertirse en marcas y por lo tanto deben omitir la parte de escape. ¿Tiene alguna idea de por qué ambos navegadores FireFox y Safari, que son compatibles con & # x202F; en Linux y Max OS X, ¿no en Windows? ¿Es solo que las fuentes Linux y Max OS X tienen ese símbolo, mientras que las fuentes de Windows no? ¿Qué no sería un problema si el navegador implementara el repliegue? – FroMage
Las versiones de Linux y Mac OSX probablemente utilicen una biblioteca de representación de texto (o servicio de sistema operativo) que implemente la alternativa cuando la fuente no tenga el carácter. Los navegadores solo usan estas API o bibliotecas. Dado que Windows no implementa este respaldo de fuentes en sus API de procesamiento de texto (GDI, GDI + ...), los navegadores que lo usan no muestran el carácter. Sé que Firefox usa sus propias reservas internas para algunos personajes, pero muchos de ellos son bastante pobres. Pero no veo ninguna razón por la cual un navegador no implemente las propias excepciones para espacios en blanco. –
Tenga en cuenta que Safari no muestra U + 202F en Windows, pero Google Chrome sí lo muestra (incluso ambos navegadores usan WebKit, que debería usar las mismas bibliotecas de renderizado de texto): Chrome implementa el respaldo fuera de Webkit, o usa una versión parcheada de Webkit. –