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

Modifié par Arsene (13 Feb 2009 - 17:32)

mathmax a écrit :
Pour le CSS3, je m'attend évidement à quelque chose de BIEN plus puissant que le CSS 2, parce que c'est vraiment un langage préhistorique que l'on utilises actuellement...

D'une, je ne suis pas sûr que tu connaisse toutes les possibilités de CSS 2.1 (pour prendre quelque chose qui est plus d'actualité...). De deux, pour les possibilités de CSS 3, il ne faut pas s'y attendre mais se renseigner. C'est pas comme si c'était fait dans le secret!

Les évolutions proposées pour CSS 3 répondent à une grande partie des besoins graphiques. Pour ce qui relève de widgets applicatifs, voir du côté de:
- HTML 5;
- JavaScript;
- ARIA.
(+ SVG et Canvas, tant qu'à faire.)

En passant: si je me souviens bien d'une conversation récente avec Aurélien Levy, HTML + JS + ARIA = plus accessible que les possibilités intéressantes mais limitées de Flash pour l'accessibilité. Côté implémentation, celle d'ARIA 1.0 est pas mal dans certains navigateurs, notamment IE et Firefox.

mathmax a écrit :
J'espère au moins qu'on pourra faire des effets dynamiques

Ça dépend de ce que tu appelles un «effet dynamique». Mais il y a des propositions intéressantes du côté de CSS Animations (webkit), pas encore intégrées aux modules CSS3 par contre, faut voir ce que ça va donner.

mathmax a écrit :
des variables pour centraliser les valeurs comme les couleurs

En discussion/élaboration (avec des constantes plutôt que des variables). Notons tout de même que rien n'empêche de créer de manière assez simple des variables dans du CSS... avec un langage de script serveur quel qu'il soit.

mathmax a écrit :
des opérations sur les dimensions

In the works.

Quant à l'idée que Flash/Flex/Air/Silverlight bouffent HTML-CSS, je n'y crois pas plus que ça. Peut-être en partie pour de l'applicatif, mais même ça, ça reste incertain.

PS: oui, la V4 en Air c'est une blague. T'as pas saisi le concept du vendredÿ, toi.

mathmax a écrit :
Pour le CSS3, je m'attend évidement à quelque chose de BIEN plus puissant que le CSS 2, parce que c'est vraiment un langage préhistorique que l'on utilises actuellement...

Les CSS2 seraient déjà moins préhistoriques si on avait eu aut' chose que <table> et float: left; (genre display: table-cell; ou inline-block; sur des navigateurs pourris comme IE6 et Firefox 2)

trikar a écrit :
A se demander pourquoi, ici, il n'y a pas de salon dédié... Il y a pourtant beaucoup à dire et à faire.

Parce que Media-Box existait avant Alsacréations et que donc ça ferait doublon. Sibelius pourrait confirmer.

mathmax a écrit :
C'est une blague j'espère...

Bien sûr, y aura pas de "Jordan edition". D'ici à ce que la V4 commence, MS aura écrasé ces concurrents ! Ce sera Silverlight donc.
Modifié par Felipe (13 Feb 2009 - 17:38)

a écrit :
D'une, je ne suis pas sûr que tu connaisse toutes les possibilités de CSS 2.1 (pour prendre quelque chose qui est plus d'actualité...).

Si, je crois en avoir fait le tour...ou quasiment (je ne connais pas tous les hacks CSS pour IE 4 ou netscape... ). C'est d'actualité puisqu'on l'utilise mais je dis simplement que c'est vraiment trop basique et surtout pas assez factorisé.

Qu'est ce que la norme ARIA ? Je n'ai pas trouvé d'exemples sur le web (le long article du W3C ne me tente pas trop...). On peut déjà l'utiliser ?

mathmax a écrit :

Qu'est ce que la norme ARIA ? Je n'ai pas trouvé d'exemples sur le web (le long article du W3C ne me tente pas trop...). On peut déjà l'utiliser ?

