Chez Jérémie - Mot-clé - agacement

Arrétez de me casser les gonades avec border-radius

Jeremie — Mon, 03 Jan 2011 09:00:00 +0100

Ça faisait longtemps que je ne m’était pas énervé et pour bien commencer la nouvelle année, sachez le, j’en ai un peu marre. Marre de quoi me diriez-vous ? J’en ai marre de ces intégrateurs qui se gargarisent avec border-radius, marre de ces gens qui ne jurent que par box-shadow, marre de ces crétins qui réduisent CSS3 au module “Border & Background”. Border-radius, c’est l’arbre qui cachent la forêt. CSS 3 est d’une richesse incroyable et pour l’instant, les constructeurs de navigateurs n’implémentent que de toutes petites choses, le gros reste à venir (et si vous prenez 5 minutes pour aller survoler les specs, même pas les lire, juste les survoler, vous verrez qu’il y a du lourd).

Soyons clairs, aujourd’hui, les seuls gars que je prend au sérieux à propos de CSS 3, ce sont ceux qui me parlent des sélecteurs et des Media Queries CSS 3 car c’est là que se cache la vraie puissance actuelle de CSS 3 (et pour le future les transformations 2D et 3D, les différents systèmes de positionnements et de mise en page, la génération de contenu, etc. autant dire que ça va être la fête du slip le jour où on aura tout ça dans nos boites à outils). Si vous voulez vous la péter avec le module “Border & Background”, c’est possible. Mais dans ce cas, c’est du coté de border-image qu’il faut aller fouiner et surtout, surtout, arrêtez de vous extasier sur border-radius et box-shadow qui ne sont que de la poudre au yeux.

Voilà pour l’échauffement, passons à la mise à mort. Je vais vous détailler pourquoi border-radius et box-shadow ne sont que des résidus de cagoinces (si, si).

Le cas border-radius

Combien de fois ai-je entendu “Oui, mais tu comprends, pour les bords arrondis, border-radius, c’est mieux”. Mieux ? Mieux que quoi exactement ? Non parce que sans déconner, moi, intégrer des bords arrondis, ça fait plus de 10 ans que je le fait. Ok, ne soyons pas de mauvaise foi, border-radius permet de faire des bords arrondis “sans image” ni “sur-balisage HTML” ni “Javascript”. C’est donc bien une autre méthode, parfois plus légère, pour réaliser des bords arrondis simples. Mais je ne vois pas en quoi c’est “mieux” :

Pas d’image : Donc ça c’est un non-argument absolue. Que dites-vous ? Économiser des requêtes HTTP pour les performances ? Vous ne connaissez pas les DATA URL ? Qui sont implémentées par tous les navigateurs qui supportent border-radius et avec des équivalents pour les vieux IE ! Mmmh ? Réduire le poids des pages Web ? Non sans rire, vous en êtes à optimiser 500 octets d’image (le poids maximum d’une image correctement compressée pour faire l’équivalent de ce que permet border-radius) ! Vous êtes sur que vous n’avez pas autre chose à optimiser avant, comme la durée de vie du cache de vos ressources statiques par exemple ? Accessoirement, l’utilisation d’images pour gérer les bordures offre d’énormes avantages graphiques car elles permettent de créer des formes bien plus subtiles et complexes donc, allez plutôt trifouiller border-image et apprenez à faire des sprites CSS, hein.
Pas de sur-balisage HTML : Ceci est un argument presque recevable sauf que… Sauf que dans la vraie vie, ce n’est vraie que si vous cherchez à intégrer des boites qui s’élargissent à la fois en hauteur et en largeur et qui doivent s’afficher avec des coins transparents. Une fois sortie de ce cas de figure, somme toute assez rare, il y a 9 chances sur 10 (voir 9,9 si vous vous intéressez aux sélecteurs CSS 3) que votre code source soit suffisamment balisé pour vous permettre de rajouter des bords arrondis sans avoir à vous casser la tête sur le HTML (et je ne vous parle même pas d’utiliser des techniques un peu délicates comme les pseudo-éléments CSS).
Pas besoin de Javascript : Donc, là, vous ne le voyez pas, mais je suis sous mon bureau, ravagé par une crise de fou rire. Si vous avez tout lu jusque là, vous aurez sans doute deviné que je n’ai jamais utilisé une once de Javascript pour produire des bords arrondis. Mais même si c’était le cas… en toute honnêteté, c’était quand la dernière fois que vous avez créer un site qui n’embarque pas une bibliothèque Javascript à tout faire (jQuery, Prototype, YUI, etc.) ? Accessoirement, si vous avez pris de bonnes habitudes en terme de Javascript non-intrusif, ça ne devrait pas vous poser l’ombre d’un cas de conscience.

