Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - standards web

Fil des billets - Fil des commentaires

mercredi, juin 25 2008

Openweb n'est pas mort

Si vous pensiez qu'Openweb, l'un des tout premiers sites francophones sur les standards, était mort, vous êtes dans le faux.

L'équipe s'est plus ou moins renouvelée depuis quelques mois, et quelques nouveaux articles ont été publié. Mais ce n'est pas fini.

Lire la suite...

mercredi, avril 9 2008

Variables en CSS

Vous en avez rêvé ? Daniel et David vont l'ont fait : Les variables CSS. Pour l'instant, ce n'est que le brouillon d'un brouillon d'une future recommandation, mais les commentaires sont les bienvenu. Vous pouvez les faire sur le blog de Daniel ou ici, je transmettrai ;-).

En gros, comment ça fonctionnera (en faisant l'hypothèse que la spec ne changera pas trop :-) ) :

@variables {
 CorporateLogoBGColor: #fe8d12;
}

div.logoContainer {
 background-color: var(CorporateLogoBGColor);
}

Les variables sont définies dans un bloc d'une règle @variables. Ici la variable CorporateLogoBGColor est déclarée avec la valeur #fe8d12. Ensuite, pour l'utiliser dans les propriétés de style, on utilise l'instruction var() avec le nom de cette variable.

Alors attention, il s'agit bien d'une variable, et non pas d'une constante, puisque, cerise sur le gâteau, on peut modifier sa valeur via le DOM style. Vouloir modifier la variable CorporateLogoBGColor reviendra à faire ça :

 document.styleSheets[0].cssRules[0].variables.setVariable('CorporateLogoBGColor', '#000');

PS: je vais proposer à Daniel une manière plus simple de modifier une variable, par exemple :

 document.styleSheets[0].setVariable('CorporateLogoBGColor', '#000');

jeudi, mars 27 2008

Acid3: le gagnant est ...

Mise à jour 15h12 : Arg, Ian indique qu'un bug a été découvert dans Acid3, et du coup Opera est redescendu à 99/100 :-) La course continue !

Mise à jour 15h00 : Webkit a "un peu" triché au niveau de son score 100/100. L'une des étapes de Acid3 test les animations SVG. Or pour ce test, Webkit a juste implémenté une interface pour que le test passe. Et donc en fait, les animations dans SVG ne sont pas implémentées ! Plus d'explications sur ce blog, où son auteur a fait passé la suite de test SVG au moteur webkit... Avec peu de succés... En fait Webkit n'implémente pas beaucoup plus SVG que Firefox 3... Alors qu'Opera a une très bonne implémentation de SVG.


...Webkit ! Ou Opera ! Incroyable ! Le même jour ! Je ne pensais pas la course si serrée.--

Bon, mais, pas tout à fait en fait. Les bureaux d'Opera sont situés en Europe. Ceux de Apple/webkit, aux États Unis si je ne me trompe pas. Si on pose l'hypothèse que les heures de publications des billets correspondent aux fuseaux horaires de ces deux endroits, alors c'est Opéra qui a gagné !

Mais, mais... C'est Webkit qui fournit le premier une version dispo au grand public..

Bon, allez, pas de jaloux, ils sont tout les deux sur la première marche :-)

Conçernant Firefox 3 : il ne passera jamais le test acid3. Le compteur restera bloqué aux alentours de 71/100. En effet, la sortie de la version stable de Firefox 3 approchant à grand pas, ce n'est plus le moment (depuis un bout de temps d'ailleurs), d'aller modifier en profondeur Gecko. Les développeurs se concentrent en ce moment sur la correction des bugs critiques. En effet, ce qu'il manque pour passer le test acid3 complet, ce sont des choses comme l'implémentation des animations SVG, l'implémentation des fontes téléchargeables etc. Et ce sont des gros morceaux à coder, pas le temps pour le moment donc. Il va donc falloir attendre au moins la version suivante de Firefox (3.5, ou 4, on ne sait pas encore).

Bon, heureusement pour Mozilla, il y a Internet Explorer qui occupe toujours la place du dernier :-)

Félicitations aux développeurs de Webkit et Opera !

vendredi, mars 7 2008

Glazou, co-chairman du CSS working group

Daniel Glazman, aka glazou, vient d'être nommé co-chairman du CSS Working Group au W3C. Félicitation à toi Daniel !

J'ai comme l'impression que ça va bouger un peu plus du coté de CSS3 ;-)

samedi, février 23 2008

La course acid3

En ce moment, entre les moteurs de rendu web, c'est la course à celui qui passera les tests acid3 au complet le plus tôt possible.

