CSS 3 : mais qu'attend-on pour valider cette norme !?!

(reprise du message précédent)

Florent V. a écrit :
@Changaco: C'est un désaccord de fond, alors. Tu as l'air d'avoir décidé que les principales technos web étaient une mauvaise couche applicative, à bannir. Pour ma part je reste ouvert et je trouve des intérêts divers à ces technos pour de l'applicatif, même si bien sûr ça ne correspond pas à tous les besoins.

Je pense simplement que comme les machines sont de plus en plus puissantes on ne prend plus la peine de faire de l'optimisation et je trouve que ça c'est dommage.

Faut pas mal interpréter ce que je dis, j'adore XML sous toutes ses formes mais je pense que l'on ne peut pas utiliser une de ses formes pour tout faire. Pourquoi pas un vrai vrai langage web pour documents et un autre pour les applications ?
Par contre je pense en effet que JavaScript est un langage qui a été créé pour rendre le Web un peu plus dynamique et que son utilisation un peu partout n'est pas forcément une bonne idée. Il existe de nombreux langages de programmation, pourquoi ne pas essayer de rassembler tous leurs avantages ?
En ce qui concerne DOM je trouve que c'est un truc génial qui devrait être plus utilisé sous Linux.

Je pense qu'il est dommage de se laisser restreindre par HTTP. Par exemple les Server Side Events de HTML5 c'est du gros bricolage ...
Modifié par Changaco (14 Feb 2009 - 09:25)

QuentinC a écrit :

En tout cas moi c'est décidé, j'applique immédiatement, et tant pis pour la validation W3C (si ce n'est que ça à payer, osef).

Tu peux tout à fait faire une page conforme et ajouter les attributs ARIA en javascript, c'est expliqué plus bas dans l'article.
Modifié par Patidou (14 Feb 2009 - 10:58)

a écrit :
Ça devrait marcher plutôt bien (voire mieux que dans Firefox) avec IE8, qui améliore le support d'ARIA au niveau du navigateur et d'une bibliothèque système
pour l'accessibilité dont j'oublie le nom. Je crois aussi qu'il y a un début de support avec IE7, mais ça reste à voir. Tu as testé avec IE6 ou 7?

J'ai pas IE8 donc je ne sais pas ce qu'il en est avec lui. J'ai testé dans les configurations suivantes, celles que j'ai sous la main :
IE6 + JFW7.1 : que dalle
FX2 + JFW7.1 : que dalle
IE7 + JFW9.0 : Que dalle
FX3 + JFW9.0 : Les exemples présentés fonctionnent plus ou moins, le slider, la case trois états ou le bouton.

Patidou a écrit :
Tu peux tout à fait faire une page conforme et ajouter les attributs ARIA en javascript, c'est expliqué plus bas dans l'article.

Oui mais ça c'est feinter pour pas grand chose. Théoriquement, une page devrait être conforme après manipulation du DOM par JavaScript. Il faudrait donc valider le code HTML généré plutôt que le code HTML brut.

Mais je rappelle à nouveau que la validation est un outil et pas un but en soi. Si tu sais pourquoi ta page est invalide (utilisations de l'attribut tabindex sur des éléments non prévus en HTML 4, utilisation d'attributs ARIA), et que tu sais quelles sont les conséquences, peu importe que la page ne soit pas valide. Ça sera valide en HTML 5 de toute manière.

Générer les attributs ARIA en JavaScript n'est cependant pas idiot, car en général on en a besoin pour des widgets gérés ou créés en JavaScript (+ HTML et CSS), et en l'absence de JS on n'en a pas besoin. Mais l'idée ici serait de respecter un principe de programmation JS non intrusive, pas de valider le HTML pour se faire plaisir.

QuentinC a écrit :
J'ai pas IE8 donc je ne sais pas ce qu'il en est avec lui.

Ok. Je pense que tu pourras l'installer lorsque la version finale sortira, ça devrait donner quelque chose de pas mal pour ARIA. Ils ont en tout cas annoncé à deux reprise des améliorations significatives du support d'ARIA dans IE8, donc ça devrait marcher un minimum, et peut-être un maximum.
Modifié par Florent V. (14 Feb 2009 - 11:35)

Florent V. a écrit :
Générer les attributs ARIA en JavaScript n'est cependant pas idiot, car en général on en a besoin pour des widgets gérés ou créés en JavaScript (+ HTML et CSS), et en l'absence de JS on n'en a pas besoin.

C'est ce que je me disais, et comme une application web est censée fonctionner js désactivé…

Patidou a écrit :
et comme une application web est censée fonctionner js désactivé…

Ça, ça reste discutable. Surtout maintenant qu'on a un moyen correct de rendre les applis JS accessibles.

Olah il y a beaucoup de trollage par ici. Mais c'est intéressant.

Je crois que l'on compare un peu trop des technologies ayant un historique radicalement différent entre elles et ce que l'on peut en attendre. XHTML+CSS+JS ne pourra jamais se transformer en Flash/AIR et inversement (ou alors en 2050). On ne pourra de toute façon pas regrouper les langages s'exécutant côté serveur et ceux s'exécutant côté client.

Javascript n'est pas une béquille, c'est un langage normalisé ECMA qui est exploité dans bon nombre de situations, pas seulement pour agir sur le DOM ou pour faire tomber de petits flocons de neige en gif le jour de l'an.

Adobe délivre une solution quasiment tout-en-un avec AS3. C'est très pratique, cela tourne plutôt bien et cela ouvre le chemin à d'autres implémentations (pour les citer les tags media de HTML5 qui ne sont rien d'autre qu'une concrétisation des players Flash de Youtube).

Il y a de grands manques côté XHTML/CSS/JS que comblent en partie les librairies. Avec les inconvénients que cela comporte, mais cela reste au moins modulaire.
Par exemple jQuery/mooTools/scriptaculous pour le dynamisme.
Par exemple Flash (ou SVG) pour le vectoriel.
Mais l'appropriation de ces techniques qui mettent souvent en œuvre plusieurs langages différents (cf animation SVG dans une page web qui fait appel jusqu'à 5 langages) est beaucoup plus lente que les IDE all-in-one d'Adobe.