Lire cette traduction: http://www.lesintegristes.net/2008/12/09/introduction-a-wai-aria-traduction/
Modifié par Hermann (13 Feb 2009 - 18:13)

a écrit :
Question accessibilité, il y a moyen de faire bien mieux avec ActionScript (Flash, Flex,...) que l'association XHTML/CSS/JS ne sait le faire

Prouvez-le !

Je considère aujourd'hui que le format HTML est celui le plus accessible pour transmettre un document texte structuré.
PDF c'est pourri, surtout à cause d'acrobate reader en fait, c'est un grouffre à RAM). Et office... c'est bien mais c'est plus lourd qu'un navigateur quand même. JE parle sérieusement, ceci n'est pas une mauvaise blague de vendredÿ.

Puisque qu'on parle d'accessibilité moi je pense que HTML c'est à peu près bien pour les documents mais c'est pas du tout fait pour les applications. Par exemple un forum c'est une application pour discuter et ça n'a rien à faire en HTML sur HTTP. Mais bon tout le monde à l'air de se foutre de la sémantique donc bon ...

mathmax a écrit :
C'est d'actualité puisqu'on l'utilise

Non, on le sous-utilise. Sans aller du côté des hacks ou de la magie noire style One True Layout (de toute façon pas intéressants de manière générale, vu les problèmes de complexité et de maintenance posés)... tu fais du display:table-cell, utilise des sélecteurs d'attributs, d'enfant, et autres fonctionnalités CSS 2.1 pas supportées par IE6, IE7, Firefox2, etc., et tout ça couramment?

Changaco a écrit :
Puisque qu'on parle d'accessibilité moi je pense que HTML c'est à peu près bien pour les documents mais c'est pas du tout fait pour les applications.

ARIA = Accessible Rich Internet Applications. Faut suivre, les gens.

Changaco a écrit :
Par exemple un forum c'est une application pour discuter

Oui, et ça fait des années que des applications de ce type existent avec des interfaces en HTML et CSS, en utilisant HTTP. Et ça marche finalement pas mal, y compris niveau accessibilité (pour peu que les technos soient bien utilisées). Et même: côté accessibilité, c'est souvent bien mieux que ce que proposent beaucoup d'applications Desktop. Je vois pas au nom de quoi il faudrait décréter que «c'est de l'applicatif, ça n'a rien à faire en HTML, CSS et HTTP». Ça me semble plutôt absurde.

Les standards du Web (HTTP, HTML, CSS, JavaScript, SVG, Canvas, etc.), utilisés avec des langages serveur, forment une plateforme applicative. On peut en comparer les mérites et limites avec ceux d'autres plateformes applicatives, avec plusieurs critères (possibilités, couts de développement, accessibilité, public potentiel...), mais les déclarations de principe sur le rôle idéal de telle ou telle techno ne servent pas à grand chose.

Depuis le clash Whatwg il est clair que Html - alias le canard étêté - s'oriente plus vers un langage "appli-porteur" que "data-porteur"... voir <canvas> et autres.
Donc faux procès à mon avis.

a écrit :
tu fais du display:table-cell, utilise des sélecteurs d'attributs, d'enfant, et autres fonctionnalités CSS 2.1 pas supportées par IE6, IE7, Firefox2, etc., et tout ça couramment?

Je les utilise mais le moins possible car ils ne sont justement pas supportés par les navigateurs.

Mais cala nous ramène à un truc que je n'ai encore jamais compris. Pourquoi diable va t-on inventer des nouveaux trucs pour améliorer les sélecteur css alors qu'il existe une norme Xpath bien plus puissante ! Plutôt que de passer un temps fou à nous sortir 3 nouveaux sélecteurs pourquoi n'adoptent t-ils pas cette norme ? Ils pourraient alors se concentrer sur les vrais besoins, à savoir un CSS beaucoup plus dynamique (dans tous les sens du terme) !

