La comparaison CSS+XHTML vs Flash est complètement biaisé.

Le format qu'on devrait comparer à Flash c'est SVG+SMIL (SVG pour le stockage et smil pour l'interactivité).

CSS+XHTML n'est pas fait pour faire du dynamique : flash si (et même pratiquement exclusivement du dynamique). CSS+XHTML est une rationalisation du HTML pas un format idéal pour faire du dynamique même s'il est possible d'implémenter quelques comportement dynamique via CSS+XHTML.

Sans ce détail, l'article soulève de vrais problèmes (à mon sens) à propos de la norme : elle doit être utilisée. Le problème de SVG+SMIL c'est qu'aucun browser actuel n'est capable de gérer correctement ces formats. Donc, ils restent inutilisé et on leur préfère le flash.

Ceci dit, l'auteur de l'article passe sous silence un truc à propos de flash : l'indexation automatique des pages faites avec flash. Cette indexation est pratiquement impossible pour des moteurs de recherche classiques comme google ou yahoo. Alors qu'en CSS+xhtml non seulement c'est possible mais c'est fait. Pour permettre l'indexation des pages flash il faut utiliser des astuces largement plus pénibles que d'apprendre le css+html.

Amha, flash signe la mort d'internet tel qu'on le connait. Perso je ne surf pas sur internet à la recherche de "belles pages" (même si ça me fait plaisir de tomber sur certaines d'entre elles) mais pour y trouver services et informations. Et pour cela, le flash est sans intérêt voir nocif.

Ce qui ne veut pas dire que flash est un mauvais format, au contraire, c'est certainement un bon format, et un bon outil : mais pas pour faire tous les sites du monde, et pas pour faire un site entier.

Poste le Monday 23 May 2005 15:54:07

Citation
Léa (Fred)
CSS+XHTML n'est pas fait pour faire du dynamique : flash si (et même pratiquement exclusivement du dynamique). CSS+XHTML est une rationalisation du HTML pas un format idéal pour faire du dynamique même s'il est possible d'implémenter quelques comportement dynamique via CSS+XHTML.

Cet aspect (CSS+XHTML vs Flash) repose sur l'argument selon lequel les CSS sont volontairement bridées à de la pure description, ce qui empêche précisément d'obtenir une solution dynamique.

Citation
Arno*
Les CSS souffrent d’un dogme originel : les CSS ne doivent pas devenir un langage de programmation. Cette volonté est très discutable (ce que nous allons faire immédiatement), et fait apparaître des limites dans leur utilisation.

Ce qui le raccroche à l'argument de fond que je trouve le plus intéressant (bizarrement) : le net pour qui ? pour les pros uniquement ou pour tout le monde ? et si c'est pour tout le monde, celui qui se fait une petit site perso veut-il un site au normes ou un site sympa ? et quand les normes ne lui permettent pas de faire simplement ce qu'il veut, lequel des deux aspect va l'emporter ?

En fait dans un autre texte plus polémique [www.uzine.net] il critiquait avant tout le glissement muant les recommandations du W3C en conditions inaltérables. Là encore il insistait sur la souplesse nécessaire d'un code, l'erreur et le codage "sale" étant conçus comme une étape de l'apprentissage qui ne doit en rien empêcher la mise en ligne et la lecture des contenus. Ce qu'il met en cause c'est donc le côté "Ça pue c'est pas aux normes, il faut que ce soit au normes !!! X-o" qui ressort d'une lecture rigide des recommandations.

Moi-même, comme je pense pas mal de débutants sensibilisés à cette question, j'ai adopté de suite le xhtml 1.1 sans savoir exactement ce que ça apportait de plus (j'en suis resté à "C'est conforme au W3C donc c'est bien", sans réaliser - comme il est souligné - qu'on peut faire des trucs bien pourris en xhtml/css)... Alors oui ça apprend à coder plus proprement, oui, c'est plus orienté feuille de style, mais ne vaudrait-il mieux pas que celles-ci soit adoptées pour répondre à un besoin plûtot que comme un a priori canonique à toute publication sur internet ?

Bref, ce qui me paraît intéressant dans ce texte c'est l'aspect "oui les normes c'est très bien mais c'est pas marrant..." alors que précisément la normalisation devrait déboucher sur une explosions des possibilités puisqu'on n'a normalement plus à s'embêter avec la compatibilité à tel ou tel truc... explosion de possibilités qui devrait conduire à l'adoption des normes, bien plus que le simple et glacial jugement au W3C Validator.

Poste le Monday 23 May 2005 16:52:56

L'argument n'est pas nouveau l'équipe de SPIP a toujours déclaré vouloir faire sans le W3C

Poste le Monday 23 May 2005 17:17:04

On pourrait rapporcher cette problématique de l'apprentissage de l'écriture : l'othographe et la grammaire sont des normes, que l'on met du temps à apprendre, avec une phase assez longue pendant laquelle on fait des erreurs.
Ce qui ne m'empêche pas de comprendre ce que mon neveu de 5 ans tente d'écrire, même s'il me faut des efforts d'adaptation.
Et c'est là que le parallèle s'arrête : un navigateur, comme tout logiciel, est infoutu de s'adapter à la syntaxe de ce qu'il lit, au contraire d'un être humain... Donc le respect des normes est bien plus important.
Par contre, une norme genre XHTML, qui concerne relativement peu de "lecteurs"/navigateurs, doit pouvoir évoluer beaucoup plus vite qu'une langue comme le Français (combien de lecteurs dans la Francophonie ?)
En résumé, c'est indispensable d'avoir des normes dans ce domaine, mais elles ne doivent absolument pas être figées. Même que ça fait plus longtemps qu'on voit "transitional" qu'on attend la sortie de la prochaine debian, d'abord )

--
Primo : rien de ce que j'écris ne saurait avoir a priori valeur de vérité universelle et incontournable.
Secundo : ce post est placé sous la DSSL (Demerden Sie Sich Licence).
Tertio : les barbus mangent du nioubie au p'tit-déj.
Quarto : z'avez vu, j'ai rajouté un tertio ?

Poste le Monday 23 May 2005 17:19:42

le transitionnal, c'est juste parce que les webmaster (comme par exemple ceux de léa) on le flemme de faire le travail de passage à l'xhtml 1.1 strict

si les navigateurs affichait : "erreur xhtml n°12 : balise non valide bla bla" plutot qu'un truc ressemblant vaguement à quelque chose, ça éviterait au débutant de coder une grosse merde et de se demander pourquoi tel navigateur affiche tel truc avec son code et tel autre navigateur affiche tel autre truc. Alors, plutot que de pester contre le navigateur X qui fait nawak, il se dirait je code vraiment comme un pied.

Reste le pb des navigateurs infoutu de respecter correctement une page respectant les standards (à la limite quand la page ne respecte aucun standard : qu'il fasse ce qu'il veut). ...

Maintenant, pour reprendre le débat au début, le problème de coder en flash par rapport à coder en xhtml+css : c'est qu'avec flash il est livré des outils permettant de faire tout un tas de saloperie graphiques qui bougent et font des bulles sans rien coder, alors qu'on attend des éditeurs css capable d'éditer aussi simplement une CSS.

Poste le Monday 23 May 2005 17:43:08

Juste pour rajouter la "couche merlin8282" ^o^ je pense que les normes sont là pour être respectées (et c'est bien qu'elles existent et soient strictes). Le gars (ou la nana ;-) ) qui veut apprendre le *html, il commence à coder en transitional puis une fois prêt il se colle au strict. Arnaud a choisi un bon exemple: qui sur ce forum aime qu'on lui parle en SMS ? Ben avec les sites web c'est la même chose.

Sinon, le Flash, ça peut être bien mais il faut comme dit ne l'utiliser que ce pour quoi il a été fait: de l'animation. Et il ne faut vraiment pas en abuser, àmha. D'ailleurs, le flash n'est pas prévu pour les handicapés, aveugles, sourds, etc. alors que le *html l'est ! Par exemple, essaye de naviguer sur un site en flash avec links ou lynx, pour voir...

[v]technologies web ? allez voir chez Morgan ;-p, c'est notre Oracle du web... #%b[/v]

.:! L'être humain est au sommet de la chaîne alimentaire. Certes. Mais il est surtout au sommet de la connerie et de la bêtise... !:.
-- Pour les nouveaux linuxiens : Ce n'est pas en continuant de faire ce que l'on connaît que l'on pourra faire ce que l'on ne connaît pas --

Poste le Monday 23 May 2005 18:29:39

Merlin8282 > Tu souleve un point interessant: Une page qui est codé en HTML strict aurat t'elle un meilleur rendu que des pages en HTML traditionel ?

$ uptime
19:28:06 up 12 days, 20:46,  2 users,  load average: 213.96, 212.37, 208.44

Poste le Monday 23 May 2005 19:08:52

Citation
merlin8282
D'ailleurs, le flash n'est pas prévu pour les handicapés, aveugles, sourds, etc.

Je renchéris.
J’ajoute que passer son hacheteumeuleu à la moulinette automatique de tidy ne mange vraiment pas de pain et peut se scripter.

--
On ne prête qu’aux riches, et on a bien raison, parce que les autres remboursent difficilement.
-+- Tristan Bernard (1866-1947) -+-

Poste le Monday 23 May 2005 19:23:50

Citation
Léa (anne)
L'argument n'est pas nouveau l'équipe de SPIP a toujours déclaré vouloir faire sans le W3C.

Pourtant la dernière version de SPIP (1.8.1) est réputée (j'ai pas testé, je l'ai lu sur linuxfr) produire des pages conformes aux W3C. Le site de Spip lui même affiche un W3C xhtml 1.0... c'est cette position qui me paraît intéressante : il n'y a pas d'opposition à l'idée de normes, simplement une discussion de ce qui doit fonder cette norme.

Citation
Arnaud
Et c'est là que le parallèle s'arrête : un navigateur, comme tout logiciel, est infoutu de s'adapter à la syntaxe de ce qu'il lit, au contraire d'un être humain... Donc le respect des normes est bien plus important.

Oui, mais là où le navigateur diverge du logiciel classique c'est qu'il n'"exécute" rien, il interprète un flux et donne un rendu. Or le rendu basique peut toujours être rendu puisque tu peux accéder à un site avec un navigateur texte. Le navigateur peut donc se permettre d'ignorer une erreur et de ne rien faire. C'est d'ailleurs - si j'ai tout compris - ce qui est fait pour permettre l'accessibilité : il n'y a plus de mise en forme gauche/droite tout est remis dans un seul flux l'accessibilité consistant dans une bonne hiérarchisation des contenus. Basiquement, le parallèle avec la phrase ou le programme ne tient pas parce que le contenu peut toujours être traité (le html, comme le tex, ne gérant qu'une mise en forme).

Citation
Léa (Fred)
si les navigateurs affichait : "erreur xhtml n°12 : balise non valide bla bla" plutot qu'un truc ressemblant vaguement à quelque chose, ça éviterait au débutant de coder une grosse merde et de se demander pourquoi tel navigateur affiche tel truc avec son code et tel autre navigateur affiche tel autre truc. Alors, plutot que de pester contre le navigateur X qui fait nawak, il se dirait je code vraiment comme un pied.

Probablement... mais ça suppose que tous les navigateurs respectent les mêmes standards si bien que :

Citation
Léa (Fred)
Reste le pb des navigateurs infoutu de respecter correctement une page respectant les standards (à la limite quand la page ne respecte aucun standard : qu'il fasse ce qu'il veut). ...

Il sera impossible de régler ce problème (car les faveurs iraient sans conteste aux navigateurs plus tolérants), l'objectif étant de pousser à la norme, ce qui rejoint la thèse intéressante de l'auteur : à vouloir imposer la même sauce à tout le monde sans développer des vraies potentialités (des trucs qui donnent envie), on en arrive à quelque chose de contre-productif et (ça c'est moi qui l'ajoute) à part "comme ça y aura une vraie liberté de choix pour naviguer", on n'a pas grand chose pour argumenter. Argument d'autant plus faible que tous les webmasters sont loin d'être prêts à sacrifier la compatibilité IE (car je crois savoir que faire de la compatibilité avec IE6 nécessite souvent quelques entorses au W3C).

Poste le Monday 23 May 2005 19:38:16

L'article est très édifiant...

Un autre point intéressant qu'il soulève est le cercle vicieux de l'intégration des technologies.

Au début peu utilisée = pas d'intégration dans les navigateurs = pas de gens qui s'en servent = pas de logiciels autour = pas de développement de la norme = pas de raison de l'utiliser = pas d'intégration dans les navigateurs #%b

C'est dommage quand on voit le potentiel de choses comme le SVG, qui existe depuis des lustres et ne sera intégré nativement à Firefox que dans la prochaine version 1.1...

Sa critique de XHTML, qui est utilisé comme un "HTML 5", est parfaitement représentative de cet état d'esprit... Ben alors, elles sont où les eXtensions ?-(

Lâchez le SMIL, la 3D, le MathML, que diable ! }-F
Un format basé sur du texte sera toujours plus accessible que le-fichier-qu'on-peut-lire-qu'avec-le-plug-in-pas-documenté

On se met à essayer d'imaginer ce que ça aurait été si les normes Web étaient un projet libre, développé comme l'est PHP... Je n'y connais rien, mais je verrais cette réalité parallèle en plus bordélique, plus laxiste, mais bien plus dynamique... Mais bon, il y aurait 50 protocoles chacun dans son coin, non-centralisés...

Dites-moi si je me trompe, mais il rejette un peu la faute sur les développeurs des navigateurs, de ne pas vouloir se donner la peine d'intégrer les normes naissantes, ce qui leur donnerait un élan. D'un autre côté, sachant à quel point il est difficile de coder ça, ça se comprend :,(

Poste le Monday 23 May 2005 21:11:29

La comparaison que fait Arnaud avec l'apprentissage de la grammaire et de l'orthographe est àmha très pertinente. Le but, c'est que tout le monde parle un même langage, c'est tout. Cela peut relever du dogme chez certains, et pas chez d'autres, de même qu'en français, certaines personnes ont un certain désir de figer la langue française. Les normes ne sont pas dogmatiques àmha, ce sont les gens qui le sont ou non.

En tant que développeur web, si je juge cela nécessaire, je sacrifie parfois les normes, dans le sens ou parfois mon code ne valide pas: ce qui signifie que j'accepte sans problème de faire des entorses à la lettre pour respecter l'esprit (exemple courant: j'ai besoin d'un hack pour obtenir un effet important dans IE et aprés quoi, le css ne valide plus).

On peut faire des entorses aux recommendations du W3C: c'est l'esprit qui est important (interopérabilité, accessibilité, légéreté, ...), pas la lettre, et on peut faire de très beaux et bons sites de cette façon et même sous IE.

De la même façon, je pense que l'on tolére tous ici sur ce forum que des gens fassent des fautes (involontaires ou non d'ailleurs) tant que l'on arrive à se comprendre. On tolérera moins quelqu'un qui écrit en sms car il on lui reprochera de ne pas faire l'effort d'être compréhensible.

Après, il faut savoir ce que l'on veut:
- soit on veut des animations qui pétent et qui en mettent plein la vue et on fait du flash. C'est très bien, je n'ai rien à redire et j'apprécie particuliérement certaines animations flash.
- soit on veut du contenu (sans forcément sacrifier la forme, bien au contraire, la forme peut véhiculer du sens) et du contenu accessible.

La question à se poser quand on commence un site, c'est pourquoi ce site ?
Si la réponse est par exemple: "je fais ce site pour des professionnels de l'animation", bien évidemment, on va mettre des animations.
Si La réponse est: "je fais un site commercial qui doit proposer les mêmes fonctionnalités a tous les navigateurs", je respecte les standards et le flash n'a rien à faire ici (en plus, se posent ici les difficultés de référencement mentionnées par Fred).
Si la réponse est: "je fais un site perso sans autre but que de m'amuser", alors je fais ce que j'ai envie pour m'amuser. Ou alors "je fais un site perso pour me faire connaitre (ou ce que je fais)", quelle image je souhaite faire passer ?.

Citation
Perramus
Moi-même, comme je pense pas mal de débutants sensibilisés à cette question, j'ai adopté de suite le xhtml 1.1 sans savoir exactement ce que ça apportait de plus (j'en suis resté à "C'est conforme au W3C donc c'est bien", sans réaliser - comme il est souligné - qu'on peut faire des trucs bien pourris en xhtml/css)...

Ben oui, normal, il faut apprendre avant de pouvoir remettre en cause cet apprentissage, et alors ? Le xhtml/css n'empéche pas certaines personnes de faire des "trucs bien pourris", oui, et alors ? Personne ne dit que c'est une garantie ?
On peut se planter en réalisant un site, et même en respectant les standards, certes. Et cela aurait été mieux en réalisant une mise en page avec des tableaux et des balises obsolétes (genre font ou layer) ?
Ce que je peux dire, c'est que même une page bien pourrie codé en (x)html/css est moins lourde que la même page codée avec des tableaux et sans css! Bref, en 56k, tu as attendu moins longtemps pour voir cette page pourrie, Perramus, enjoy! ;-)

Quant au fait que le css ne soit pas un langage de programmation, ben oui! Mais cela permet à tout le monde de faire du (x)html/css sans avoir a connaitre l'algorithmie: problème d'accessibilité encore. Parce que ce n'est pas un langage de programmation, tout le monde peut l'utiliser, même les non-développeurs, et ça, je trouve cela bien, personnellement.
Ce qui n'empéche pas de le coupler avec du php (et oui, on peut générer du css en php!) ou du javascript (qui n'est pas à bannir, surtout pas, c'est un langage d'une puissance et d'une richesse incroyable: simplement, il ne doit pas indispensable à la lecture et à la navigation, la nuance est de taille tout de même). Je ne vois pas en quoi cela limite la portée des css que ce ne soit pas un langage de prog, àmha, c'est sa force et sa richesse!

Quant aux difficultés posés par l'intégration des nouvelles technologies, je crois que le choix du xml dans pas mal de standards (xhtml, svg, MathMl, ...) est lié autant à ses potentialités qu'à ses possibilités actuelles: l'histoire du web étant ce qu'elle est (conséquences de la "guerre" des navigateurs IE et netscape, monopole de IE provoquant sa non-évolution , etc...) , il aurait été illusoire àmha d'attendre un changement trop rapide. Je crois que globalement, on va dans la bonne voie. :-)

D'ailleurs, j'aimerais que l'on me donne un exemple d'innovation technologique importante dans le domaine du web ces 5 derniéres années qui ne soit pas lié aux standards ... (?)


___________________________________________________
L'interface chaise-clavier se débuggue elle aussi...

Poste le Tuesday 24 May 2005 00:30:23

Citation
Morgan
Ben oui, normal, il faut apprendre avant de pouvoir remettre en cause cet apprentissage, et alors ? Le xhtml/css n'empéche pas certaines personnes de faire des "trucs bien pourris", oui, et alors ? Personne ne dit que c'est une garantie ?
On peut se planter en réalisant un site, et même en respectant les standards, certes. Et cela aurait été mieux en réalisant une mise en page avec des tableaux et des balises obsolétes (genre font ou layer) ?
Ce que je peux dire, c'est que même une page bien pourrie codé en (x)html/css est moins lourde que la même page codée avec des tableaux et sans css! Bref, en 56k, tu as attendu moins longtemps pour voir cette page pourrie, Perramus, enjoy!

Bin justement, il y a pas mal de sites totalement navigables en 56k qui ne respectent pas les standards. Ex. [slackware.org], bon, on peut dire que "certes mais c'est roots" ce à quoi je répondrais que j'en connais plein d'autres (je vais pas vous faire la visite guidée du net selon Perramus) bien plus chiadés, navigables avec firefox et pourtant non conformes (en fait les temps d'attente sont surtout liés au chargement des images... et là c'est juste un problème de compression pas de codage). D'où le strict respect des standards n'est absolument pas une condition sine qua non d'une bonne navigabilité.

De plus, on peut ajouter que pour beaucoup le 56k c'est le Web à papa... déjà les sites en flash ont abandonné cette considération (je peux vous le dire, c'est galère les sites en flash en 56k), ce n'est donc plus vraiment un argument (enfin, en tout cas pas un argument efficace, non, non, rassurez-vous je ne milite pas pour un net où je n'aie plus le droit de naviguer ;-) ).