Alors, oui, border-radius, ça peut être plus simple et plus rapide… mais c’est aussi très limité dès que vous voulez essayer de produire des bordures un peu chiadées graphiquement parlant (genre avec un petit reflet de lumière ou avec un petit déséquilibre dans les formes… bref, si vous voulez un truc un peu moins raide). Et dans ce cas-là… mmmh… je crois qu’il y a un truc en CSS 3 qui s’appelle border-image.

box-shadow, ni fait, ni à faire

Ayant donc d’autorité décrété que border-radius c’était plutôt “bof”, je vais maintenant faire de même avec box-shadow.

Box-shadow est cette propriété qui, comme son nom l’indique, permet de créer des ombres portés et, comme son nom ne l’indique pas, des effets de halo, de lumière et même… de bordures ! Et oui ! En soit, c’est une propriété intéressante (en tout cas beaucoup plus que border-radius), dès qu’on cherche à la tordre pour en faire autre choses que ce qu’elle suggère. Malheureusement, elle souffres de quelques défauts que je qualifie assez volontiers de majeur :

Les ombres (ou lumières) générées sont carrées ou plus exactement, elles ont la forme exacte de la boite sur laquelle la propriété est appliquée (ce qui inclue l’usage de border-radius heureusement, mais pas la transparence des images, j’y reviens plus loin). Certes, elles peuvent être distendues ou contractées homothétiquement, mais pas déformées à l’envie. Donc, si vous souhaitez créer des effets graphiques un peu travaillés, du genre feuille-de-papier-qui-se-décolle-sur-un-coin, vous repassez par la case image (et vous ne touchez pas 20 000 Francs, votre client n’en ayant rien à foutre que vous galériez à produire l’effet qu’il attend… il fallait y penser avant).
Si vous ne mettez pas une couleur d’arrière plan à la boite qui génère l’ombre, celle-ci sera… troué ! Et oui, c’est la spec qui le dit : The shadow is drawn outside the border edge only: it is clipped inside the border-box of the element.. En clair, la partie de l’ombre qui est sous la boite correspondante n’est pas rendue et puis voilà, c’est tout… iiirk ! Vous pourriez m’objecter que ça peut être utile. Oui, c’est vrai, mais pas toujours et comme ce n’est pas paramétrable, c’est chiant.

Donc, de deux choses l’une : Soit vous atteigniez le niveau zéro du web design (et franchement, une boite à bord arrondi et/ou avec une ombre porté, oui, c’est le niveau zéro du web design ; le truc que tous les apprentis intégrateurs font le premier jour où ils découvrent les joies de CSS) et avez besoin de produire de simples ombres portées ou des effets de lueur interne sur une boite, dans ce cas, c’est ok, cette propriété est faite pour vous ; soit vous voulez réalisez des effets un peu plus complexes et vous allez vite vous rendre compte que ce n’est pas plus simple ou pire, que c’est carrément limité et vous allez alors soit vous rabattre vers l’utilisation d’images (là encore, border-image peut bien vous aider… oui, je sais, je suis un peu lourd là, mais il faut vraiment voir toute la souplesse graphique qu’offre cette propriété) soit, si vous êtes un peu plus aventureux, vous allez regarder du coté des filtres SVG (aventureux car pour l’instant, l’application de filtres SVG sur des éléments HTML ne fonctionne qu’avec Firefox 4… qui n’est pas encore sorti au moment ou je publie ce coup de gueule).

Je ne suis pas le seul à penser que box-shadow est une propriété mal finie. En effet, les développeurs de webkit ont implémenté une autre propriété d’ombre : -webkit-svg-shadow. Cette propriété ne fait actuellement l’objet d’aucune normalisation, mais elle est une tentative pour porter la souplesse des ombres SVG vers CSS sans avoir à subir toute la lourdeur des primitives de filtres SVG. L’idée étant d’avoir une propriété qui gère pleinement la transparence des boites HTML et des images pour créer des ombres qui ont des formes complexes. En effet, essayez d’appliquer box-shadow à une image transparente… l’ombre sera carré : fail ! (Ceci étant dit, les développeurs de Webkit ferait mieux de travailler sur l’implémentation de box-shadow. Essayez de créer une ombre interne sur une boite avec border-radius et vous comprendrez de quoi je parle).

