Ganf

> J'ai l'impression qu'on a manqué de vision en ne regardant pas directement UTF-8.

Oui et non.

Ton contenu est exclusivement français et anglais. Il n'y a aucune honte à utiliser un codage adapté à ces deux langues. Il est peu probable que dès demain tu te mettes à écrire chinois (et que ces écritures chinoises ne soient pas dans un espace distinct qui permette de mettre un charset différent du reste du site).

Dommage de ne pas y avoir assez mis d'intérêt, mais on n'a par exemple rien à reprocher à ton blog et tes articles à cause de leur ISO-8859-1.

> Ce qui me dérange beaucoup, c'est que depuis toujours, nous parlons tous

> d'ISO-8859-1 comme étant le charset à utiliser

Ça dépend pour quoi faire. Si tu fais des productions françaises il n'y a pas de mal. Si on s'attarde sur des outils qui ont pour but de vivre un peu plus indépendament que les écrits, eux devraient être en UTF-8.

Disons que l'ISO a encore ses raisons d'être. En particulier à cause du fait que ce soit le codage par défaut sur de nombreux protocoles, ou que de nombreux outils ne savent pas gérer les codages sur plusieurs octets (comme UTF-8).

Rien que pour donner un exemple : l'utilisation d'UTF-8 dans PHP n'a rien d'extrèment simple.

> Tu n'es pas le seul Ganf à éprouver des problèmes bizarres avec mon RSS, un ami

> me faisait part du même problème la semaine dernière, sans pour autant pouvoir en

> identifier la cause.

Quand j'ai constaté la chose j'ai pourtant moi aussi vu la déclaration XML de charset. Je jetterai un oeil pour chercher le problème si tu veux.

Je ne suis pas d'accord pour le alt "portrait de xxx", sauf si il y a un lien sur l'image en question qui mène au portrait de xxx (et encore, le alt dans se cas là ferait aussi bien de se restreindre à "xxx").

Quand je lis le document, je ne gagne aucune information à lire "portrait de xxx". L'image n'est qu'illustrative, elle ne porte aucun sens ni aucun rôle. Le alt devrait selon moi être vide.

Par contre effectivement, il peut être utile d'avoir un longdesc. Le texte décrivant l'image, disant qu'il a une grosse moustache, qu'il est en cravate, etc.

Pourquoi je parle de ce longdesc qui parait inutile ? parce que la description de l'image est utile. Elle n'est pas nécessaire, elle n'est aucunement liée à la compréhension du document, mais oui elle est utile. Les illustrations sont le genre d'information qui sont utile à la lecture. On peut se faire une idée de la personne (tiens, lui est en cravate de l'autre en Tshirt), on peut se faire des remarques sur son énorme moustache ... etc.

L'erreur principale quand on fait de l'accès aux handicapés (*) c'est de limiter l'accès à "l'information nécessaire". Eux aussi peuvent avoir envie de commenter ou avoir accès aux informations connexes, aux appartés, aux ajouts ...

Le longdesc c'est AMHA inutile sur une image d'agrément (pour faire joli). Par contre c'est utile (mais non nécessaire) sur une image illustrative (liée au document mais non nécessaire à sa compréhension). Il devient nécessaire sur une image informative (qui porte une information nécessaire à l'intégrité du document). Le alt lui sert pour les images informatives qui font partie du flux de lecture ou nécessaires à la lecture (je parle bien de la lecture, pas de l'accès à l'information, on met une alternative, pas une description).

Sur ce cas précis (le portrait) :

- pas de alt : on srt du flux de lecture, l'image n'apporte pas une information nécessaire au décodage du document.

- éventuellement un title : parce que c'est bien pour comprendre ce que c'est "portrait de xxx"

- éventuellement un longdesc s'il y a un title : pour donner accès aux informations connexes portées par l'image (à quoi ressemble le gars sur la photo)

(*) (je ne réduis pas ce long desc à l'accès aux handicapés mais c'est une des utilisations)

Non Denis, un alt ne suffit pas forcément. Imaginons un bête graphique en courbe. On ne peut pas toujours compter faire une description très détaillée, ça agacerait tout les voyants. Là mettre ailleurs une description précise du contenu de l'image (et pas de l'alternative) peut être sacrément intéressant.