En fait, je pense qu'il serait intéressant de faire le parallèle avec l'adoption croissante de firefox. Qui peut penser que celle-ci est liée uniquement à son respect des standards : la plupart des gens ne savent pas ce qu'est un standard, ni à quoi ça sert[^][1][/^]. À mon avis firefox n'a pas gagné en visibilité face à IE parce qu'il était plus "moral", mais tout simplement parce qu'il est quelques année-lumières en avance sur ce dernier : il permet des choses impossibles à faire avec IE.

Citation
Morgan
D'ailleurs, j'aimerais que l'on me donne un exemple d'innovation technologique importante dans le domaine du web ces 5 derniéres années qui ne soit pas lié aux standards ...

C'est un peu forcé, àmha, puisque IE n'avance plus, pour avancer sans IE, il faut bien se regrouper autour de quelque chose pour "fédérer" les différents développements et espérer émerger.

Bref, il ne s'agit pas de dire "les standards c'est tout pourri mort aux standards !", mais juste de s'interroger sur la pertinence du jugement : "ça respecte pas les standards c'est pas bien". Car ça revient à biaiser la seule question intéressante pour un site :"est-il est visible avec tous ou la plupart des navigateurs ?" avec des considérations pour le coup entièrement dogmatiques. En fait, et c'est dans ce sens que me semble aller le texte, de la même manière que firefox révolutionne la navigation de ceux qui l'adoptent, il faudrait que les standards révolutionnent la conception et le potentiel des sites[^][2][/^].