Au niveau accessibilité, Flash/AIR ne sont sûrement pas parfaits, mais lorsqu'Adobe aura décidé de s'attaquer sérieusement au sujet (cela s'améliore de version en version), ils pourront sortir une implémentation très rapidement (moins de 2 ans) tandis que la finalisation des spécifications par le W3C prendra toujours trop de retard par rapport à ce que le marché attend. Oui le marché, car c'est bien l'économie qui tire ces besoins vers le haut, et CSS3 même en donnant un coup d'accélérateur, ne pourra certainement pas combler ces manques.

La désactivation de Javascript est de plus en plus rare. Ce qui était d'actualité en 98-2000 lorsque les pages étaient lourdes, que JS n'était utilisé que rarement à bon escient, ne l'est plus aujourd'hui : il est devenu presque impossible d'utiliser les sites "grand public" sans JS, et les "nouveaux internautes" ne se focalisent plus sur cette désactivation qui était parfois recommandée - à tort - dans les bouquins ou magazines comme palliatif à une sécurité défailllante.

Les forums ont toujours existé en HTML sur HTTP, cela n'est pas choquant, cela reste du contenu textuel principalement que l'on consulte "à la demande". Et HTTP n'est pas uni-directionnel, il est bien bi-directionnel mais qualifié de "mode déconnecté" ce qui signifie que la connexion TCP n'est pas persistante entre le client et le serveur. Cela induit bien sûr une latence supplémentaire dans les RIA et un overhead important, mais cela s'améliore avec les connexions "haut-débit" de nos jours ; le RTC est (quasi) oublié.

Il y aura de plus en plus de couches applicatives. Dans le temps on écrivait un programme en C et cela s'arrêtait là, avec peut-être une lib graphique et des system calls, cela nous fait 3-5 couches supperposées. Et lorsqu'on pense au nombre de technologies mises en jeu pour délivrer un simple kikoolol.png en Ajax (stockage, OS, serveur HTTP, langage de script type PHP, les 7 couches du modèle OSI, la pile IP du client, le navigateur, le moteur de rendu, JavaScript, HTML, CSS, les bases de données, et ainsi de suite)... Ceci est donc un vrai métier dans lequel il est souvent indispensable d'être over-multi-polyvalent, et ce n'est pas facile à expliquer aux gens qui ne voient qu'un petit pixel bouger naturellement sur l'écran.

dew a écrit :
Au niveau accessibilité, Flash/AIR ne sont sûrement pas parfaits, mais lorsqu'Adobe aura décidé de s'attaquer sérieusement au sujet (cela s'améliore de version en version), ils pourront sortir une implémentation très rapidement (moins de 2 ans) tandis que la finalisation des spécifications par le W3C prendra toujours trop de retard par rapport à ce que le marché attend. Oui le marché, car c'est bien l'économie qui tire ces besoins vers le haut, et CSS3 même en donnant un coup d'accélérateur, ne pourra certainement pas combler ces manques.

Pour moi le W3C avance lentement à cause de Microsoft.

dew a écrit :
La désactivation de Javascript est de plus en plus rare. Ce qui était d'actualité en 98-2000 lorsque les pages étaient lourdes, que JS n'était utilisé que rarement à bon escient, ne l'est plus aujourd'hui : il est devenu presque impossible d'utiliser les sites "grand public" sans JS, et les "nouveaux internautes" ne se focalisent plus sur cette désactivation qui était parfois recommandée - à tort - dans les bouquins ou magazines comme palliatif à une sécurité défailllante.

On est encore beaucoup à désactiver JS parce que les trucs kikoolol qui sont faits avec ne nous plaisent pas.

dew a écrit :
Les forums ont toujours existé en HTML sur HTTP, cela n'est pas choquant, cela reste du contenu textuel principalement que l'on consulte "à la demande". Et HTTP n'est pas uni-directionnel, il est bien bi-directionnel mais qualifié de "mode déconnecté" ce qui signifie que la connexion TCP n'est pas persistante entre le client et le serveur. Cela induit bien sûr une latence supplémentaire dans les RIA et un overhead important, mais cela s'améliore avec les connexions "haut-débit" de nos jours ; le RTC est (quasi) oublié.

Pour moi une mailing-list ça remplit la même fonction qu'un forum (sans l'édition de message ceci dit) et ça ne dépend pas de HTTP.

dew a écrit :
Il y aura de plus en plus de couches applicatives. Dans le temps on écrivait un programme en C et cela s'arrêtait là, avec peut-être une lib graphique et des system calls, cela nous fait 3-5 couches supperposées. Et lorsqu'on pense au nombre de technologies mises en jeu pour délivrer un simple kikoolol.png en Ajax (stockage, OS, serveur HTTP, langage de script type PHP, les 7 couches du modèle OSI, la pile IP du client, le navigateur, le moteur de rendu, JavaScript, HTML, CSS, les bases de données, et ainsi de suite)... Ceci est donc un vrai métier dans lequel il est souvent indispensable d'être over-multi-polyvalent, et ce n'est pas facile à expliquer aux gens qui ne voient qu'un petit pixel bouger naturellement sur l'écran.

Ajouter des couches c'est bien mais ça tue les performances donc faut toujours y réfléchir à deux fois avant de le faire.

Changaco a écrit :
Pour moi le W3C avance lentement à cause de Microsoft.

A cause de sa structure et de son mode de fonctionnement, que ce soit Microsoft ou une autre entité, à partir du moment où il faut concilier tout le monde il y aura toujours quelqu'un pour freiner ou pour défendre son bifteck.

Changaco a écrit :
On est encore beaucoup à désactiver JS parce que les trucs kikoolol qui sont faits avec ne nous plaisent pas.

Oui mais vous êtes des power-users. C'est à dire 0.01% des utilisateurs.

Changaco a écrit :
Pour moi une mailing-list ça remplit la même fonction qu'un forum (sans l'édition de message ceci dit) et ça ne dépend pas de HTTP.

