2026 Acceptation livraison front-end sur Mac distant :
Container queries CSS et @layer — matrice Safari / Chromium + porte en trois étapes
Public : équipes qui livrent composants et sites depuis un Mac distant et utilisent container queries + @layer (Tailwind, tokens, widgets). Ce billet est une lentille d’acceptation livraison, pas un cours de syntaxe. Contexte matériel : accueil ; liste : blog ; thématique Web : smoke Web pré-déploiement. Croisez avec Vite/Webpack + Safari et Playwright WebKit.
01 Pourquoi les container queries et les couches conditionnent la livraison
Les container queries déplacent les ruptures du viewport vers les boîtes de composants — utile pour dashboards et embeds, mais cela multiplie les états à valider (imbrication, overflow, size vs inline-size). @layer est spécifié de façon cohérente en 2026 ; en prod, les casses viennent surtout du code splitting et du CSS fournisseur non couché, qui bat toujours les couches.
Sur Mac loué, gardez une seule vérité : playwright-webkit et CI Chromium ne remplacent pas Safari.app pour les layouts à containment. Figez moteurs, comparez les deux familles, tracez les exceptions.
02 Matrice comparée — focus acceptation
Focus acceptation (pas la spec complète). Baseline : Safari + Chromium evergreen internes ; adaptez si vous ciblez de vieilles WebViews.
| Sujet | Chromium (Chrome / Edge) | Safari (WebKit) |
|---|---|---|
Unités de requête conteneur (cqw, cqh, cqi, cqb, cqmin, cqmax) |
Stable ; DevTools montrent le conteneur actif. Évitez de mélanger cq* et vw/vh sans règle d’équipe. |
OK sur Safari récent ; testez l’imbrication avec overflow: auto (scrollport + containment). |
container-type: size vs inline-size |
DevTools utiles sur l’axe de bloc ; piège : hauteur oubliée avec size. |
Même spec ; redimensionnez aussi la hauteur des cartes, pas seulement la fenêtre. |
Cascade @layer et règles non couchées |
Panneau Layers pratique ; imports dynamiques peuvent réordonner les déclarations. | Cascade conforme ; écarts = ordre bundle / couches dupliquées post-minify — lisez le computed. |
@import + couches |
Waterfall DevTools ; imports tardifs visibles. | Pareil ; méfiez-vous du critical CSS inline sans @layer → gagnants non couchés. |
| Shadow DOM / feuilles constructibles | Container queries dans shadow : règles d’hôte connues. | Testez un web component shadow + couches page. |
| Signal d’automatisation | Headless Chromium : rapide, pas la vérité WebKit. | RC : Safari sur Mac distant ; Vitest vs WebKit si tests DOM. |
03 Checklist en trois étapes avant la mise en ligne
- Geler les moteurs. Versions min. Safari + Chromium (image Mac distant + devices). Assertion CI (UA,
userAgentDatasi dispo, tag d’image) pour éviter un pool obsolète. - Templates réels. Redimensionnez sidebars / dashboards / mobile pour chaque
@container. Sur conflits@layer, comparez le computed des deux moteurs (boutons, modales, embeds). - Preuve WebKit. Une capture ou courte vidéo Safari sur Mac distant dans le ticket — artefact humain pour bissecter si Chromium est vert.
Enchaînez avec smoke Web pré-déploiement pour ranger CSS, API et Lighthouse dans le même dossier d’artefacts.
04 Suggestions de données structurées (SEO / GEO)
Déjà inclus ici : BlogPosting, BreadcrumbList, HowTo, FAQPage. À envisager selon hub : TechArticle ou Article + about. Validez via Rich Results Test ; évitez les FAQ dupliquées sur plusieurs URL.
05 FAQ
Safari et Chromium implémentent-ils les container queries de la même façon ?
Même norme @container. En prod, l’écart vient du contexte layout (flex, overflow, hauteurs), pas du parseur sur des min-width simples.
Pourquoi @layer est correct dans Chrome mais pas dans Safari ?
Souvent : règles non couchées, couches dupliquées entre chunks, tiers sans @layer. Comparez le computed nœud par nœud.
Le Safari Mac distant suffit-il si nous exécutons déjà Playwright WebKit ?
Playwright = volume ; Safari utilisateur = GPU, polices, extensions off. Gardez les deux : bots + Safari Mac distant sur RC.
06 Synthèse
Interop moderne oui ; l’acceptation reste le lieu des bugs de cascade et de containment. Safari réel sur Mac distant = critère de « terminé », pas option. Forfaits, achat sans login, aide pour provisionner un nœud Apple Silicon.
Action finale : sur le Mac distant, ouvrez la préprod dans Safari, redimensionnez les conteneurs, basculez thèmes / vues denses, vérifiez qu’aucun tiers non couché ne reprend la main — une passe WebKit vaut plus qu’un seul diff Chromium.
① Figez Safari + Chromium minimum pour CI et appareils. ② Redimensionnez et inspectez les container queries + les gagnants @layer sur les vrais gabarits. ③ Joignez une capture ou un enregistrement WebKit depuis Safari sur Mac distant au ticket de release.
Enchaînez Safari réel à côté de votre CI Chromium
Un Mac loué dédié offre le WebKit que vos utilisateurs voient dans la nature — idéal pour les mises en page en container queries et les design systems en couches. Parcours sans compte : choisissez un forfait, SSH ou partage d’écran, et attachez une preuve WebKit à chaque release.