Conclusion

Aaaah, je me sens mieux !

Vous l’aurez compris, en ce qui me concerne ces deux propriétés ne méritent pas l’attention qu’on leur porte. Certes, elles apportent des solutions élégantes à certains problèmes communs d’intégration mais sans non plus porter à elles seules la révolution qu’est CSS3. De fait, je ne les renie pas car elles ont leur utilité (et il m’arrive même de les utiliser, si, si !). Cependant, il existe moult autres propriétés CSS3 en cour d’implémentation qui sont infiniment plus utiles (mais aussi infiniment moins sexy). En particulier, je vous invite à regarder de près ce qui ce fait au sein du module CSS Basic UI avec en particulier les propriétés box-sizing et pointer-events qui sont assez discrètes mais super utiles au quotidien (non mais vraiment !) ainsi que toutes les pseudo-classes de ce module et du module CSS selecteur Level 3. Ah ! Et au fait, est-ce que je vous ai parlé de border-image ?

2 ou 3 petites choses qui m'agacent avec HTML 5

Jeremie — Wed, 08 Jul 2009 20:00:00 +0200

Avec la sortie de Firefox 3.5, Safari 4 et prochainement de Opera 10, mais aussi avec les prises de position de Google, actuellement HTML 5 a le vent en poupe. C'est plutôt une bonne chose car les apports de cette norme sont conséquents et véritablement nécessaires. Ceci dit, au-delà du buzz, je lit et j'entends certaines choses qui m'agacent et qui prouvent soit une méconnaissance de la norme en cour d'élaboration, soit un manque de discernement certain. Petite revue de détails... par ce que là, "j'en ai gros" !

HTML 5 n'est pas encore une norme

Ça parait idiot à dire, mais c'est vraie : à ce jour, HTML 5 n'est pas un standard. C'est tellement vraie et l'engouement autour de ce futur standard est tel que, suite aux annonces de Google du mois de mai dernier, le W3C lui même a crue bon de se fendre d'un communiqué pour le rappeler. Au delà de l'aspect formel que cela peut revêtir vis à vis du cycle de normalisation du W3C, HTML 5 n'est même pas un standard de fait. En effet, les navigateurs les plus actifs sur le sujets n'implémentent qu'une petite partie de la future norme et surtout, Microsoft ne prévoie rien de sérieux pour le moment en termes de support de ces fonctionnalités à brève échéance. Quelque soit l'avis que l'on puisse avoir sur les qualités ou défauts de Internet Explorer, il n'en reste pas moins le navigateur le plus utilisé au monde. En particulier sa version 6 qui reste calamiteusement significative et refuse de disparaitre tel un bernique accroché à son rocher !

Ainsi, même si je trouve que HTML 5 est une fabuleuse avancé, il n'en reste pas moins que pour l'instant, celui-ci est inexploitable dans un cadre de production industrielle. On peut expérimenter, se former, appréhender de nouveau concept ou explorer la simplification de concepts connus, mais en aucun cas, un site ne peut prétendre faire une utilisation industriel de ce format sans se fermer à une part significative de son audience... ce qui justifie en soit la position de YouTube par rapport à l'utilisation de la balise <video>... subtile transition vers mon point suivant.

La balise `<video>` n'est pas morte

Une annonce de Ian Hickson concernant l'abandon d'une tentative de normalisation des codecs vidéo utiles à HTML 5 fait actuellement couler beaucoup d'ancre. L'interprétation complétement fantaisiste de cette information ayant parfois pour conséquence d'affirmer que la balise <video> a été purement et simplement retiré de la future norme (à cet égard, le Monde Informatique a fait preuve d'un scandaleux laissé aller journalistique) ! Les moins agressifs sur le sujet, se contente juste d'affirmer que cette balise est morte née et sera inexploitable.

En soit, la balise <video> fait toujours partie de la future norme HTML 5. Ce qui est abandonné, c'est la partie liée aux codecs. Qu'est ce que ça veut dire exactement ? Tout simplement qu'il n'y aura pas de format de vidéo standard sur le Web, exactement de la même façon qu'il n'y a pas de formats standards (comprendre : normalisés par le W3C dans HTML) pour les images. D'aucun de dire que cela signe le glas de la vidéo ouverte sur Internet.