[^][1] Et là je suis d'accord avec l'auteur sur la non-pédagogie du validateur... quand tu passes du html 4.1 au xhtml 1.1 juste en mettant un "/" dans les métatags de ta page, tu peux pas dire que tu comprennes grand chose et les explications du site (avec les subtiles différences entre html 4.1 strict, transitionnel, xhtml 1.0 strict, transitionnel, et xhtml 1.1) t'aident à en saisir l'intérêt : au final c'est mieux "parce que".[/^]

[^][2] Sans compter que ça déboucherait certainement sur des outils respectueux des standards et accessibles au plus grand nombre désireux d'eploiter ces possibilités nouvelles.[/^]

Poste le Tuesday 24 May 2005 10:58:19

En même temps, le validateur n'est qu'un outil pour vérifier si ta page est conforme ou pas. Il ne sert pas à expliquer. Il ne dit pas si la page est bien codée.

On peut faire du HTML correct et du xHTML imbitable.

Le fait de changer un / dans une page HTML ne rend pas une page conforme xHTML.

L'idée sous-jacente du xHTML+CSS : c'est la séparation forme/fond. La forme dans le CSS, le fond dans le xHTML. La différence fondamentale entre HTML et xHTML strict : les balises xHTML ne codent plus la typographie mais la sémentique. En gros, on ne dit plus "met en gras" mais "c'est important" et dans la CSS on code : "si c'est important : tu mets en gras". Je caricature je sais.