Je viens de voir par exemple que la nightly de Webkit a un score de 86/100 ! Alors qu'il y a quelques jours il n'en était qu'à 79/100 apparement. La nightly de Firefox (future beta4) en est aujourd'hui à 67/100. La beta 3 ayant un score de 59/100.

Quant à IE, son score actuel est... Non rien...

C'etait Laurent, du stand Mozilla, en direct du Fosdem. À vous les studios

mardi, février 19 2008

Support des selecteurs CSS3 amélioré dans Firefox 3.0

David Baron vient d'intégrer dans les sources de Firefox 3 des corrections sur les sélecteurs de pseudo classes (genre :empty, :only-child, :last-child etc..). Avant, par exemple, il y avait un bug avec :empty : la sélection se faisait bien au chargement du document, mais si un élément non vide devenait vide ou l'inverse, la sélection ne se faisait plus. Et je vous parle de :empty parce que ce bug m'empêchait d'utiliser ce sélecteur dans Etna, mon éditeur XML wysiwyg, et m'obligeait du coup à des petites acrobaties dans le code qui me déplaisaient.

Ainsi, grâce à cette correction, le support des sélecteurs CSS3 dans Firefox 3.0b4 sera largement amélioré, la suite des tests de css3.info en atteste. Voici un comparatif :

Résultats des tests de la prise en charge de 43 sélecteurs CSS3
Firefox 2Firefox 3.0b3Firefox3.0b4
Sélecteurs OK263236
Sélecteurs buggés1040
Sélecteurs non supportés777
Total des tests ok357/578369/578374/579

En fait, il ne reste plus que 7 sélecteurs à implémenter correctement : :nth-child(), :nth-last-child(), :first-of-type, :last-of-type, :only-of-type, :nth-of-type(), :nth-last-of-type(). Peut-être y'aura-t-il encore des améliorations sur ceux-là d'ici Firefox 3 final mais ce n'est pas encore sûr.

À noter que webkit (safari et Konqueror) ainsi qu'opera je crois, passent la suite de test complètement avec succés.

