Shell header identity: device-inline evidence flips nav overlay mode; style whitespace breaks equivalence

Abierto
  • ¿Algo no está bien?
#5,013 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
php
Área
backend

Línea de trabajo

Start with WordPressSitePlan/ShellExtraction.php, especially absorbResponsiveVariantLandmarks() and normalizeNestedChromeMarkup(), then trace NavigationToggleSuppressor::navigationOverlayMenu() and its source-variant checks. Add neutral regressions for descendant tablet-only inline evidence and whitespace differences in inline style declarations. Done means both route pairs project equivalent navigation and extract one shared header part.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

Shell extraction (WordPressSitePlan/ShellExtraction.php, absorbResponsiveVariantLandmarks() → per-variant identity_markup signatures) excludes routes as non_equivalent when their source header is identical but incidental capture evidence differs. Two independent causes were observed on one multi-route capture (7 routes; only 4 got the shared header part):

1. Per-device inline evidence on one menu item flips the whole navigation's overlay mode

On one route, a single <li> inside the desktop nav carries tablet-only inline evidence (width: 93px instead of the desktop 88px):

<li … style="position: relative;…;width: 88px;height: 38px"
    data-blocks-engine-capture-device-inline="{&quot;tablet&quot;:&quot;position: relative;…;width: 93px;height: 38px&quot;}">

That route projects the nav as:

  • overlayMenu:"mobile"
  • blocks-engine-native-responsive-navigation blocks-engine-navigation-overlay-…
  • the parent group gets blocks-engine-sidebar-navigation-carrier

The other routes project overlayMenu:"never" with no carrier. The source has no toggle for this nav; the phone layout is a separate device document. Removing only that one attribute makes the route project never and join the shared header.

A related route that is missing one coalesced device stylesheet (a separate DLA issue) flips the same way. That suggests NavigationToggleSuppressor::navigationOverlayMenu() (hasEquivalentSourceNavigationVariant() or navigationToggleControl()) is reading evidence that shouldn't decide the overlay mode.

2. The identity signature is sensitive to whitespace in serialized style values

After normalization, the home route's desktop signature differs from the others only in serialized inline styles inside block attributes:

"style":"visibility:inherit;overflow-x:visible"   vs   "style":"visibility: inherit;overflow-x: visible"
"itemStyle":"position:relative;box-sizing:border-box;…"  vs  "position: relative;box-sizing: border-box;…"

Same declarations, different whitespace. normalizeNestedChromeMarkup() does not canonicalize declaration text stored in block attribute JSON.

Expected

  • A navigation's overlay mode is decided by real collapse evidence: a source toggle, or an equivalent source navigation variant within the same document. Device-inline style evidence on a descendant, or stylesheets scoped to another device document, don't turn a non-collapsing nav into a native responsive overlay.
  • Shell identity treats CSS declaration lists that differ only in whitespace as equal (or the projection serializes them canonically, so both routes emit the same text).

Acceptance

  • Neutral regression with two routes sharing an identical header nav, where one route has a descendant item with data-blocks-engine-capture-device-inline tablet evidence. Both project the same overlayMenu and the header becomes one shared part.
  • Neutral regression where two routes' headers differ only in whitespace inside an inline style. They extract one shared header part.

AI disclosure: investigated and drafted by Claude (Opus) via the Pi coding agent (Franklin) for Chris Huber, from a Brandspell Wix import (DLA 0.33.169 / php-transformer 0.45.305).

Lenguaje dominante
PHP
Estrellas
25
Forks
3
Merge medio
2 h 23 min
PR fusionados (30 d)
942

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Automattic/blocks-engine

Todos los issues de Automattic/blocks-engine

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.