Certes cela peut avoir des conséquences sur la vitesse d'adoption de cette partie de la norme par les constructeurs de navigateurs, mais surtout par les éditeurs de vidéo en ligne. Néanmoins, aujourd'hui, ce qui freine vraiment l'adoption de la balise <video> pour la diffusion de vidéo sur Internet, ce n'est pas un problème de codec, mais bien le fait que Microsoft refuse actuellement de l'implémenter dans Internet Explorer. En effet, aujourd'hui, il y a deux codecs en lice (Theora et H.264), mais les mécanismes de la balise <video> sont suffisamment bien pensés pour qu'il soit possible, grâce à la balise <source> de proposer plusieurs versions d'une même vidéo, les navigateurs n'ayant qu'à faire leur marché dans la liste proposée. Cela représente un petit travail supplémentaire pour les éditeurs de vidéo, mais qui est facilement automatisable dans la chaine de production à cout maitrisable. Mais ce ne sera acceptable par les éditeurs que si la balise <video> est largement supportée afin que le bénéfice de l'utilisation de cette balise soit supérieur au cout induit par du multi-encodage. Ainsi, de mon point de vu, la question des codec n'est pas la plus importante. Ce qui est vraiment bloquant, c'est l'attitude de Microsoft vis à vis de HTML 5.

Qu'est-ce que c'est que cette histoire de "microdata" ?

Alors oui, je trouve que le travail fait autour de HTML 5 est formidable. Oui, cette norme va apporter un lot non négligeable de nouveautés qui vont simplifier la vie des webdesigners. Mais de temps en temps, dans le processus de normalisation, on voit passer des OVNI et on se demande ce qui a traversé l'esprit du groupe de travail. C'est typiquement le cas de ce truc que sont les "microdata". En soit l'initiative est louable : permettre de rajouter des informations supplémentaires à l'usage des machines. Mais est-ce vraiment nécessaire d'avoir un nième langage de sémantisation du Web ? Après tout, le W3C a déjà normaliser RDF et sa déclinaison pour XHTML : RDFa. En outre, les microformats offrent déjà une solution pratique à des problèmes quotidiens de sémantisation particuliers. Alors POURQUOI devrait-il être nécessaire d'en remettre une couche avec une troisième façon de faire ? Est-ce qu'on pensent parfois aux éditeurs de sites Web ? ENCORE une nouvelle technique à apprendre et en plus qui est redondante avec quelque chose déjà existant. En l'état, je sens que ce truc risque de faire long feu pour rien. C'est dommage. Néanmoins, si quelqu'un peu m'éclairer sur les raisons profondes de ce choix, ce sera avec plaisir.

Conclusion

Voila, pour mon petit coup de gueule du jour... il y a encore beaucoup à faire et il y a beaucoup d'attente autour de HTML 5. Si seulement, tout le monde pouvait garder un peu la tête froide, ça avancerai sans doute beaucoup plus rapidement. La norme se développe et à besoin de murir. Inutile de crier au loup pour un oui ou pour un non. De toute façon, aujourd'hui, c'est malheureusement Microsoft qui joue les arbitres dans l'adoption de HTML 5. Malgré un net recule de la part de marché de Internet Explorer, Microsoft reste dans une position ou il peut faire obstruction à l'émergence d'une norme commune. Ceci dit il ne peut pas la bloquer totalement, ni imposer un standard de fait (on voit bien les difficulté que rencontre SilverLight à émerger sur le marché). Microsoft est seulement dans une position où il peut fortement ralentir l'évolution du web ouvert et standard (J'en voie qui ricane au fond là !). C'est en cela que l'adoption à grande échelle de HTML 5 sera longue et douloureuse.

Chez Jérémie - Mot-clé - agacement

Arrétez de me casser les gonades avec border-radius

Le cas border-radius

box-shadow, ni fait, ni à faire

Conclusion

2 ou 3 petites choses qui m'agacent avec HTML 5

HTML 5 n'est pas encore une norme

La balise <video> n'est pas morte

Qu'est-ce que c'est que cette histoire de "microdata" ?

Conclusion

La balise `<video>` n'est pas morte