Geckozone

Ils sont en Candidate Recommendation depuis un baille :
http://www.w3.org/TR/ruby/ << HTML
http://www.w3.org/TR/css3-ruby/ << CSS3

Puis si on rajoute ça.
http://www.w3.org/2001/05/xhtml-ruby-pr ... se.html.fr

Le bug traine depuis super longtemps :
https://bugzilla.mozilla.org/show_bug.cgi?id=33339

D'un côté ça fait un peu chier qu'ils s'occupent des ligatures (bien occidentales elle) mais qu'il oublie complètement le support pour les langues asiatiques (parce que c'est pour dire, mais les furigana, c'est tout de même quelque chose de super courant et réellement utilisé dans les journaux, livres, télévision, manga, etc.).

Un document très intéressant du W3C sur l'écriture du japonais: http://www.w3.org/TR/jlreq/

J'étais tombé dessus, c'est plus pour le SVG. D'ailleurs l'écriture vertical SVG n'est même pas supporté par Fx (mais elle l'est dans Opera et Webkit il me semble).
En tout cas, il y a tout les spécs. pour faire un éditeur avance de texte en japonais là-dedans. Je pense qu'il doit bien y avoir un équivalent pour d'autres écritures.

Le support du SVG dans Firefox ne donne pas vraiment envie de l'utiliser. XHTML application/xhtml+xml ou objet SVG. Il n'y a toujours pas de support dans la balise img ce que réclame pas mal de monde.

Zefling a écrit : Il n'y a toujours pas de support dans la balise img ce que réclame pas mal de monde.

Yep, c'est le bug 276431. Un message indiquant pourquoi cela n'a pas été fait pour Fx 3.6 a été ajouté (c'était initialement prévu):

Joe Drew a écrit :The changes in bug 753 and bug 435296 were being made at the time that
svg-in-img development would have been happening, and the two pieces of work
would conflict with each other (or, more specifically, depend on each other),
so we opted to delay implementation until the other imagelib work was done.

Sinon le travail sur le CSP (Content Security Policy) continue: http://blog.sidstamm.com/2009/10/csp-preview.html

Zefling a écrit :D'un côté ça fait un peu chier qu'ils s'occupent des ligatures (bien occidentales elle) mais qu'il oublie complètement le support pour les langues asiatiques (parce que c'est pour dire, mais les furigana, c'est tout de même quelque chose de super courant et réellement utilisé dans les journaux, livres, télévision, manga, etc.).

Est-ce que ce n'est pas généré par les mêmes mécanismes dans les polices ? Parce que ce qu'ils font c'est traiter plus d'infos qui sont présentes dans les polices et ça devrait pouvoir bénéficier à d'autres systèmes d'écriture. Il me semble qu'il n'y a quasiment pas de ligatures dans les lettres latines par rapport à ce qu'on trouve dans les alphabets indiens par exemple.

Le mécanique n'a rien à voir. Les furigana, lorsqu'on n'a pas le support, ça ressemble à cela : 神社｛ここ｝には、何の神が住んでいたか？
J'ai mis la lecture particulière entre parenthèse car mot se lit « じんじゃ ». Là, j'ai détourné son sens pour apporter une précision. Ce cas de figure est impossible à prévoir, c'est au bon vouloir de l'auteur.

Normalement, c'est mieux comme ça :


Ça c'est le titre d'une série récemment parue qui utilise une forme plus complexe :

C'est bizarre en effet que ça n'ait pas été intégré encore, ça ressemble fortement à ce qu'on peut faire avec du MathML (les limites autour d'une intégrale par exemple). Et l'équipe de Mozilla Japan est assez active. Peut-être que l'extension leur suffit pour l'instant ?

Peut-être que le parser HTML5 fera avancer ça. Non seulement ruby fait partie de la spécification, mais une partie du travail consiste à faire fonctionner des particularités XHTML (comme MathML !) dans du HTML normal.

Yep, les furigana ne sont pas des ligatures mais des "sous-titres" (ou sur-titre) aux idéogrammes indiquant quelle est la bonne prononciation.

Et effectivement, je pense que l'existence d'un double parser html4/html5 doit bloquer toute avancée de ce côté-là, travail à double et impossibilité d'avoir des review sur html4, comme sur html5 (tant que le gros du travail n'est pas fini)

Sinon, rien à voir, mais le retour des propriétés dans le menu contextuel pour les images: cela ouvre la page info/média au bon endroit désormais:
Bug 517902 - Reimplement image properties, using the existing "Media" panel

Et le SMIL a été activé par défaut sur le trunk: Bug 482402 - (smil) Enable "svg.smil.enabled" pref by default

+2 au test ACID3 (96/100). Rappel: 1 point sera obtenu lors de l'activation du parseur html5 et les 3 points restants sont dus à l'absence des SVG:Fonts [A part cela il reste deux petits problèmes: 1 de perf sur un des tests, l'autre étant l'affichage de la favicône envoyée par un serveur même si la favicône est signalée en 404]

teoli2003 a écrit :Sinon, rien à voir, mais le retour des propriétés dans le menu contextuel pour les images: cela ouvre la page info/média au bon endroit désormais:
Bug 517902 - Reimplement image properties, using the existing "Media" panel

Ah ça c'est une excellente nouvelle !

L'ancienne fenêtre n'était pas très intéressante, mais l'absence d'entrée Propriétés dans le menu réutilisable par les extensions ne pouvait que déboucher sur des menus contextuels interminables. Reste à réadapter des extensions comme FxIF.

Mais pour les liens ou tout élément comportant un titre ?

teoli2003 a écrit :Sinon, rien à voir, mais le retour des propriétés dans le menu contextuel pour les images: cela ouvre la page info/média au bon endroit désormais:
Bug 517902 - Reimplement image properties, using the existing "Media" panel

Quelles sont les raisons de ce retour en arrière ?

ghosta a écrit :

teoli2003 a écrit :Sinon, rien à voir, mais le retour des propriétés dans le menu contextuel pour les images: cela ouvre la page info/média au bon endroit désormais:
Bug 517902 - Reimplement image properties, using the existing "Media" panel

Quelles sont les raisons de ce retour en arrière ?

Ce n'est pas un retour en arrière. L'objectif était de supprimer l'ancienne fenêtre de propriété car elle n'était plus maintenue et ajoutait de la redondance superflue dans le code. Cet objectif est atteint et il n'y a pas de retour en arrière là dessus.
Par contre, la fonctionnalité que le menu apportait était utile, en utilisant le panneau "Média" et un lien direct sur l'image dans ce panneau, on évite la duplication de code, et on accède aux même informations aussi facilement.

Zefling a écrit :Mais pour les liens ou tout élément comportant un titre ?

Pour les images uniquement.