Bien sûr on peu faire du bricolage avec une technologie serveur, mais quelle perte de temps dans bien des cas...
Modifié par mathmax (13 Feb 2009 - 19:07)

mathmax a écrit :
Pourquoi diable va t-on inventer des nouveaux trucs pour améliorer les sélecteur css alors qu'il existe une norme Xpath bien plus puissante !

1. Par compatibilité arrière (système de niveaux).
2. Parce que Xpath c'est imbitable.

mathmax a écrit :
Ils pourraient alors se concentrer sur les vrais besoins

Sauf que les vrais besoins c'est... un peu tout.

mathmax a écrit :
Bien sûr on peu faire du bricolage avec une technologie serveur, mais quelle perte de temps dans bien des cas...

Je parlais des standards web + langages serveur comme couche applicative. Pas juste des technos serveur. Et toute couche applicative doit bien sûr être évaluée, et n'est pas nécessairement adaptée aux besoins. Arf, mauvais vendredÿ, on se retrouve à enfoncer des portes ouvertes.

Ca consiste en quoi exactement la norme ARIA ? J'avoue que j'ai du mal à trouver de la documentation en français ...

QuentinC a écrit :
Ca consiste en quoi exactement la norme ARIA ? J'avoue que j'ai du mal à trouver de la documentation en français ...

Une traduction par ici.

a écrit :
Parce que Xpath c'est imbitable.

Bof, je trouve pas. Question d'habitude, je pense. Evidement c'est plus complexe car plus complet mais si on continue à ajouter des trucs aux sélecteurs CSS on se retrouvera certainement avec la même complexité...

Mais encore une fois ce qui m'étonne le plus c'est la lenteur du W3C. Ils n'ont pas d'implémentation à faire, ils ont simplement une norme à définir. Ca devrait prendre quelques mois tout au plus, pas des années non ?

Florent V. a écrit :
Oui, et ça fait des années que des applications de ce type existent avec des interfaces en HTML et CSS, en utilisant HTTP. Et ça marche finalement pas mal, y compris niveau accessibilité (pour peu que les technos soient bien utilisées). Et même: côté accessibilité, c'est souvent bien mieux que ce que proposent beaucoup d'applications Desktop. Je vois pas au nom de quoi il faudrait décréter que «c'est de l'applicatif, ça n'a rien à faire en HTML, CSS et HTTP». Ça me semble plutôt absurde.

Ces trois langages n'ont pas été conçus pour transporter des applications. Appliquer des patchs encore et toujours pour assurer la compatibilité ça marche un temps mais au bout d'un moment faut construire quelque chose de neuf.
Il faut arrêter de vouloir tout faire passer par HTTP alors que ce n'est même pas une technologie bi-directionnelle.
Il faut arrêter de penser que OpenID vaincra alors que c'est mal conçu. Ça ne respecte même pas vraiment le concept de couches du réseau puisque c'est basé sur HTTP. Les seules qui semblent comprendre ça c'est les fans de XMPP.
Il faut arrêter de vouloir tout faire en HTML juste parce que c'est compatible avec tous les OS qui ont un navigateur Web.

Florent V. a écrit :
Les standards du Web (HTTP, HTML, CSS, JavaScript, SVG, Canvas, etc.), utilisés avec des langages serveur, forment une plateforme applicative. On peut en comparer les mérites et limites avec ceux d'autres plateformes applicatives, avec plusieurs critères (possibilités, couts de développement, accessibilité, public potentiel...), mais les déclarations de principe sur le rôle idéal de telle ou telle techno ne servent pas à grand chose.

Si on ne réfléchit jamais à comment ça devrait être alors ça ne le sera jamais.

bzh a écrit :


Une traduction par ici.

J'ai pas pu m'empêcher : j'ai même pas lu le quart de l'article que j'ai voulu essayer tout de suite.

Si seulement tous les développeurs d'applications AJAX pouvaient utiliser ça... Non non rendormez-vous vous autres facebook et tweeter entres autres, c'est pas vous que je montre du doigt.