C'est d'ailleur en parti la critique que fait l'article : le CSS n'est pas assez complet et souple pour coder la mise en forme "fine" du texte. Il donne comme exemple l'accès à la seconde lettre d'un paragraphe, ou au 3ème paragraphe qui restent complexe et du niveau de la bidouille en CSS2 (en CSS3 je ne sais pas).

Poste le Tuesday 24 May 2005 12:23:23

Citation
Léa (Fred)
Le fait de changer un / dans une page HTML ne rend pas une page conforme xHTML.

D'accord, mais ça peut se réduire à ça car rien n'empeche d'utiliser des CSS avec du HTML. Le XHTML implique cet usage mais le HTML ne l'interdit pas.

Citation
Léa (Fred)
En même temps, le validateur n'est qu'un outil pour vérifier si ta page est conforme ou pas. Il ne sert pas à expliquer. Il ne dit pas si la page est bien codée.

Tout à fait, c'est d'ailleurs bien la thèse de l'article : la validation ou non au W3C n'est pas déterminante pour faire un site navigable ou une grosse bouse numérique, les standards doivent donc offrir un plus et c'est là qu'est le vrai combat.

Poste le Tuesday 24 May 2005 12:38:16

Citation
Perramus
(en fait les temps d'attente sont surtout liés au chargement des images... et là c'est juste un problème de compression pas de codage).

