Ingénieuse utilisation des Media Queries pour piloter JavaScript selon certaines conditions.
Le vendredi 15 juin prochain, j’aurai l’honneur de participer à la 4è édition du Web Event Lyon, au centre des congrès de Lyon.
J’y présenterai un thème qui me tient à cœur, en rapport avec les CSS, forcément.
Voici le contenu de cette présentation :
Parce qu’un jour CSS nous promet de ne plus avoir à nous torturer avec des bidouilles de positionnement, des bugs d’affichage, des hacks, des flottants mal employés, des position: absolute tordues, des position: relative ou des clear: both sortis de nulle part, du centrage vertical intuitif, toussa.
Un jour vous pourrez dire : j’y étais, c’était le bon vieux temps.
Mais pas encore.
On y parlera de diverses spécifications (en plein brouillon ou non) telles que : inline-block, CSS table, multicolonnes, flexbox, grid layout, float : position, regions, exclusions, CSS4, etc.
J’ai hâte d’y être ;)
J’ai envie aujourd’hui de revenir sur une idée reçue de longue date : le mélange du positionnement flottant (float) et de la propriété display.
C’est parfaitement inutile.
Tout simplement parce que les deux schémas de positionnement ne peuvent pas cohabiter : un seul sera interprété, le flottant.
Pourtant, bon nombre de feuilles de styles cumulent les deux propriétés sur le même élément, sous prétexte de pouvoir lui attribuer une largeur width ou une hauteur height.
Eh ben non, c’est inutile.
La seule exception acceptable est celle d’employer display: inline pour corriger un bug identifié sur IE6 sous le nom de double-float margin bug.
Non.
Float n’a aucune influence sur la valeur de display d’un élément. Pour preuve, un élément qui sort du flux de quelque manière que ce soit (float, position: absolute ou fixed) occupe par défaut la largeur de son contenu et non la largeur de son parent. Donc pas du tout le comportement d’un bloc.
Par contre, un élément qui sort du flux bénéficie d’un avantage commun aux display block : celui de pouvoir supporter les propriétés de dimensionnement (largeur, hauteur).
Les spécifications W3C admettent l’éventualité de cumuler différents schémas de positionnement.
Voici exactement comment cela se passe pour éviter les règles contradictoires :
En résumé : si les propriétés float et display apparaissent au sein du même bloc de déclarations, alors display (à l’exception de display none) doit être purement et simplement ignorée par les navigateurs. Elle devient inutile.
De même, si position absolute, float et display cohabitent, ces deux dernières doivent être ignorées par les navigateurs.
Pour élargir le débat, je vous invite à consulter cet article dédié au positionnement flottant : http://www.alsacreations.com/article/lire/972-float-le-grand-bluff.html
WebKit est un moteur de rendu libre et ouvert initialement lancé par Apple en 2003 et composé actuellement de nombreux développeurs de Google. Adobe participe aussi activement à Webkit car c’est le moteur de rendu utilisé dans toute leur suite.
Il est le cœur de très nombreux navigateurs de bureau (Chrome, Safari, Konqueror) mais aussi sur mobile (Safari mobile, Android, etc.).
En quelques années, il s’est imposé comme un acteur majeur du Web.
Plus important encore : Webkit va plus vite, plus haut et plus fort que les autres. Et ça excite les webdesigners.
Les composants de CSS3 étant pour la plupart en cours d’élaboration à des stades divers, le souci de l’implémentation dans les navigateurs web devient problématique. En effet, si chaque module est susceptible d’évoluer, voire de changer, dans les mois ou années à venir, il est totalement contre-productif pour un navigateur de tenter d’adapter au jour le jour son traitement de toutes les propriétés fluctuantes.
Que faire alors ? Patienter jusqu’à l’aboutissement de chacun des modules ou modifier ses algorithmes à chaque modification des spécifications d’une propriété ?
Le Consortium W3C propose depuis CSS 2.1 une alternative qui a le mérite de ne pas bloquer l’évolution des agents utilisateurs : à partir des informations dispensées dans les spécifications, chaque navigateur a carte blanche pour construire ses propriétés personnelles dérivées en les faisant précéder d’un préfixe vendeur propriétaire. Lorsque la spécification atteint le stade de Recommandation Candidate (CR), le préfixe doit être supprimé.
Ainsi, Mozilla Firefox a pu développer sa propre variante -moz-border-radius pour permettre d’utiliser la célèbre propriété border-radius (définissant l’arrondi des coins d’un bloc), très récemment finalisée dans la norme CSS 3. L’avantage est que l’un et l’autre isotope de la propriété ont leur propre vie et peuvent être développés indépendamment, voire se distinguer… jusqu’au jour de la reconnaissance officielle de border-radius par le W3C, auquel cas sa copie propriétaire n’a plus de raison d’exister.
Les spécifications recensent une douzaine de préfixes propriétaires (appelés aussi préfixes vendeurs) dont les plus fréquemment rencontrés sont attribués aux navigateurs web principaux, à savoir :
Cette convention évite les collisions de noms entre les fonctions standards et propriétaires, sans entraver les progrès des constructeurs de navigateurs. Toutefois, dans la pratique, cela contraint les auteurs à multiplier les écritures de déclarations de propriétés pour parvenir à un accord sur tous les navigateurs.
Nous parvenons enfin au cœur du feuilleton : Opera a annoncé aujourd’hui qu’il allait implémenter très prochainement le préfixe -webkit- initialement “réservé” au moteur de rendu du même nom (sur son navigateur Opera Mobile dans un premier temps, puis sur l’ensemble de ses services).
L’explication est simple : WebKit est devenu l’unique référence pour de nombreux concepteurs web, qui ne prennent plus la peine d’ajouter les préfixes des autres navigateurs.
Pire, ils se contentent parfois de cette seule syntaxe, en occultant la syntaxe officielle finalisée sans préfixe.
L’expérience utilisateur s’en voit bien entendu dégradée sur un grand nombre de navigateurs, qui pourtant sont capables de reconnaître ces fonctionnalités CSS3.
Même dans le marché grandissant du Web mobile, où Opera est très représenté en terme d’usage,… tout le monde développe spécifiquement pour Android ou iOS, et le préfixe -webkit- est roi incontesté.
Opera a donc opté pour une solution radicale : supporter les propriétés préfixées par -webkit-. Cette décision a bien entendu levé un vent de panique dans notre microcosme.
Dans la pratique, Opera ne va pas implémenter les propriétés en triple exemplaire (-webkit-, -o- et sans préfixes) : seules certaines propriétés préfixées seront reconnues, et considérées exactement comme s’il s’agissaient de propriétés préfixées par -o- (un peu comme un alias).
En outre, cela ne concernera évidemment que les fonctionnalités déjà supportées par Opera.
En fait le principe est assez simple, le voici illustré par un exemple fictif :
Malheureusement, très (trop) peu de webdesigners se contraignent à ajouter tous les préfixes et se contentent souvent de -webkit-.
Au final, il n’y aura pas de transitions sur Opera, bien que ce navigateur les supporte très bien.
La solution de repli d’Opera est d’interpréter les préfixes -webkit- et de les appliquer quand-même à condition qu’il reconnaisse la propriété concernée. Du coup, les transitions fonctionneront sur Opera… même en se contentant d’un -webkit-transition.
Pour bien se rendre compte que le phénomène est loin d’être anodin, une réunion de discussion autour de ce thème est prévue prochainement.
Il y sera question de l’adoption du préfixe -webkit- par Mozilla Firefox ainsi que d’Internet Explorer, qui semblent très sérieusement envisager cette éventualité.
Pas mal de choses.
Pour commencer, c’est un aveu de plusieurs dysfonctionnements (notamment du W3C et de sa lenteur), et aveu de faiblesse devant l’ogre WebKit : soit on s’allie, soit on meurt.
Sinon, plus prosaïquement :
Bref, la nouvelle guerre des navigateurs commence maintenant, attachez vos ceintures !
(source de l’illustration : http://gohelrakesh.wordpress.com/)
Charte d'intégration HTML / CSS de Google -
Important : il s’agit bien d’une convention interne à Google, pas de bonnes pratiques universelles. N’appliquez pas toutes les recommandations à la lettre, car elles ne vous concernent pas forcément toutes.
Bref, Darklg a intégré un site -
Suite à la publication de l’article intitulé “Bref, j’ai intégré un site”, plusieurs intégrateurs se sont manifestés pour partager leur méthodologie d’intégration.
Darklg a décidé d’en faire un billet complet pour y détailler toutes les étapes qui composent son travail d’intégration. Merci beaucoup à lui pour ce partage autour de son process d’artisanat 2.0.