Une histoire de Grid Layout, de Microsoft et de @supports

En résumé : la spécification CSS Grid Layout, révolutionnaire, est aujourd’hui implémentée dans la plupart des navigateurs… Mais pas tous. Quelle méthodologie adopter pour les retardataires ?

Le support de Grid Layout est de plus en plus décent (proche de 80% en France à l’heure de cet article) . Mais c’est sans compter sur ce galopin d’Internet Explorer, toujours là pour nous régaler de ses fourberies.

Voici d’ailleurs où en est l’implémentation de Grid par les différentes version d’Internet Explorer:

  • IE9 et inférieur : pas de support
  • IE10, IE11, Edge 15 et inférieur : ancienne spécification
  • Edge 16+ : nouvelle spécification  😍

À ce titre, l’experte mondiale Rachel Andrew a rédigé un article détaillant l’implémentation de Grid Layout sur IE, je vous le conseille.

Un support partiel

Commençons par une excellente nouvelle : Microsoft Edge 16 reconnaît la dernière version de la spécification Grid, dans son intégralité.
Par contre, pour les anciennes moutures d’Internet Explorer c’est un peu plus compliqué: IE10, IE11 et Edge 15 supportent officiellement Grid Layout mais se réfèrent à une antique version de la spécification qui est bien moins complète, et de nombreuses fonctionnalités y sont donc manquantes.

Parmi les lacunes principales de ces navigateurs, on dénombre le manque de support crucial de :

  • gap / grid-gap pour réaliser les gouttières
  • grid-area pour nommer des zones nommées
  • repeat(), minmax(), auto-fit et auto-fill
  • quelques syntaxes courantes actuelles.

Quels outils à notre disposition ?

De manière schématique, nous disposons de trois solutions pour gérer les lacunes de navigateurs : Autoprefixer, les mixins de préprocesseurs CSS et la règle CSS @supports.

Autoprefixer

Le célébrissime Autoprefixer est un superbe outil permettant d’ajouter tous les préfixes CSS vendeurs à vos propriétés de manière automatisée et, surtout, uniquement pour les navigateurs le nécessitant encore.

Par contre, figurez-vous que Grid Layout n’est pas activé sur Autoprefixer par défaut. Il faut l’activer dans les options en passant « grid: false » à « grid: true« . Voilà qui semble aberrant, non ?

Bah finalement pas tant que ça en fait. Une interpellation d’Anthony Ricaud m’a bien fait méditer sur le sujet, et je crois qu’il a entièrement raison au final (la discussion twitter complète en vaut la peine) :

Sass mixins

Autre possibilité : profiter des préprocesseurs CSS (Sass, LESS, Stylus) pour générer automatiquement les préfixes et propriétés équivalentes à Grid Layout.

Un article détaillé sur les possibilités de mixins a été publié sur CSS-Tricks récemment. Personnellement, je trouve un peu dommage d’utiliser ce genre de « hacks » en règle générale, mais dans le cas présent cela peut se révéler bien utile.

@supports ()

La règle @supports, également nommée “règle conditionnelle”, permet de détecter la reconnaissance de certaines propriétés CSS au sein du navigateur.

Introduite au sein des spécifications dans le module des CSS conditionnelles, au même titre que les Media Queries, la règle @supports se rapproche de ce que peut nous offrir un outil tel que Modernizr, à savoir détecter le support ou non d’une fonctionnalité CSS chez votre visiteur afin de prévoir une alternative au besoin.

Voici un exemple de règle conditionnelle valide :

@supports (hyphens: auto) {
  p {
    hyphens: auto;
  }
}

@supports est reconnue depuis à partir de Microsoft Edge, il est donc totalement ignoré par IE11 et inférieurs.

@supports et l’amélioration progressive

 

La règle @supports est notre meilleure alliée pour concevoir une intégration adaptée à tous les navigateurs selon le processus d’Amélioration Progressive.

La méthode de l’amélioration progressive

Avec la diversité actuelle des visiteurs, des usages, des navigateurs et des devices, il nous paraît absolument nécessaire de nous adapter.
L’heure n’est plus à tenter d’obtenir un affichage identique sur chaque device, bien au contraire, car un gabarit de 4 colonnes ne serait pas harmonieux sur un écran de smartphone.
Il en est de même pour les navigateurs : il devient aberrant de souhaiter un affichage identique sur un obsolète IE10 et sur un Edge flambant neuf par exemple.

Si le Responsive Webdesign est l’art de s’adapter à tous les devices; l’Amélioration Progressive est celui de s’accommoder aux évolutions des navigateurs.
Cette double compétence est aujourd’hui devenue absolument essentielle.

Appliquée à Grid Layout, l’amélioration progressive nécessite un minimum de deux étapes :

  1. Prévoir une alternative (fallback) en Flexbox (ou autre mode de positionnement) avec fonctionnalités de base
  2. Appliquer Grid Layout uniquement pour tous les agents utilisateurs qui le comprennent correctement

Sur le principe, c’est aussi bête que ça.

En pratique, le plus compliqué est de savoir faire le tri entre les bons et les mauvais chasseurs navigateurs.

Le Fallback ne doit concerner que les mauvais élèves dont IE10, IE11 et quelques navigateurs plus exotiques encore (UC browser, Opera Mini, anciens Firefox). Pour eux, la page s’affichera grâce à Flexbox et se contentera d’un affichage sommaire mais amplement suffisant.

Microsoft Edge, quant à lui, gère très bien Grid Layout… mais uniquement à partir de son 16è opus.

Il faudra donc trouver une combinaison de règle @supports permettant d’exclure uniquement les navigateurs non compatibles ou ayant implémenté l’ancienne spécification.

