At 15:52 20.02.2006, you wrote:
Bonjour
Votre remarque relative au Rich Text est très
pertinente et nous nous réjouissons d'apprendre
que Jahia5.0 disposera d'un module de "filtrage"
du Rich Text. C'est un vrai problème et pour des
raisons de cohérence de charte graphique, nous
pensons que l'utilisateur ne devrait pouvoir
utiliser qu'un FCKEditor très "dépouillé".
FCK est open source (au même titre d'ailleurs que
HTMLArea qui a malheureusement été abdanonné en
début d'année mais dont un fork se trouve ici:
Xinha (http://xinha.python-hosting.com/) ) donc
facilement configurable afin d'en faire une
version "light". La plupart des icônes sont
d'ailleurs facilement désactivable via les
fichiers de conf respectifs de ces éditeurs.
Voici pour les éditeurs à proprement parler.
Une fois l'édition dans le browser terminé, le
texte riche HTML est de toute manière retourné au
serveur. A ce moment là, Jahia rééeffectue un
parsing du code afin d'y détecter les liens
internes Jahia (dans jahia 5.0, si vous faîtes un
lien interne vers 45, il recomposera à la volée
une url type jahia/Jahia/pid/45 correct et
inscrira ce lien dans un registre afin, lors de
la suppresion de la page 45, pouvoir notifier
l'éditeur que des liens "hardcodés" dans du text
riche pointe encore vers cette référence et vont
provoquer des 404). Jtidy est alors utilisé
(configurable avec NeckoHTML) pour faire ce
travail. C'est à ce moment là également que l'on
en profite pour valider le code HTML vis-à-vis de
WAI (si l'option est activée vu que WAI est
relativement restrictif et que les copier/coller
Word ou autres deviennent vite impossible une fois activée).
Bref, tout ceci pour mentionner que vous pouvez
très bien avoir un premier contrôle au niveau du
client (ou du javascript, de l'applet ou autre
selon l'éditeur WYSIWYG utilisé) et un second
check au niveau du serveur lors de la sauvegarde
des données. Il faut donc distinguer de quels
type de vérification nous parlons.
Par contre il y a une dichotomie que je ne comprends pas.
Comment faire pour que la partie "restitution"
soit WAI si la partie "édition" ne peut l'être ?
Il s'agit de la même page liée à un seul template.
Cela veut-il dire que si l'on veut faire du WAI,
il faut construire son template de la façon suivante :
Je mentionnais simplement que les "pop-ups"
d'édition n'avaient pas été testé pour WAI. Donc
qu'un éditeur aveugle aurait certainement de la
peine à éditer du contenu vu qu'il manque
(encore) certains raccourcis clavier ou autres
dans les fenêtres d'édition (enfin peut-être que
cela marche... je dis juste qu'on a pas testé, ni
corrigé les fenêtre d'édition pour le moment car
on se contente de contrôler les données sur le
site publié pour les internautes (ou
intranautes). Par contre naviguer en mode edit ne
devrait pas poser de problème vu que la page est
similaire au mode live (ah oui, les checks WAI ne
sont pas obligatoire en mode édition, un éditeur
peut temporairement passer outre, par exmeple
pour sauver son texte et aller manger, et ce
n'est qu'à la validation que le check définitif
sera réalisé... Maintenant à quoi peut bien
servir la navigation en mode edit si la personne
mal-voyante ne peut éditer le contenu....
Stéphane
<%if (jData.gui().isEditMode())
{%>
// Je fais du code HTML non WAI
<%}
else
{%>
// Je fais du code HTML WAI
<%}%>
?
Merci
Cordialement
--
Arnaud RUPIN
Rectorat de Rennes
SERvice Informatique Académique(SERIA)
Département Etablissement, Bureau des études techniques (SERIA-E3)
Stéphane Croisier a écrit :
At 12:02 20.02.2006, you wrote:
Une de nos contraintes fortes est de mettre en
place des sites respectant les caractères
d'accessibilité web (WAI, tableless, etc...).
Lorsque l'on ne songe qu'à la restitution
pure, cela paraît simple à mettre en oeuvre.
Le souci est lorsque l'on passe en mode
édition : le template réalisé pour la
restitution ne tient plus la route du fait des
widgets utilisés pour l'édition des containers
(les widgets n'apparaissent pas aux positions prévues).
Notre connaissance du développement XHTML/CSS2
est peut-être insuffisante mais, ceci dit, la
création de templates respectant les normes
d'accessibilité nous semble beaucoup plus
compliquée (impossible ?) à mettre en place.
Quelqu'un a-t-il rencontré ce type de problème ?
Y a-t-il une solution identifiée pour
conserver la souplesse de développement de template Jahia ?
Qu'en est-il de Jahia5.0 et des normes d'accessibilité web ?
Il faut distinguer plusieurs problèmes:
- la consultation d'un site web aux normes WAI.
Comme vous l'avez mentionné, il est très simple
de modifier un jeu de template pour le rendre
compatible avec la norme. Du moins pour les
éléments de templates hardcodés dans le JSP.
Ensuite il reste le problème des textes HTML
riches à traiter (bigtexts dans le langage Jahia).
- L'ajout de contenus riches html: comme
mentionné, un éditeur peut actuellement saisir
n'importe que contenu HTML, y compris donc du
contenu non compatible WAI. Il faut donc
limiter (= techniquement parlant parser et
supprimer) certains tags. Certaines détections
peuvent être réalisées automatiquement (la
majorité), certaines autres (même pour du WAI
level 1) sont difficiles à automatiser
puisqu'ils s'appuient sur les CSS globale à la
page (ex: les différences de couleurs pour
s'assurer qu'on écrit pas un titre jaune clair
sur un fond blanc). Un tel "module" a été intégré à Jahia 5.0.
- La naviguation/édition en mode Edit: là très
clairement les choses se compliquent. Quitte la
naviguation en mode edit devrait pouvoir être
également "WAIfiable". Par contre les engine
d'édition (les pop-ups) seront clairement plus
difficile à "WAIfier". Dans Jahia 5.0,les
engines d'édition ont été tous convertis en
CSS. il n'en demeure pas moins qu'il existe une
pléthore de code Javascript et autres
formulaires/onglets,/tabulations qui sera difficile à intégrer.
Donc notre objectif est de rendre l'output de
Jahia WAI compatible, pas l'édition. Autrement
dit garantir, à travers des vérifications lors
de l'édition ou lors des workflows qu'un
contenu HTML riche (issu d'un copier/coller MS
Word par exemple ;-) ) soit rejeté tant qu'il
n'est pas WAI compatible. Pare contre pour les
engines d'édition ceci n'est pas à l'ordre du jour du moins pour Jahai 5.0.
Cordialement,
Stéphane Croisier
Merci beaucoup.
Cordialement
--
Arnaud RUPIN
Rectorat de Rennes
SERvice Informatique Académique(SERIA)
Département Etablissement, Bureau des études techniques (SERIA-E3)
- -- --- -----=[ scroisier at jahia dot com ]=---- --- -- -
CEO - Jahia Ltd, 45 rue de la gare, 1260 Nyon (Switzerland)
Jahia : The Java Unified Web Platform
www.jahia.org - The community and product web site
www.jahia.com - Our commercial services company
www.collaborativesource.org - The Collaborative Source Initiative
