Incontournables XHTML / CSS :
| Auteur | Pages : [<] |
|---|---|
| Arsene | # 25 Jun 2007 - 18:24:39  |
| 793 Posts |
(reprise du message précédent) Magnifiiiiique et merci à Laurent et JPV  Concernant <object> : Les éléments OBJECT imbriqués sont utiles pour offrir des solutions de repli au cas où l'agent utilisateur ne reconnaîtrait pas certains formats. Par exemple : Extrait de www.la-grange.net ... ce qui ne solutionne pas tout, et notamment pas la question de la relation contextuelle créée entre le contenu des balises <object> et les textes l'entourant, question qui relève effectivement d'une stratégie éditoriale. D'autre part <object>, d'un point de vue opérationnel, inverse un peu la règle du jeu en disant à l'UA : "si tu ne peux pas faire ceci (restituer une image par ex.) alors fais ceci (affiche un texte)". Si un monde idéal existait tout ça se présenterait probablement en ordre inverse : "si tu peux faire ceci (afficher un texte) alors essaie plutôt de faire cela (afficher une image de remplacement)". Du coup on serait plus portés à penser non pas en alternative textuelle mais en alternative visuelle... ce qui serait dans la cohérence du document : d'abord le contenu structuré puis les couches graphiques (les images, les CSS de mises en forme) et événementielles. J'ai droit aussi à ma part de moquette ??? |
 |
|
| Florent V. | # 25 Jun 2007 - 18:40:38 |
On va manger des chips.  Modérateur 13463 Posts |
Arsene a écrit : Tu ne viens pas de l'utiliser ?  |
 |