C'est très différent et beaucoup moins pratique.
La mailing-list abreuve d'information, sur le forum on peut choisir ce que l'on souhaite lire, à son propre rythme.

Changaco a écrit :
Ajouter des couches c'est bien mais ça tue les performances donc faut toujours y réfléchir à deux fois avant de le faire.

A notre époque, de moins en moins... C'est pourquoi on voit de plus en plus de langages interprétés et de virtualisation.

dew a écrit :
A cause de sa structure et de son mode de fonctionnement, que ce soit Microsoft ou une autre entité, à partir du moment où il faut concilier tout le monde il y aura toujours quelqu'un pour freiner ou pour défendre son bifteck.

Ouais c'est toujours le même problème. "Il y a cent façons de devenir riche: quatre-vingt dix-neuf sont malhonnêtes." Marcel Mithois.

dew a écrit :
C'est très différent et beaucoup moins pratique.
La mailing-list abreuve d'information, sur le forum on peut choisir ce que l'on souhaite lire, à son propre rythme.

La mailing-list peut être moins pratique en effet mais c'est quand même un "type de forum" que ne dépend pas de HTTP et qui était là bien avant si je ne m'abuse.

dew a écrit :
A notre époque, de moins en moins... C'est pourquoi on voit de plus en plus de langages interprétés et de virtualisation.

C'est bien ce que je critique.

Changaco a écrit :
La mailing-list peut être moins pratique en effet mais c'est quand même un "type de forum" que ne dépend pas de HTTP et qui était là bien avant si je ne m'abuse.

Admettons. Et ça démontre quoi, à part le fait que HTTP n'est pas indispensable pour ce type d'application? (Il n'est d'ailleurs indispensable pour aucune. Juste utile.)

Changaco a écrit :
C'est bien ce que je critique.

Et que d'autres ne critiquent pas.
Désaccord de fond, j'vous disais.

Florent V. a écrit :
Admettons. Et ça démontre quoi, à part le fait que HTTP n'est pas indispensable pour ce type d'application? (Il n'est d'ailleurs indispensable pour aucune. Juste utile.)

Pas grand chose c'était juste pour clarifier ce point sur les forums dans le message de dew.

Florent V. a écrit :
Et que d'autres ne critiquent pas.
Désaccord de fond, j'vous disais.

C'est un gain de temps, donc un gain d'argent.