Problem
The packaged Code OSS 1.137 browser workbench renders its Welcome page incorrectly in WebScene while Chromium renders the same server payload correctly. At a 1440 x 972 logical viewport with the Chat auxiliary bar open, the Start, Recent, and Walkthroughs regions overlap and clip instead of occupying their named grid regions.
The unchanged VS Code stylesheet uses:
.gettingStartedCategoriesContainer {
display: grid;
grid-template-rows: 25% minmax(min-content, auto) min-content;
grid-template-columns: 1fr 6fr 1fr 6fr 1fr;
grid-template-areas:
". header header header ."
". left-column . right-column ."
". footer footer footer .";
}
.categories-column-left { grid-area: left-column; }
.categories-column-right { grid-area: right-column; }
.header { grid-area: header; }
.footer { grid-area: footer; }
WebScene currently handles grid-template-columns, grid-template-rows, numeric grid-area/grid-row/grid-column, and auto placement. It does not parse or apply grid-template-areas, and named grid-area values therefore fall back to the wrong placement. The current compatibility classification can report the placement declaration as supported even when its value is a named area that cannot be resolved.
Reproduction
- Launch the current AppScene/WebScene Code OSS release at 1440 x 972 logical pixels with a fresh profile.
- Leave the Welcome editor and Chat auxiliary bar visible.
- Compare to Chromium using the same Node server, source payload, workspace/profile settings, and viewport.
- Observe overlapping/clipped Welcome content only in WebScene.
Native computer-use evidence records accepted AppScene mouse/key events. Chromium CDP interaction against the same live server remains responsive. A separate input/publication investigation may be needed; the grid defect is independently visible on the first presented frame.
Proposed implementation
- Parse
grid-template-areas as rows of equal-width area tokens, including . empty cells.
- Validate rectangular named regions and reject invalid declarations atomically according to CSS Grid parsing rules.
- Resolve a grid item's named
grid-area, plus named grid-row-start/grid-column-start references where supported, into explicit row/column lines before auto placement.
- Preserve authored/computed CSSOM serialization and invalidate layout when the template or item assignment changes.
- Report named placement as supported only when the semantic slice is actually implemented.
- Keep the implementation in WebScene; do not patch VS Code.
Acceptance and gates
- Add focused WPT-style parsing/computed-value tests based on upstream CSS Grid named-area coverage.
- Add a product-neutral rendered layout reduction matching the five-column/three-row Welcome pattern, including
minmax(min-content, auto), fractional tracks, empty cells, and resize-driven constrained layout.
- Add mutation tests for changing/removing
grid-template-areas and grid-area without stale placement.
- Compare native geometry with the Chromium reference at normal and constrained widths.
- Add a bounded benchmark for parsing, resolving, and relaying out a representative named-area grid; fail on material regression in CSS cascade/layout/publication.
- Run native/portable WebScene contracts and the packaged Code OSS visual/feature acceptance gate.
Related project scope
This is a generic CSS Grid compatibility fix and belongs in WebScene. It unlocks the unchanged VS Code Welcome experience and other browser applications that depend on named grid areas. It should be developed as a focused draft PR against feature/code-oss-browser-compatibility, then consolidated into PR #76 after all gates pass.
Problem
The packaged Code OSS 1.137 browser workbench renders its Welcome page incorrectly in WebScene while Chromium renders the same server payload correctly. At a 1440 x 972 logical viewport with the Chat auxiliary bar open, the Start, Recent, and Walkthroughs regions overlap and clip instead of occupying their named grid regions.
The unchanged VS Code stylesheet uses:
WebScene currently handles
grid-template-columns,grid-template-rows, numericgrid-area/grid-row/grid-column, and auto placement. It does not parse or applygrid-template-areas, and namedgrid-areavalues therefore fall back to the wrong placement. The current compatibility classification can report the placement declaration as supported even when its value is a named area that cannot be resolved.Reproduction
Native computer-use evidence records accepted AppScene mouse/key events. Chromium CDP interaction against the same live server remains responsive. A separate input/publication investigation may be needed; the grid defect is independently visible on the first presented frame.
Proposed implementation
grid-template-areasas rows of equal-width area tokens, including.empty cells.grid-area, plus namedgrid-row-start/grid-column-startreferences where supported, into explicit row/column lines before auto placement.Acceptance and gates
minmax(min-content, auto), fractional tracks, empty cells, and resize-driven constrained layout.grid-template-areasandgrid-areawithout stale placement.Related project scope
This is a generic CSS Grid compatibility fix and belongs in WebScene. It unlocks the unchanged VS Code Welcome experience and other browser applications that depend on named grid areas. It should be developed as a focused draft PR against
feature/code-oss-browser-compatibility, then consolidated into PR #76 after all gates pass.