CSSWG Minutes Telecon (2024-12-04): Utilisez simplement la grille vs affichage: maçonnerie

Le groupe de travail CSS (CSSWG) organise des réunions régulières pour résoudre les problèmes de GitHub, empêchant souvent de longs débats de forum. Une réunion particulièrement significative s'est produite le 4 décembre 2024, en se concentrant sur une discussion de cinq ans: La maçonnerie devrait-elle être intégrée dans la grille ou rester un système de mise en page distinct?

Pour une compréhension complète de l'histoire du débat, consultez la grille CSS Masonry & CSS par Geoff et choisissant une syntaxe de maçonnerie dans CSS par Miriam Suzanne.

La question de base, après des années de discussion et d'obstacles techniques désormais résolus, se résume à Syntaxe : Quelle approche est plus facile pour les développeurs d'apprendre et comment cela aura un impact sur le développement futur CSS?

Le groupe d'architecture technique W3C (TAG) a fourni des commentaires, ce qui a provoqué une tentative de concilier deux propositions concurrentes d'Apple et de Google. Les deux parties ont présenté leurs arguments lors de la réunion, visant un consensus. (Les procès-verbaux de la réunion sont disponibles sur w3c.org)

Propositions concurrentes: présentations PowerPoint

Alison Maher (Microsoft), plaidant pour la maçonnerie en tant que nouvelle valeur display, a mis en évidence ces points:

1. Des différences comportementales significatives existent entre la maçonnerie et la grille.
2. display: masonry offre des paramètres par défaut supérieurs (un point récemment souligné par Rachel Andrew).
3. Les préoccupations concernant les longues secours pour display: masonry ont été rejetées; Maher a fait valoir que se concentrer sur le futur est primordial et que les bases explicites devraient être implémentées par les auteurs.
4. Le positionnement de la maçonnerie est plus simple (un axe par rapport aux deux de la grille).
5. Les raccourcis de maçonnerie sont plus conviviaux que les raccourcis complexes de Grid.
6. Le placement et l'alignement diffèrent considérablement entre la maçonnerie et la grille.
7. Les développements futurs en sous-masonrie / sous-grille divergent davantage.
8. L'intégration de la maçonnerie dans la grille entraînera des spécifications gonflées, une complexité d'apprentissage accrue et une confusion des développeurs.

Conclusion (maher): La maçonnerie doit être un type d'affichage séparé.

Jen Simmons (webkit), défendant l'approche "Utiliser la grille", contrée avec:

1. Un nouveau type de mise en page introduit une syntaxe séparée, similaire mais distinct, potentiellement déroutant les développeurs familiers avec la grille.
2. La proposition de chrome introduit environ 10 nouvelles propriétés, jugées inutiles.
3. La syntaxe améliorée de la proposition chromée a été contestée; grid-auto-flow fournit une solution suffisante.
4. Les différences de syntaxe de mise en page des lignes ont été mises en évidence.
5. Les écarts dans le comportement auto-flow ont été notés.
6. Les valeurs par défaut de maçonnerie proposées ont été critiquées comme inefficaces.
7. La commutation entre la grille et la maçonnerie (par exemple, aux points d'arrêt) est plus simple avec une approche unifiée.
8. La réutilisation des fonctionnalités existantes de la grille s'aligne sur les principes de conception CSS.

Entrée de balise

Lea verou (balise) a offert la perspective de la balise:

La balise a trouvé les arguments de WebKit convaincants. Ils ont suggéré non seulement l'intégration de la maçonnerie dans la grille, mais aussi la simplification de la grille elle-même. Tout en reconnaissant la complexité de certaines caractéristiques de la grille, ils ont souligné la nécessité de solutions plus simples. Ils ont mis en évidence le potentiel de défaut plus intelligents et les avantages d'une approche unifiée pour réduire la courbe d'apprentissage. La balise a également souligné que de nombreux cas d'utilisation de maçonnerie bénéficient de grilles plus simples, souvent 1D,

Le débat se poursuit

La discussion ultérieure a impliqué divers points de vue:

• Les préoccupations ont été soulevées concernant la cohérence des propriétés proposées.
• Certains membres ont changé leur position en fonction des arguments de la balise.
• Des contre-arguments forts ont été présentés contre les recommandations de l'étiquette, citant les conflits potentiels et les complexités résultant de la combinaison de modèles de disposition distincts.
• L'étiquette a clarifié leur position, mettant l'accent sur le continuum des approches de mise en page et la nécessité d'une syntaxe flexible.
• Une focalisation a émergé sur les propriétés du partage, même si display les valeurs différaient.

Le résultat: une impasse

Malgré une discussion approfondie, un consensus est resté insaisissable. Un sondage de paille a révélé une décision divisée. La réunion s'est terminée sans une voie claire.

Ce débat prolongé souligne l'importance d'une solution bien considérée. Une nouvelle proposition répondant aux préoccupations des deux parties est probablement nécessaire. L'avenir de la maçonnerie dans CSS reste incertain, mais son importance pour les futurs systèmes de disposition est indéniable.

Ressources supplémentaires

L'article comprend des liens vers la lecture plus approfondie et les problèmes de github pertinents.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!