ben, pas tant que cela: tu peux garnir ta page d'éléments graphiques assez lourds et obtenir des temps de chargements très corrects en 56k, si tu les géres intelligemment...

Citation
Perramus
De plus, on peut ajouter que pour beaucoup le 56k c'est le Web à papa... déjà les sites en flash ont abandonné cette considération (je peux vous le dire, c'est galère les sites en flash en 56k), ce n'est donc plus vraiment un argument

Cela reste un argument pour plein de gens, détrompes-toi. Comme je l'expliquais ci-dessus, la question est: "Pourquoi ce site et à qui s'adresse t-il?", le choix de la technologie (flash ou pas, en l'occurence) découle de la réponse.

Citation
Perramus
Tout à fait, c'est d'ailleurs bien la thèse de l'article : la validation ou non au W3C n'est pas déterminante pour faire un site navigable ou une grosse bouse numérique, les standards doivent donc offrir un plus et c'est là qu'est le vrai combat.

Mais ils offrent un plus: ils offrent un langage commun:
[openweb.eu.org]

Après, évidemment, comme je le disais au-dessus, ce sont les gens qui peuvent être dogmatiques: il ne faut pas confondre respect des standards et vénération du validateur mais la-dessus, on est d'accord, il me semble.



___________________________________________________
L'interface chaise-clavier se débuggue elle aussi...