C'est comme ça que je le vois en tout cas.

ne devrions-nous pas tous utiliser Unicode ?

Denis, toujours pas convaincu par Unicode ?

On peut s'en passer, mais ça demande plus de boulot. En plus de changer la langue, de changer les préférences d'affichage de type monnaie/date/nombres, il te faudra aussi changer de charset. Une application peut tout à fait gérer ça en interne mais ça demande plus de boulot et c'est la meilleure manière de se planter.

Je peux te dire qu'ici on cherche à implémenter une interface Coréenne sur une appli et une base de données toutes les deux en ISO-8859-1 au départ ... ben c'est pas gagné.

(message perso: d'ailleurs j'en profite pour te signaler que ton fil RSS passe mal chez moi, justement à cause d'un problème de déclaration de charset)

UTF-8 est tout simplement loin d'être l'encodage par défaut.

Je rajouterai même que pour les documents envoyés en HTTP avec un type mime en text/* le codage (pas encodage, s'il vous plait) est implicitement du ISO-8859-1 (c'est définit par la norme). Firefox a donc raison de le prendre par défaut. (j'en veux d'ailleurs au validateur W3C qui prend de l'UTF8 par défaut quand rien n'est déclaré).

Heureusement, les navigateurs choisissent bien souvent l'encodage UTF-8 pour les documents XML

Si je ne me trompe pas c'est là aussi imposé par les specs : un document XML sans déclaration de codage est un document UTF-8.

(pour qu'il soit sans codage il faut donc qu'il ne soit pas envoyé en text/* sinon le codage est considéré comme déclaré par HTTP)

Unicode devrait-il être utilisé ?

Globalement, j'ai vu des navigateurs ne pas accepter ISO-8859-15 (le même que par défaut mais avec l'euro et quelques autres caractères en plus) ou ne pas accepter cp1252 (la version proprio Microsoft Windows qui diffère sur les guillemets typo et quelques autres machins) ... mais globalement même les très vieux supportent l'UTF-8. Les seuls chez qui ça ne passent pas ne supportent vaiment que ISO-8859-1 (donc pas d'internationalisation) et ressemblent généralement plus à des scripts qu'autre chose.

Le surcout en taille de fichier est largement négligeable pour l'essentiel des ressources. Surtout si c'est contrebalancé par la pérénité et l'évolutivité.

Le seul défaut se situe au niveau de quelques débats entre les chinois et coréens (entre autres) : ils utilisent les mêmes caractères mais les dessinent différement. Unicode a jugé qu'ils écrivaient une table des caractères et pas une table des glyphes (dessins), donc que les différences d'affichage devaient se faire au niveau des polices. Du coup c'est vrai que ça réduit un peu le coté pratique (surtout pour les citations) car les documents ne peuvent être relus correctement que s'ils incluent une information sur la langue.

Maintenant c'est encore pire si on utilise ISO-8859-1 ou un codage qui ne supporte qu'un alphabet. On a tout intérêt à utiliser UTF-8, rien à perdre en tout cas.

Parce que c'est un tableau qui sert à la mise en page et qu'il ne contient pas de données tabulées à proprement dit.

C'est justement ce qui me semble contestable.

Dans http://www.bioblock.com/pages/promotions/promotions.asp, à la fin de la page ce qui est présent c'est bien une suite de données avec chacune :

- image

- descriptif

- réduction

- prix

- liens d'action

Ça me parait justement être tout ce qu'il y a de tabulaire : deux dimensions (une pour le type d'info et une pour les différents objets).

C'est justement quelque chose que moi je conseillerai de mettre sous forme de tableau si ça ne l'était pas.

mais ce n'est pas l'objet du post

Désolé d'avoir dérivé mais ça me semble important de dire quand je pense que c'est une erreur au lieu de donner une solution qui au final est mauvaise à mes yeux. Voir d'ailleurs à ce sujet mon dernier article (ça ne correspond pas tout à fait mais l'idée directrice est la même).

Ce d'autant plus qu'on est dans un espace public et que ce n'est pas à toi que je répond mais à tout ceux qui lisent ou qui liront. Donner une réponse sans faire la remarque alors que je pense ça faux, c'est plus ou moins inciter les gens derrière à faire pareil (ou plutot à ne pas voir le problème).

Pour la solution si tu y tiens vraiment je pense que le plus adapté ici c'est (si tu imposes de ne pas utiliser le <table> ) :

- transformer le <table> en <ul>

- transformer les <tr> en <li>

- transformer les <td> en <span>

Par la suite tu peux appliquer une présentation :

- sous mozilla et opera faire un display:table, display:table-row, display: table-cell sur les <ul> <li> <span>

- sous les autres définir les span en float:left, leur donner une taille horizontale (fixe pour la première colonne, proportionnelle au texte pour les autres) et affecter un clear:left aux <span> de première colonne.

Ça devrait dégrader correctement dans tous les navigateurs, textes compris.

Les solutions à base de colonnes comme "little boxes" (et non de lignes comme plus haut) sont plutot à réserver pour le layout de la page. Ils ont déjà des rendus bien plus complexes à mettre en oeuvre pour autre chose qu'un 3 colonnes simples sans gestion des lignes, et en plus ils dégradent mal dans les navigateurs texte/oraux qui font une lecture linéaire (on aurait alors tous les descriptifs, puis tous les prix, puis tous les boutons ...)

Pourquoi souhaites tu transformer ton tableau ? Qu'il y a t'il qui ne va pas avec ce tableau ?

à mon avis tu fais fausse route et tu n'as pas vraiment fait le point de tes motivations pour faire cette transformation.

zut, j'ai pas fini mon article, j'avais oublié, bon, je m'y remet.

utf8_encode(urlencode($data['mavar'])) ??

Je suppose que la syntaxe correcte est plutot urlencode(utf8_encode(...))

De toutes façons une fois passé par urlencode la fonction utf8_encode ne servira à rien vu qu'il ne restera que des caractères ASCII donc directement compatibles UTF8

Clairement le code source est plus clair, plus simple à travailler et modifier : gains sur les mises à jour, ajouts, modifications, etc. Je pense que c'est l'avantage (personnel) le plus important.

Concernant la créativité je ne suis pas sûr qu'il y ai un énorme bénéfice. On peut certes faire plus de choses mais on reste toujours limités et je ne crois pas que les graphistes vont d'un coup avoir une énorme créativité en passant à CSS (surtout si ils ont besoin de changer leurs méthodes de travail).

Tu peux aussi consulter le très connu http://www.cybercodeur.net/weblog/presentations/seybold/

l'un est en HTML l'autre en XHTML.

Aucune autre différence

Bah, franchement je ne vois pas en quoi des gros pointillés seraient plus logique que des petits, ni en quoi les pointillés se font sur la couleur de fond plutot que la couleur du contenu. Un jour tu veux l'un, un jour tu veux l'autre. Il est même probable que tu souhaites ce que te donne MSIE parce que tu as l'habitude de MSIE et de son rendu par défaut.

Faut simplement apprendre à lacher prise, le Web n'est pas fait pour être identique partout (c'est même tout le contraire)

Pour les navigateurs qui posent problèmes il y en a plein, mais en faisant les tableaux tu emploient déjà probablement les astuces nécessaires pour que ça passe sur les principaux, ça sans t'en rendre compte. Tu n'as jamais eu à faire des imbrications alors que tu comptais faire autrement ? jamais eu à faire des colonnes ou lignes de 1px, à rajouter des colonnes ou lignes parce que le navigateur n'arrivait pas à calculer tout seul les tailles ?

Maintenant ton problème c'est que tu regardes les "gros" navigateurs. L'exemple le plus flagrant c'est le navigateur oral pour ceu qui ont des déficiences visuelles. Une mise en page avec trop de tableau est incompréhensible. Ceci dit il y a d'autres exemples simples, par exemple Google qui risque de mal interpréter ta page si sa conception n'est pas naturelle.

Grosso modo si tu préfères les tableaux il y a déjà des moyens de réduire les problèmes :

- pas d'imbrication de tableaux

- peu voire pas de rowspan et colspan

- peu de colonnes et lignes

- faire en sorte qu'une lecture séquentielle du contenu soit compréhensible

si djà tu fais ça tu auras le principal (à défaut de faire correctement)

"" peut tout à fait être codé directement. Le problème vient de Windows (pour changer) qui code certains caractères n'existant pas dans l'ISO-8859-1 de manière non standard dans de l'ISO-8859-1 justement, ce qui risque de ne pas être lisible partout (c'est le le fameux codage cp1252). Si tu choisis de l'ISO-8859-15, ou mieux de l'UTF-8, tu pourras l'écrire directement tous tes caractères sans problèmes (du moins à ma connaissance)

Pb. 1 :

- la grosseur du trait est réglable dans les deux navigateurs, il ne devrait pas y avoir de différence si tu en demandes un explicite

- l'espacement est lié au navigateur, rien n'indique nulle part cet espacement. Tu ne trouveras rien pour le régler. Des fois il convient chez l'un, des fois il convient chez l'autre. Dans l'ensemble : est-il grave que ce soit différent ? probablement pas

- pareil pour la couleur de fond, savoir si la bordure est faite sur la couleur interne ou externe. Il va falloir accepter que ça ne soit pas identique partout, ou alors mettre une bordure continue

D'une manière générale pour le 1, tu devrais éviter de te formaliser pour les différences de détail dans les rendus. Laisse donc au navigateur certaines liberté d'apréciation et de rendu : c'est son boulot. A ce propos je te conseille la lecture du Tao : http://pompage.net/pompe/tao/

La règle d'or c'est "n'essayes pas de tout controler". Contentes toi de faire un accès correct à tout le monde, ça sera déjà beaucoup.

Pb. 2 :

Si c'est un problème de box model (impossible à dire à partir des captures) tu pourras trouver la description du problème et des solutions sur Openweb : http://openweb.eu.org/articles/dimensions_boites_css/

Globalement encore : est-ce que une différence telle que sur la capture d'écran est importante ?

Pb. 3 :

La solution se trouve sur alistapart : http://www.alistapart.com/articles/footers/

si pour avoir les caractères encodés en html (exemple : è pour è, ou é pour é, etc...) il me faut passer par la function utf8_decode() avant d'appliquer htmlentities()...

Tout d'abord, un des avantages de déclarer un jeu de caractères c'est justement de ne pas avoir à faire &eagrave; mais directement mettre la lettre accentuée. Pas besoin de jouer au htmlentities pour ça (le htmlspecialchars reste nécessaire)

Ensuite, si tu as besoin de passer par utf8_decode() c'est que PHP fonctionne par défaut en ISO-8859-1. La plupart des fonctions PHP marcheront mal ou pas du tout avec de l'UTF-8 (surtout à cause des caractères sur plusieurs octets). C'est le cas aussi pour htmlentities().

Par contre cette dernière a une possibilité supplémentaires, tu peux lui dire "ce que je t'envoie est de l'UTF-8". Il suffit de mettre 'UTF-8' en troisième paramètre, et 'op, plus besoin de utf8_decode().

htmlentities ( $texte , ENT_COMPAT , 'UTF-8')

Pour le 3° c'est étrange, les polices windows ont ou n'ont pas ces caractères accentés. Je ne vois pas de raison réelle pour qu'ils n'apparaissent pas. Le rendu des polices est tout de même uniformisé sur la plateforme, il ne devrait pas y avoir de problème.

Je penche plus pour autre chose : peut être que tu as récupéré une police qui servait à un test de la fonctionnalité. Pour moins de poids ils ont pu retirer les algorithmes de lissage et quelques tailles de glyphe intermédiaires, ainsi que les caractères qui ne leur servaient pas.

euh, le téléchargement de police via _AT_font-face c'est quelque chose de tout à fait standard et documenté dans CSS2 (qui a disparu dans la 2.1)

Rien de propriétaire, rien de "trop avancé", si MSIE/win est le seul à l'implémenter c'est plutot à reprocher aux autres navigateurs (mais le fait que les différents systèmes utilisent des systèmes rendu de police différents doit jouer pas mal)

Non non, MSIE permet bien de spécifier une police à télécharger via une règle CSS2 (tout à fait standard en plus).

Maintenant :

- ça ne marchera que sous MSIE

- ça ne marchera que sous Win

- je pense qu'il faut avoir les droits d'administrateur

et ...

- est-ce vraiment utile ?

Vouloir absolument forcer une police peut se comprendre pour un titre ou autre objet très graphique, pour le texte lui même c'est plus contestable. Pour ces titres, une image avec un alt bien placé est probablement aussi simple et efficace.

Si tu y tiens vraiment tu peux aller voir http://www.yoyodesign.org/doc/w3c/css2/fon...nt-descriptions

En gros c'est :

_AT_font-face {

font-family: "nom_de_la_police";

src: url("url_de_la_police_a_tele_charger")

}

notes que si une autre police de même nom existe sur le système, c'est celle ci qui sera utilisée.

De grandes chances que j'y aille. Avec de la chance je tiendrai peut être même une des conférences.

Après à savoir ce que tu cherches. Ce sont des présentations de 3/4 d'heure. Si tu comptes apprendre le PHP ou chercher à monter en compétence sur des sujets très techniques ce n'est pas l'endroit. Même s'il est possible que tu apprennes des détails intéressants ce n'est pas forcément ce qui m'a semblé le but lors de l'édition précédente.

La première journée est faite autour des décideurs, le but c'est d'expliquer pourquoi PHP peut répondre à leurs besoins. La seconde est plus orientée technique mais c'est plus pour montrer ce que PHP peut faire et répondres aux questions de ce type. (note : je ne donne que mes impressions, ça vaut ce que ça vaut)

Perso par contre je ne regrette pas ma présence, il y a eu des discussions et personnes intéressantes l'année dernière

Je participerai peut être, mais c'est loin d'être sûr. Il y a quelque part le règlement ou un détail sur ce qui sera jugé ?

Le concours dont j'avais personnellement entendu parlé c'est http://www.codewalkers.com/php-contest.php mais malheureusement il s'agit plus d'un concours d'algo et de stratégie que de PHP (vu qu'on juge le résultat d'une IA et pas le code)

--

Eric Daspet (Ganf)

Je suis à la recherche d'un lecteur d'écran, gratuit et destiné à lire des textes en français : cela existe t-il ?

Ça ne va pas être ce que tu attend mais je peux te proposer Oralux, une distrib Linux basée sur la lecture d'écran. Coté logiciel gratuit je ne connais rien de célèbre.

Lesquels sont les plus utilisés selon vous ?

Personnellement j'entend presque uniquement parler de Jaws, qui semble être très avancé et avoir pas mal trusté le domaine (de ce que j'ai pu voir, c'est à dire pas beaucoup).

C'est en cours, j'ai un premier draft mais j'aimerai bien quelques relecteurs pour faire des commentaires sur la forme et publier quelque chose de correct (avec un peu de chances ça peut être utile donc j'aimerai que ce soit clean).

Si ça intéresse du monde il suffit de me bipper sur ganfset @ dreams4net.com

Backwards compatibility, clear migration path

Personnellement je trouve cette prise de position très grave. Autant je trouve que faire actuellement du Web sans garder la compatibilité MSIE est stupide, autant là disent dès les premières lignes que faire un nouveau schéma qui n'est pas directement compatible avec un navigateur qui a déjà plusieurs années est mauvais.

Si on ne peut pas imaginer pour le futur des formats qui ne passent pas actuellement sur MSIE on ne fera jamais rien. Ou plutot on peut tout de suite retirer le W3C et déléguer la création des formats à MSIE, parce que ça revient à lui donner un pouvoir de véto sur tout ce qu'il se fait, dre que quelque chose ne peut exister que si MSIE l'a fait auparavant.

Ne pourrait-on pas imaginer enfin un format en cassant la compatibilité ? le XHTML1 n'est même pas encore d'actualité (on en est encore globalement au HTML4) et si on commence aujourd'hui un format refait correctement il ne sera de toutes façons pas d'actualité avant 3 ans (en comptant la rédaction) alors pourquoi tout baser sur les fonctionnalités de MSIE6 (et pourquoi pas sur Mozilla tiens ?) qu'on trouve déjà dépassé actuellement.

Users should not be exposed to authoring errors

Là ils sont en train de demander explicitement un retour à une tolérance aux erreurs. C'est un choix compréhensible, mais contestable.

Par contre comme c'est marqué aussi ils demandent un modèle de gestion d'erreur différent de celui de XML. Alors ça veut dire que soit on jette les formats basés sur XML soit on s'amuse à autoriser du XML qui sera incompatible avec les specs XML, donc potentiellement impossible à interpréter ou faire passer dans les chaines XML existantes et conformes.

Dans les deux cas ça me parait tuer complètement le principe même de XML (une grammaire unique qui sert partout de la même façons pour permettre une compatibilité simple de la grammaire).

Ces deux points sont pour moi un échec complet et un désastre pour l'avenir : on parle sans retenue de créer des XML incompatibles et de ne rien faire qui ne passe pas sur un vieux navigateur connu pour ne pas être à jour au niveau des fonctionnalités actuelles. Chouette, on empeche la création tout en détruisant ce qui existe déjà. Ils ont fumé quoi ?

Sinon dans la suite ils parlent d'applications Web et j'ai l'impression de ne pas retrouver mon HTML. Le HTML est por moi adapté à la description de documents. Pour faire des applications il y a XFORMS, XBL et plein d'autres choses qui peuvent servir de base à un format applicatif, pas besoin de pourrir XHTML.

Et là je ne parle même pas de leur demande de limiter les espaces de nom, ce qui revient grosso modo à revenir sur le concept de sous formats XML qui se mixent entre eux pour apporter des fonctionnalités élémentaires de façon modulaire. (je peux comprendre mais c'est AMHA pas la bonne direction pour l'avenir)

J'ai l'impression que dans l'ensemble ils sont simplement en train de nous pourri XML pour revenir sur quelque chose de plus proche de SGML. Je n'ai rien contre l'idée qu'ils fassent un truc à eux mais qu'ils ne viennent pas pourrir XML avec un truc pseudo compatible qui ne le sera pas (erreurs tolérées, pas d'espace de nom, etc.)

Je sens que je vais faire un article réponse complet tellement ça me semble idiot.

Juste pour rajouter : PHP a un module tidy, qui permet justement d'appliquer un filtre automatique à l'affichage via les fonctions de buffer.

C'est à mon avis une mauvaise solution mais si tu tiens à faire comme ça tidy reste probablement un moyen des plus efficace.

Tu as le fameux "tidy" qui sait faire ça, en plus il peut corriger une bonne partie des erreurs si le HTML est mal rédigé au départ.

c'est koi cette histoire de href="#", nohref... ?

Simple, area contient un attribut nommé href. Cet attribut est là pour faire un lien entre une ressource (une page) et la zone de l'image concernée. Là tu fais un lien entre la zone et ...... rien (ou plutot une ancre inexistante de ta page).

Pour signaler qu'il s'agit d'une zone qui n'est pas un lien il ne faut pas mettre une ancre vide (ce qui n'a absolument pas de sens). Il existe un attribut pour ça, il s'appelle "nohref".

Quand on te demande un n° de fax sur un papier administratif tu fais quoi ?

- tu laisses vide

- tu barres le champ

- tu marques "aucun"

- tu marques "0000000000"

à priori marquer dix 0 parait plutot bizarre, voire idiot. Et bien bizarrement c'est ce que tu fais en mettant ce href="#". (bon, c'est une analogie pourrie mais ça résume bien ce que je veux dire)

Pour le javascript je pensais à quelque chose dans le style de http://blog.dreams4net.com/JavascriptNonIntrusif (tu peux sauter le dernier paragraphe, il n'a rien à faire avec notre histoire). Je sais que ça existe pour les liens classiques (et faire apparaitre le titre avec une bulle d'aide un peu plus élaborée que par défaut), c'est peut être adaptable pour les <area> aussi.

Globalement tant que tu cherches à détourner des choses qui ne sont pas faites pour ... tu t'exposes à des problèmes :

- le href est fait pour faire un lien, pas pour avoir un effet technique de zone réactive

- le alt est un texte alternative, pas une information complémentaire

- l'affichage par bulle d'aide n'est pas garanti par défaut car pas fait pour, c'est juste une des présentations possibles. Rien ne parle de bulle d'aide (tooltip) en HTML.

Tu as d'autres solutions :

- afficher directement les textes dans l'image, sans survol

- utiliser des choses plus élaborées avec plein de javascript pour les événements

- afficher des drapeaux ou points avec une légende en dessous

- faire du flash pour la carte ...