PS : une autre conséquence de cette correction est que trois tests supplémentaires passent avec succés [au test acid3|http://acid3.acidtests.org/], avec un score de 64/100.

vendredi, février 1 2008

Test Acid3

Le premier test acid se focalisait sur le modèle de boîte CSS. Le test acid2 se focalisait sur CSS en général, sur le support de PNG. Voici maintenant le test acid3, qui se concentre plus sur l'ensemble des technologies web, comme HTML, CSS, ECMAScript, SVG et XML. Les 100 tests sont réalisés aux travers de l'api DOM.

Dans les navigateurs que j'ai pu lancer :

  • Firefox 2 (linux et windows) : 50/100
  • Firefox 3b3 (linux) : 59/100
  • Firefox 3b4 en cours de dev (linux) : 64/100
  • Konqueror 3.5.8 (linux) : il plante (crash) lamentablement durant le test
  • Opera 9.25.687 (linux) : 47/100
  • IE6 (windows) : 13/100 (ridicule, mais logique pour un navigateur aussi vieux)

Notez toutefois que la suite de tests est en "rodage", comprendre par là qu'il y a peut être quelques bugs à corriger avant que cela devienne "officiel" (et donc les scores changer dans les navigateurs).

jeudi, janvier 24 2008

Changements : IE8 et le doctype switching

Revirement de situation, par rapport à l'annonce faite hier. IE8 supportera le "DOCTYPE switching" avec HTML5. C'est à dire que si vous utilisez HTML5 et que vous indiquez son doctype, IE8 passera en mode "super mega standard".

Bref, vous mettrez

 <!DOCTYPE html>

et plus besoin de cette balise meta. Notez aussi que Firefox et d'autres navigateurs basculent eux aussi en mode standards avec ce doctype.

En quoi cela change par rapport à la meta ? Cela change que le rendu dépendra du type de document, et non pas d'une balise mise aléatoirement. Ce qui en terme de pérennité est plus rassurant. Et cela veut dire qu'à l'avenir, les développeurs web auront certainement moins de problèmes, et que probablement, il n'y aura pas un nième mécanisme dans IE pour tout changer.

Sachant que HTML5 sera implémenté dans la majorité des navigateurs, et apparemment aussi dans IE8 (cela ne veut pas dire que tout sera implémenté tout de suite ou jamais), vous pouvez d'hors et déjà vous pencher sur les nouveautés de HTML5.

Pour plus de détails, voir le billet de John Resig.

mercredi, janvier 23 2008

IE8 cassera encore plus le web

Mais quelle connerie !! Sous pretexte de ne pas vouloir casser les sites qui s'affichent bien dans IE6 et IE7, Microsoft va introduire dans IE8 l'utilisation d'une balise meta pour dire que la page respecte les standards, et donc que IE8 peut l'afficher selon les standards. Un truc dans le genre :

 <meta http-equiv="X-UA-Compatible" content="IE=8" />

Donc en clair, il n'y aura pas seulement 2 modes d'affichage, "quirks mode" (IE6 et -) et "standards mode" (IE7), mais un troisième mode "super standards".

Mais c'est vraiment n'importe quoi ! Et dans IE9, on aura quoi ? D'autant plus que cela pose une multitude de problèmes aux implémenteurs de IE (m'enfin ça c'est leur problème), mais surtout des problèmes incommensurables aux développeurs web ! Il va bientôt falloir faire une page pour chaque IE ??

Franchement, ils se foutent vraiment de la gueule du monde chez Microsoft.

Pour comprendre le pourquoi et le comment, lire par exemple ce billet, celui-là, celui-là, ou lisez aussi les 300 commentaires au billet de la team IE conçernant cette stupide "feature".

Mise à jour 24/01/2008: IE8 pourra switcher vers le mode standard avec le doctype HTML5, donc il n'y aura pas besoin de cette balise meta.

Premier brouillon de HTML5

Le W3C vient de publier le premier brouillon de la future spécification de HTML5. C'est le résultat d'un travail ardu au W3C, basé sur celui du WHATWG (qui est donc à l'origine de HTML5). Je vous propose une découverte succincte des nouveautés qui sont spécifiées dans ce brouillon.

Lire la suite...

dimanche, janvier 20 2008

IE6 n'aime pas les boutons

Pour faire des boutons, il y a une balise sympa en HTML : <button>. On peut s'en servir notamment pour les boutons d'envoi de formulaire :

 <button type="submit" name="validation" value="save">Enregistrer</button>

Comme vous le voyez, l'avantage par rapport à un <input type="submit">, c'est que l'on peut spécifier une valeur, que l'on recevra coté serveur. Et au niveau du libéllé, on peut en principe mettre n'importe quoi : du texte, d'autres balises HTML... C'est particulièrement sympa quand vous avez plusieurs boutons d'envoi :

 <button type="submit" name="validation" value="save">Enregistrer</button>
 <button type="submit" name="validation" value="prev">Prévisualiser</button>

Coté serveur, en PHP par exemple, on a juste à tester la variable $_POST['validation'] par rapport aux valeurs "save" et "prev", afin de savoir quoi faire.

J'avais donc choisi d'utiliser ces boutons dans jForms, le système de formulaire de Jelix. Et ça fonctionne parfaitement dans Firefox, Konqueror, IE7 et certainement Opera. Mais je viens de faire machine arrière, à cause de bugs dans IE6 que l'on m'a rapporté.

Le premier bug, c'est que IE6 n'envoie pas la valeur que l'on met dans l'attribut value, mais le contenu de la balise button. Elle a donc le même fonctionnement que input dans IE6. C'est un bug que j'ai pu contourner dans jForms. Mais IE6 n'avait pas fini de me donner du fil à retordre.

En effet, quand plusieurs boutons ont le même nom, il renvoi toujours le libellé du dernier bouton, quel que soit le bouton sur lequel on clique ! Je me suis alors dit, bon, je ne vais pas appeler les boutons avec le même nom, et je vais faire du bidouillage dans jforms pour que dans jelix, on ait les valeurs sous un même nom. Mais voilà, peine perdue : quand on clique sur un bouton submit, IE6 envoit non seulement le libellé de ce bouton, mais aussi les libellés de tout les autres boutons submit qui n'ont pas le même nom ! Il est comique IE6 n'est ce pas ?

Conclusion : la balise <button> est inutilisable à cause de IE6, car encore largement répandu. J'ai donc à regret mis des <input type="submit"> dans jForms :-(

jeudi, décembre 20 2007

IE8 passe le test acid2

Dean Hachamovitch, l'un des responsables du projet IE8, annonce sur le blog IE que IE8, encore en développement, passe le test Acid2. C'est une très bonne nouvelle pour les développeurs web, d'autant plus que Dean confirme que les standards sont plus que jamais leur objectif pour cette nouvelle version de IE.

Pas de panique pour les "vieux" sites : la compatibilité des sites web avec IE6/7 est maintenue. IE8 aura à priori deux moteurs de rendu, l'ancien (IE6/7) et le nouveau (qui respectera donc beaucoup mieux les standards), et il basculera sur l'un ou l'autre selon les pages (on ne sait pas encore quels seront les critères).

Une autre chose très intéressante, souligné par Daniel, c'est que la liste des fichiers qu'ils ont publiés (pas par hasard) nous livrent quelques informations :

  • Il y aura des améliorations sur d'autres parties de CSS. Par exemple on voit ce fichier : FSMULTICOLUMNLAYOUTDS.H.
  • Le "nouveau" moteur de rendu n'est pas si nouveau que ça, puisqu'il en est à sa version 5.0, si on en croit le nom du répertoire. Il se pourrait donc que ce soit un moteur de rendu déjà utilisé dans des produits Microsoft (autre que IE) ;-)

(Autre chose qui n'a pas grand chose à voir : on peut remarquer que le séparateur des noms de répertoires n'est pas un "anti-slash" (\) comme c'est le cas normalement dans les systèmes windows, mais un "slash" (/). On peut utiliser des slashs dans les dernières versions de windows ?)

dimanche, novembre 18 2007

Retour de Paris Web 2007

Ce paris web 2007 fut une nouvelle fois organisé de mains de maitres, avec des conférenciers de qualité venant du monde entier (Canada, États unis, Europe du nord, Suisse) ou de "grosses boites" (Opéra, Yahoo, IBM, W3C...).. Et puis ce fut l'occasion de retrouvailles avec tout ceux qui gravitent autour des standards du web. Beaucoup plus de monde que l'année dernière, avec des personnes inscrites ayant des profils très divers (responsable informatique, étudiant, chef de projet, "marketeux" etc..), signe que les choses bougent dans l'industrie du web.

Bref, j'ai vraiment apprécié. Félicitations aux organisateurs !

PS : Des photos de paris web sur flickr

mardi, octobre 30 2007

Paris web 2007, j'y serai !

Paris Web est une manifestation sur l'accessibilité, le design et la qualité des sites web. Et comme l'année dernière, il y aura des conférences sur toutes sortes de sujets, et ce sur 3 jours. La troisième journée (seulement 10 euros l'entrée !!!) est plus technique et j'y animerai un atelier sur XBL, qui est une fantastique technologie bientôt standardisée par le W3C, et dont la version 1 est implémentée dans Mozilla/Firefox depuis des années.

À noter aussi que Mozilla Europe soutient financièrement cette manifestation, et organise même un concours qui permettra à deux gagnants d'avoir une entrée gratuite à la conférence, ainsi qu'un T-Shirt.

Je vais peut-être profiter de ses trois jours sur Paris pour organiser un soir un "apéro Jelix", une rencontre informelle entre curieux/utilisateurs/contributeurs du framework Jelix. Ça pourrait être sympa non ? Ce qui est sûr, c'est qu'on sera au moins deux avec Loïc (un contributeur) :-)

jeudi, octobre 4 2007

Support de font-face dans Webkit et Opera

La nightly de Webkit, le moteur de rendu de Safari entre autre, supporte la rêgle CSS @@font-face@@. Ce qui veut dire que l'on peut indiquer dans sa feuille de style l'url d'une font à utiliser : le navigateur télécharge alors la fonte et l'utilise là où c'est indiqué.

 @font-face {
    font-family: "Kimberley";
    src: url(http://www.princexml.com/fonts/larabie/kimberle.ttf) format("truetype");
 }

 h1 { font-family: "Kimberley", sans-serif }

C'est une propriété CSS2 qui est beaucoup attendu par les webdesigners, et Webkit est le premier à l'implémenter complètement (IE 4 le permettait mais seulement pour des fontes dans un format propriétaire). Une prochaine version d'Opera proposera très certainement aussi cette propriété. Quant à Firefox, ce n'est pas à l'ordre du jour (voir le bug correspondant), et en tout cas la version 3 ne supportera pas font-face.

À lire sur le sujet : un article récent d'Håkon Wium Lie, l'inventeur de CSS et travaillant pour Opera. Pour Håkon, la prise en charge des fontes téléchargeables dans CSS devient nécessaire. Voir aussi une interview sur CSS3.info.

samedi, septembre 1 2007

CSS Refresh 2007

Le concours organisé par Alsacreations vient de se terminer. Esthétiquement, je trouve pas mal de designs réussis. Et quand je vois tout ces jolis sites, je me demande : mais p**in ?!? Comme font-ils pour avoir autant de créativité graphique ??

Le design est un truc avec lequel j'ai beaucoup de mal. Par exemple, ça fait plusieurs mois que j'essai de pondre un nouveau design pour mon blog, et je n'arrive toujours pas à faire un truc qui me satisfasse, qui soit original. Ou alors, quand j'arrive à trouver une idée graphique, comme pour le site jelix.org, c'est après des jours de réflexions. Et encore le résultat est potable mais sans plus.

M'enfin, chacun son métier comme on dit. Et bravo à tous les participants de ce concours.

mardi, avril 17 2007

La balise <video>

Le whatwg propose une nouvelle balise,<video> dans HTML5, pour incorporer facilement des vidéos dans une page html. Certains ne voient pas l'intérêt de cette balise, dans la mesure où la balise <object> (ou <embed>) rempli soit disant très bien ce rôle. Je ne suis pas d'accord avec eux, et voici pourquoi je trouve que cette balise <video> est une bonne chose. (Mise à jour : une version plus récente de cet article est disponible !)

Lire la suite...

samedi, mars 31 2007

W3C HTML Mail Workshop

À l'ENST, le 24 mai prochain, il y aura un séminaire sur le "HTML dans les mails", organisé par le W3C. Comment doit évoluer le HTML pour les mails ? Quels sont les soucis que rencontrent les usagers ? Ce séminaire est déstiné à tous le monde. Pour y participer, débattre, proposer des contributions, et avoir plus d'infos, voir le billet de Daniel à ce sujet.

Le HTML dans les mails est un sujet hautement trollesque, mais c'est peut être l'occasion d'en finir une bonne fois pour toute avec tout ces trolls, et l'occasion de trouver des solutions qui satisfassent tout le monde ;-)

vendredi, janvier 26 2007

Avançée de CSS3 dans les navigateurs

Les spécifications de CSS3, ne sont pas encore une recommandation du W3C. Seuls 5 sur les 34 modules ont passé le cap de "Candidate Recommendation".

Cela n'empêche pas les éditeurs de navigateurs de commencer à implémenter CSS3, surtout les spécifications les plus avancées et les plus intéressantes[1].

Firefox avait ouvert la voie il y a déjà pas mal de temps. Dans Firefox 1.5, on a eu droit à la prise en charge des colonnes ou des compteurs, ou même bien avant, on pouvait déjà utiliser certains des sélecteurs CSS3 et d'autres propriétés (Ils en avaient besoin pour XUL).

Mais force est de constater que Firefox perd de son avance en matière d'implémentation CSS3. Le moteur Webkit/Khtml par exemple progresse rapidement dans ce domaine. Voir en particulier les billets de David Hyatt sur le blog de webkit. Dans KDE 3.5.6, Konqueror (basé sur khtml), prend maintenant en charge tout les sélecteurs CSS3, et passe la suite de test sur les selecteurs, proposée par le site css3.info (dont je vous recommande la lecture). Pour comparaison, Konqueror 3.5.2 (que j'ai sur ma machine) a un résultat de 309/578, Firefox 2 : 357/578 et la version de développement actuelle de Firefox 3 : 369/578 (qui corrige plus de bugs qu'il n'ajoute de nouveaux sélecteurs).

On a bien ici chez DI, une implémentation complète des sélecteurs CSS3, réalisée par mon collègue Olivier. Mais elle n'est.. qu'en Javascript (jQuery n'a qu'a bien se tenir ah ! ah !).

PS : Il y a aussi la prochaine version d'Opéra qui contiendra pas mal de nouveautés CSS3.

Notes

[1] Pour rappel, les spécifications de CSS prévoit que l'on peut implémenter des propriétés de styles non standard, si on préfixe leur nom par un tiret suivit du nom de la firme, du moteur etc. Ce que font les développeurs des navigateurs pour implémenter les styles css3 qui ne sont encore pas bien spécifiés, afin d'éviter une confusion pour les développeurs web.

lundi, novembre 6 2006

État de HTML 5 et XHTML 2

Laurent a fait un excellent résumé de la situation sur HTML 5 / XHTML 2 : Le sens du canard.

Comme le dit Karl dans un commentaire, il y a certainement de la place pour les deux langages [1], tout comme il y en a à la fois pour XForms et pour Webforms2. Je pense qu'il est sain d'avoir la possibilité entre deux langages pour un même domaine d'application : l'un, simple et suffisant pour faire des choses simples, et l'autre, pour satisfaire les besoins les plus exigeants. Cela permet de ne pas avoir à utiliser une usine à gaz quand un simple four suffit (pour cuire un canard par exemple... :-) ).

Notes

[1] je n'ai pas encore vraiment regardé en détails XHTML2

- page 2 de 9 -