|
| jpv | # 25 Jun 2007 - 19:49:51 |
| Modérateur 743 Posts |
Bonjour,Du coup on serait plus portés à penser non pas en alternative textuelle mais en alternative visuelle... ce qui serait dans la cohérence du document : d'abord le contenu structuré puis les couches graphiques (les images, les CSS de mises en forme) et événementielles. Ben oui mais non, tu penserais mal et le document n'en serait pas plus cohérent au contraire (ça ne préjuge pas de la qualité de ta moquette hein  )Il n'y à aucune raison valable de privilégier l'un ou l'autre, une image est un contenu qui à sa place en tant que tel. Le défaut de la balise img c'est justement qu'elle privilégie (ou plus exactement impose) un seul canal de restitution. En réalité la balise img est, de fait, inadaptée aux possibilités du web en tant que "media multiple" si vous me pardonnez ce "barbarisme". Il y à d'ailleurs cette phrase, lourde de sens, sur la page d'où tu à tiré l'exemple d'implémentation : Les versions antérieures de HTML permettaient aux auteurs d'inclure des images (via l'élément IMG) et des applets (via l'élément APPLET). Ces éléments ont plusieurs limitations : Ecris donc en 1999, 10 ans après nous y sommes encore.... Par ailleurs le fonctionnement que tu décris n'est pas logique : si je veux implémenter une image c'est bien parce que c'est une image...  Ce n'est pas une question de "priorité" mais de "canal" : la balise img ne possède qu'un canal de restitution (visuel) et une rustine techniquement limitée, c'est du contenu sans vraiment en être et il ne peut être que textuel ! C'est un peut juste, cela ne corrrespond pas à la notion de "ressource" attachée au web. Par ailleurs, la manière de le gérer (l'attribut) nous amène à le concevoir et le traiter comme une alternative-en-cas-de-besoin et pas du tout comme la simple présentation d'une information au travers de plusieurs canaux de restitution différents. La balise object, en revanche, fonctionne de cette manière c'est sa nature et son rôle, ce qui me permet de multiplier les possibilités de traitement de l'information. De les multiplier, de les adapter de manière très fine, d'en inventer des nouvelles ou de s'adapter à des usages, des conventions, du consensus, ou des technologies nouvelles. Bref tout ce qui fait le web... La balise img+alt+longdesc "si tout va bien" est évidemment pas le bon client pour ça. Petit exemple juste pour vanter la qualité de la moquette de mon bureau... Imaginez que j'ai envie de donner un contenu équivalent à une image sous forme d'un son (genre une alerte sonore pour une alerte visuelle) Evidemment pour éviter un futur troll on admet que j'ai de très bonnes raisons de vouloir donner cette information de cette manière. Comment je fais avec ma balise img ?, je fais pas, je prends ma béquille et je clopine avec du texte, ce qui n'est pas ce que voulais faire... Au delà de cet exemple simpliste, cela "interroge" comme dirait un candidat au bac philo, sur la notion d'alternative, et ça, pour le web, c'est tout bon Jean-Pierre Modifié par jpv (25 Jun 2007 - 20:20) |
| |
|
| jpv | # 25 Jun 2007 - 20:18:11 |
| Modérateur 743 Posts |
Hermann a écrit : Tous ceux qui s'en donnent les moyens. Il y à d'ailleurs déjà des choses qui existent comme l'extension fxif pour firefox Mozdev - extension fxif (en) Hermann a écrit : Non pas du tout. Tu à d'abord une erreur dans ton code, img est de type inline et nécessite un conteneur. Au delà, une image est du contenu, si l'image nécessite d'être restituée dans le flux d'une phrase elle doit l'être. En revanche dans le genre limitations de l'attribut alt on peut citer l'impossibilité technique d'implémenter par exemple : - Une abréviation - Une indication de langue - Une ressource (URI) Et de manière générale : utiliser ce que j'ai besoin d'utiliser parce qu'à ce moment là et dans ce contexte là c'est pertinent et adapté... Jean-Pierre |
| |
|
| Hermann | # 25 Jun 2007 - 20:52:48 |
| Modérateur 2764 Posts |
jpv a écrit : Merci, dommage seulement que le fichier xpi retourne une erreur. jpv a écrit : Mon code supposait un div englobant. ça suffit non? La FAQ répond aux questions fréquemment posées. Vérifiez qu'elle ne contient pas une réponse à votre problème. |
|
|
| Christian Le Bouler | # 25 Jun 2007 - 21:24:02 |
| 3135 Posts |
jpv a écrit : De complémentarité plutôt que d'alternative, d'autant que ce que tu décris nous entraine loin de la définition stricte de l'alternative : A ou B mais pas les deux, et pas ni l'un ni l'autre. Modifié par Christian Le Bouler (25 Jun 2007 - 21:27) |
|
|
| Lanza | # 25 Jun 2007 - 21:46:21 |
Mouton Noir  856 Posts |
Bonsoir, Hermann a écrit : Si je ne m'abuse, en (X)HTML Strict, on ne peut pas mixer des éléments inline et des éléments blocks dans un élément block, et les exceptions à cette règle (dont li si mes souviendres ne me font pas trop défaut) seront éliminés sauvagement dans les prochaines version d'HTML. <!-- sans commentaires... --> |
|
|
| Hermann | # 25 Jun 2007 - 22:20:12 |
| Modérateur 2764 Posts |
Lanza a écrit :  D'ou tu sors ça? On ne peut pas avoir directement d'élements inline dans le <body> en DTD strict ça c'est c'est vrai mais un élément comme <div> peut très bien contenir des éléments inline et block simultanément. Modifié par Hermann (25 Jun 2007 - 22:24) La FAQ répond aux questions fréquemment posées. Vérifiez qu'elle ne contient pas une réponse à votre problème. |
|
|
| Christian Le Bouler | # 25 Jun 2007 - 22:47:18 |
| 3135 Posts |
Lanza a écrit : Sur le (X)HTML actuel, cela reste absolument non problématique. Sur les versions à venir ben on verra, ce qui semble s'ébaucher te donne pour l'instant raison. Perso rien de trop à en dire puisque cela conforte ma conceptualisation du balisage block. . Block "type 1" comme séquençage du flux de niveau texte. Modèle = <p>, plus avatars et particularismes. . Block "type 2" comme séquençage d'un flux de niveau block. Modèle = <div>, plus avatars et particularismes. Enfin, on verra bien dans l'avenir... On est loin d'y être quoiqu'il en soit. Modifié par Christian Le Bouler (25 Jun 2007 - 22:49) |
|
|
| Florent V. | # 26 Jun 2007 - 00:07:00 |
On va manger des chips. Modérateur 13463 Posts |
Hermann a écrit : Une légende urbaine qui traine. Hermann a écrit : Voilà, c'est tout comme ça, et on le vérifiera avec bonheur en consultant directement la DTD Strict de XHTML 1.0. Par ailleurs, et d'après ma dernière lecture à ce sujet, le plan pour (X)HTML 5 pour l'élément div est qu'il ne puisse plus contenir que : - soit des éléments de type bloc (au sens large et approximatif, il me semble) ; - soit des éléments de type en-ligne ; - mais pas un mélange des deux. Même chose pour les li. Cf. http://dev.w3.org/cvsweb/~checkout~/html5/html4-differences/Overview.html#content-model-changes |
| |
|
| Lanza | # 26 Jun 2007 - 00:12:10 |
Mouton Noir 856 Posts |
Exact, au temps pour moi, je viens de vérifier. Mince alors, j'en étais persuadé. D'où qu'elle venait cette erreur que j'ai eue il y a 6 mois alors ? Edit : trouvé, j'étais à l'interieur d'un formulaire. Du coup, j'ai cru... Bon, je vais me coucher puisque c'est comme ça. Modifié par Lanza (26 Jun 2007 - 00:25) <!-- sans commentaires... --> |
|
|
| jpv | # 26 Jun 2007 - 01:59:40 |
| Modérateur 743 Posts |
Bonsoir,Christian Le Bouler a écrit : Heu... nous parlons bien de la même chose je pense, je n'ai pas eu l'impression de décrire un mécanisme complémentaire, au contraire. Ce que je voulais dire c'est que les capacités de la balise object de servir un même contenu (c.a.d de l'information) sous de multiples formes modifie les perspectives de l'alternative. Pour les images en loccurence nous ne sommes plus dans une perspective de pallier une défaillance (supposée ou réelle) : je ne "remplace" pas l'image (une image est irremplaçable) je rends simplement une information disponible sous plusieurs formes. Prenons un cas simple, un peut caricatural mais bien pratique : un joli graphe sous forme de camembert, avec un quartier mis en exergue (l'info importante) et son alternative. Comment je le traite actuellement : j'implémente un alt qui est censé me donner l'information nécessaire à la compréhension du contenu (donc le quartier mis en exergue) et je référence un attribut longdesc qui lie une ressource contenant une description détaillée. Très bien, mais il me faut réunir des conditions précises à l'utilisation de cette technique : il faut que l'UA ait référencé les attributs, choisis une méthode de traitement et mette à disposition des fonctionnalités adhoc... Par ailleurs ces alternatives, quoi qu'on en dise, sont "hors contexte" pour la ressource via longdesc, et pas tout à fait un véritable contenu pour l'attribut alt. On connait le succès : Tu peux tant mieux, tu peux pas tant pis. Maintenant j'implémente ce même camembert avec object. Que vais-je mettre comme "alternative" : exactement ce que je veux et ce que j'ai besoin : - Un simple résumé de l'info nécessaire à la compréhension du contenu. - Un tableau en html pur jus avec un titre, un résumé et tutti quanti. - Un tableau en html pur jus et une légende reprenant l'information nécessaire à la compréhension du contenu (au cas ou l'utilisateur passe outre la restitution du tableau). - Un simple résumé de l'info nécessaire à la compréhension du contenu ET un lien vers une ressource contenant un tableau en Html pur jus... - Tout autre chose d'encore plus pertinent. Quel que soit mon choix (et mes contraintes) je reste totalement maitre du jeux, je ne me pose plus la question de l'attribut, de la méthode, de la restitution, des palliatifs en cas défaillance, de manque de support ou de la nature du bulletin météo du lendemain. J'ai juste de l'info (l'image et son contexte) à proposer d'une autre manière, la plus pertinente et adaptée... Je ne fais plus de l'alternative (au sens rampe d'accès), je produis du contenu dont la restitution ne dépends que de la capacité de l'UA à interpréter l'un OU l'autre des canaux disponibles. C'est un détail qui à de l'importance car cela signifie que mon "alternative" est restituée dans son contexte, elle ne dépends pas d'une fonctionnalité, elle n'est pas restituée sous une forme particulière : c'est tout bêtement du contenu et rien d'autre. Ca ne change pas les problématiques de contextualisation, ca ne change rien aux statuts relatifs des images... En revanche ce que j'implémente joue le même rôle, au même moment et, du point de vue de l'information, de la même manière. Image ou pas image c'est bien pareil... Bon l'exemple est un peut caricatural puisqu'au final je ne fais que remplacer une méthode défaillante par une méthode efficace. C'est déjà pas si mal... En revanche et c'est sans doute ce qu'il faut retenir, c'est que du point de vue de l'information il n'y à pas de différence entre la ressource embarquée via l'attribut data et le ou les contenus "alternatifs" : dans les deux cas je fais ce que j'ai besoin de faire et le résultat c'est du contenu. A contrario il y à une vraie différence entre la ressource via l'attribut src d'une image et le contenu de l'attribut alt : avec src je fais bien ce que j'ai besoin et c'est du contenu, avec alt je fais surtout ce que je peux et ce n'est pas un véritable contenu. Bon je vais attaquer la moquette du voisin... Jean-Pierre |
| |
|
| mysegfault | # 16 Jul 2007 - 14:54:18 |
| 1 Posts |
Florent V. a écrit : Bonjour, J'ai participé au développement du site et on a vraiment pas mal travaillé sur le coté accessibilité du site. On a pas mal profité du site de alsacreations, autant le dire -- Maxime |
|
|
| Florent V. | # 19 Jul 2007 - 14:41:43 |
On va manger des chips. Modérateur 13463 Posts |
mysegfault a écrit :  |
| |
|
Pages : [<] |
|
Les références web : openweb.eu.org - opquast.com - webmaster-hub.com - webrankinfo.com - salemioche.net - web-pour-tous.org - webonorme.org
Nos partenaires : Editions Eyrolles
Nikozen : Hébergement - Réalisation : Alsacreations.fr