Poste le Tuesday 24 May 2005 14:23:00

Citation
Morgan
Mais ils offrent un plus: ils offrent un langage commun:
[openweb.eu.org]

Oui enfin, beaucoup de points souffrent une critique déjà évoquée (xhtml désolidarisable des CSS, respect des standards non déterminants par rapport à l'accessibilité, etc... ). Quant aux autres, ce sont des considérations qui n'entrent que dans des problématiques professionnelles.

En fait la question que tu abordes "Pourquoi ce site et à qui s'adresse t-il?", est formulée différemment par Arno* - pour résumer - "Les standards pour qui ?" réponse qui découle de la critique : pour les pros et puis c'est tout, car le codeur amateur n'a aucun intérêt à être en conformité avec les normes, ça ne lui apporte rien, ça ne lui ouvre rien. Résultat : les standards concernent au final peu de monde et le commun des codeurs mortels s'en fout. Ce qui signifie que l'unification visée du Web est en fait très relative, les amateurs continuant à coder en dehors de la norme ou - pire encore - à investir dans des solutions clé-en-main non-conformes. À moins de considérer comme les grands médias que le Web est soit un nouveau marché (ie: une nouvelle manière de consommer), soit un objet ludique inoffensif, il est quand même très dommage que la normalisation du Web se montre incapable de toucher l'ensemble de ses intervenants.

Poste le Tuesday 24 May 2005 16:08:29

L'attrait de l'interface graphique est très fort.

Le commun des mortels, même ceux qui s'y connaissent déjà en HTML, peut coder pendant des années du code non-valide qui marche pas partout avec plein d'appels javascript pour un oui ou pour un non grâce à Dreamweaver, ou pire encore avec des "solutions" comme Frontpage, Word ou OpenOffice Writer/Web.
Et tout cela sans même savoir qu'il existe du code valide et pourquoi.

Bien sûr, le tout sera testé sur un seul navigateur (IE, même si ça change en ce moment), avec pour seul souci que ça marche chez soi donc à peu près chez d'autres.

Je parle en connaissance de cause puisque je l'ai fait :-/
Et depuis que je "code" vraiment, au lieu de faire de la mise en page avec la souris, j'ai appris bien plus en 4 mois qu'en 4 ans auparavant...

Ainsi un web "normalisé" ne serait possible que si les outils étaient capables de produire du code de bonne qualité à peu près "standard".

Poste le Tuesday 24 May 2005 16:56:29

Citation
Perramus
En fait la question que tu abordes "Pourquoi ce site et à qui s'adresse t-il?", est formulée différemment par Arno* - pour résumer - "Les standards pour qui ?" réponse qui découle de la critique : pour les pros et puis c'est tout, car le codeur amateur n'a aucun intérêt à être en conformité avec les normes, ça ne lui apporte rien, ça ne lui ouvre rien.

?-(

Donc "le codeur amateur" s'en fout de tout cela:
- que le fruit de son travail soit visible par tout le monde dans les meilleures conditions possibles.
- que les documents qu'il rédige éventuellement ne soit pas dans un format qui garantisse leur pérennité.
- que son site ne soit pas facilement maintenable.
- que son site ait une structure qui favorise son référencement.

et je passe sur d'autres avantages de moindre importance (et j'en oublie probablement).

Le "codeur amateur", d'abord, c'est quoi ? Le mari de la "ménagére de moins de 50 ans" ?

Le "codeur amateur", puisqu'on prétend parler en son nom, ne me parait pas si naïf que l'on veut bien le dire: j'ai l'impression (mais c'est subjectif, hein, je n'ai aucun chiffres) qu'il y a plus d'amateurs que de "pros" (encore un mot dont on ne sait quelle réalité il recouvre vraiment d'ailleurs) qui respectent les normes.

___________________________________________________
L'interface chaise-clavier se débuggue elle aussi...

Poste le Tuesday 24 May 2005 17:21:08

Quant au fait que le xhtml soit désolidarisable du css, c'est important ?
J'y verrais plutôt un avantage des css, perso, il ne force personne: grâce à cela,tu n'es pas obligé de te mettre au xhtml pour faire du css, c'est plutôt sympa pour le "codeur amateur", non ?

___________________________________________________
L'interface chaise-clavier se débuggue elle aussi...

Poste le Tuesday 24 May 2005 17:32:36