C'est une véritable révélation que j'apprends ce soir. 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)

Important à noter toutefois : ça marche avec firefox, mais pas avec IE. Pour une fois que firefox bat IE dans le domaine de l'accessibilité, ça vaut le coup d'être mentionner tant c'est rare... Faudra vraiment que je passe à firefox pour ma navigation quotidienne un de ces quatre. Oui, faudra que j'y pense sérieusement.

Rajout : Les attributs permettant de notifier la mise à jour d'un élément (les zones live comme ils les appellent) ne fonctionnent pas avec jaws, faudra que je teste avec NVDA à l'occasion.
Modifié par QuentinC (13 Feb 2009 - 23:10)

mathmax a écrit :
Parce que Xpath c'est imbitable.

Mais encore une fois ce qui m'étonne le plus c'est la lenteur du W3C. Ils n'ont pas d'implémentation à faire, ils ont simplement une norme à définir. Ca devrait prendre quelques mois tout au plus, pas des années non ?
Ne préjuge pas si vite de la facilité de la chose, tu ne sais pas comment se passe au W3C.
C'est beaucoup plus complexe que tu ne l'imagines (problèmes de communications, de difficultés techniques, de limitations dans les possibilités d'implémentations des navigateurs, désaccords de tous types, etc.) mais n'étant pas au cœur du système je pourrai pas t'en dire plus.
Pour connaître les détails du processus d'implémentation, tu peux lire le Document de processus

QuentinC a écrit :
Important à noter toutefois : ça marche avec firefox, mais pas avec IE. Pour une fois que firefox bat IE dans le domaine de l'accessibilité, ça vaut le coup d'être mentionner tant c'est rare...

Ç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?

@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.

@mathmax: Non, on ne torche pas une spécification en quelques mois. Déjà, la spécification CSS3 est d'une complexité telle que même à tambour battant il aurait fallu des années pour l'écrire, en comptant sur une phase de discussion réduite au strict minimum. Ensuite, tu n'as pas l'air familier de la notion de standard industriel. Un standard W3C ce n'est pas une documentation pondue par un éditeur unique pour utiliser son langage maison ou son API! C'est un processus itératif et consensuel entre plusieurs acteurs industriels d'un marché, et par nature ça prend du temps. Par ailleurs, ça aurait une connerie que de produire très rapidement une norme mal foutue (CSS 2 a été en partie victime de ce travers, d'où la nécessité d'un CSS 2.1...), et les éditeurs de navigateurs n'en voulaient pas. Et qui fournit l'effort principal pour le travail sur CSS 3? Les éditeurs de navigateurs, bien entendu, vu que ce sont eux les acteurs industriels concernés.

a écrit :
@mathmax: Non, on ne torche pas une spécification en quelques mois. Déjà, la spécification CSS3 est d'une complexité telle que même à tambour battant il aurait fallu des années pour l'écrire, en comptant sur une phase de discussion réduite au strict minimum. Ensuite, tu n'as pas l'air familier de la notion de standard industriel. Un standard W3C ce n'est pas une documentation pondue par un éditeur unique pour utiliser son langage maison ou son API! C'est un processus itératif et consensuel entre plusieurs acteurs industriels d'un marché, et par nature ça prend du temps. Par ailleurs, ça aurait une connerie que de produire très rapidement une norme mal foutue (CSS 2 a été en partie victime de ce travers, d'où la nécessité d'un CSS 2.1...), et les éditeurs de navigateurs n'en voulaient pas. Et qui fournit l'effort principal pour le travail sur CSS 3? Les éditeurs de navigateurs, bien entendu, vu que ce sont eux les acteurs industriels concernés.

Ok admettons... ça me dépasse un peu quand même 10 ans de travail pour l'élaboration d'une norme CSS mais bon si on a quelque chose de vraiment révolutionnaire au final pourquoi pas...
Est-on encore loin de la date de sortie ?
Modifié par mathmax (14 Feb 2009 - 03:59)

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)