1- Gérer les Fallbacks

De nombreuses possibilités d’alternatives existent, je ne vais pas entrer dans les détails ici, mais je vous invite à lire attentivement cet article de Rachel Andrew pour mieux cerner les différentes options.

2- Gérer l’amélioration avec @supports

Appliquer @supports est un jeu d’enfant. Par contre, nous allons devoir traiter une subtilité digne de Microsoft, à savoir que… Edge supporte à la fois display: grid ET display: -ms-grid.

Les différentes syntaxe sont donc :

  • @supports (…) –> écarte IE11 et inférieur
  • @supports (display: -ms-grid) –> cible Edge uniquement
  • @supports (display: grid) –> cible Edge ainsi que tous les autres navigateurs modernes
  • @supports (display: grid) and (not (display: -ms-grid)) –> cible tous les navigateurs modernes sauf Edge

Si nous partons du principe qu’aujourd’hui nous pouvons offrir Grid Layout à tous les navigateurs modernes, Edge inclus, la solution à retenir devra être :

@supports (display: grid) {
  /* will return true for any browser supporting the spec, Edge included */
}

Cette syntaxe de @supports nous permet de ne conserver que les navigateurs vraiment compatibles tout en étant certain d’exclure IE10 et IE11 qui ne reconnaissent que la version préfixée.

Seule faiblesse de cette formule : les anciennes versions de Edge (inférieur ou égale à 15) répondront positivement au test bien que leur support de Grid soit défaillant lui aussi. Gageons que les mises à jour automatiques de Microsoft corrigent d’elles même cette lacune !

EDIT : on affine le test !

Merci à Philippe Vayssière d’avoir mis le doigt sur une particularité intéressante de Edge 16 : son support des propriétés object-fit et position: sticky.

Il est donc possible d’affiner notre test en excluant toutes les anciennes versions déficientes de Edge <16 ainsi :

@supports (display: grid) and (object-fit: cover) {
/* will return true for any browser supporting the spec, excluding Edge <16  */
}

Une autre possibilité est de ne pas tester display: grid, mais une propriété plus récente, par exemple grid-area, qui ne sera forcément vérifiée que par les navigateurs ne reconnaissant que la dernière spécification, astuce postée sur Smashing Magazine :

@supports (grid-area: auto) {
/* will return true for any browser supporting the spec, excluding Edge <16  */
}

Cette dernière solution est parfaite !

Vous pouvez tester ce snippet sur votre navigateur grâce à cette démo CodePen.

Conclusion et exemple final

Voici pour finir comment nous pourrions gérer cette situation :

Fallback en flexbox ou autre, pensez à utiliser Autoprefixer tout de même) :

.container {
  display: flex;
}

Détection du support et activation au-delà d’un seuil minimal de taille :

@supports (grid-area: auto) {
  @media (min-width: 576px) {
    .container {
      display: grid;
    }
  }
}

Et voilà, c’était aussi simple que ça ! 🙂

Capture d_écran 2017-08-26 à 14.05.49

8 réflexions au sujet de « Une histoire de Grid Layout, de Microsoft et de @supports »

  1. Je ne comprends pas le commentaire sur @supports(display: grid). J’ai testé sur Edge 14 et 15 et ces deux navigateurs disent bien qu’ils ne supportent pas cette déclaration. Du coup, seul les navigateurs supportant la spec 2017 de Grid verront les déclarations à l’intérieur de @supports(display: grid). Est-ce qu’il y a un détail que j’ai manqué ?

    1. C’est curieux en effet.
      D’après l’auteur sur Smashing Magazine (et ce n’est pas la première fois que je lis cela) : « The challenge is Microsoft Edge, the only modern browser that, as of this writing, still uses the old grid specification. It returns true for @supports (display: grid) {}, even though its grid support is spotty and non-standard. »

      Peut-être y aurait-il des différences entre Edge 12-13, et les versions que tu as testées ? (même si cela serait fort étonnant). Sans quoi je ne sais pas non plus :/

    2. Mon test avec Edge 15.15063 (Edge 40.truc sur un Win 10 Pro x64) dit qu’il supporte @supports, display: grid et -ms-grid (mais pas object-fit ou grid-area)

          1. Ce test n’est pas bon. Quand j’inspecte le CSS qui matche pour afficher « je reconnais @supports(display: grid) », je tombe sur @supports ((display: -ms-grid) or (display: grid)) {. En fait, c’est Autoprefixer qui fait quelque chose de bizarre. Quand je désactive Autoprefixer, tout ça marche comme attendu.

            1. Bigre, je crois bien que tu as raison. Je viens de désactiver Autoprefixer et Microsoft Edge 15 me répond qu’il ne supporte pas « display: grid ».
              Il semblerait que tous les articles indiquant le contraire proviendraient de tests réalisés avec Autoprefixer activé.
              En résumé : Edge 15 ne reconnaît pas « @supports (display: grid) »… sauf si Autoprefixer est activé… ce qui est d’autant plus bizarre que la configuration par défaut de Autoprefixer est « grid: false; » ! (et pire, pour avoir vu le code CSS compilé, Autoprefixer ne change rien du tout).

              J’aurais tendance à conclure que puisque Autoprefixer est très fréquemment utilisé et pour être sûr de son coup, il vaut peut-être mieux miser quand-même sur « @supports (grid-area: auto).

  2. En fait, Codepen active le support de grid dans Autoprefixer, ce qui explique le comportement. Donc avec une config par défaut de Autoprefixer, Edge se comporte comme attendu. Ce n’est que avec Autoprefixer et grid: true que l’on rencontre des soucis.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s