Repository navigation
Conversation
The app's heading and tracking rules were unlayered, so they beat every layer, the workspace's tenant CSS included: a portal's own CSS could not change its headline's weight or tracking. On a portal drawn by the design engine they now sit in a design layer between utilities and tenant. They still beat utilities, as before, and the workspace's CSS beats them. The admin and portals on the old theme keep the unlayered rules, scoped with :where so their specificity is what it was.
mortondev
force-pushed
the
feat/portal-design-v2-phase5-design-layer
branch
from
October 31, 2026 08:31
1bab443 to
e3899cb
Compare
Member
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The twenty-fifth of the stack that builds a new design engine for the portal, and the last of phase 5. A workspace's own CSS can now restyle a part's type, such as its headline's weight and tracking. Behind the
portalDesignV2flag; nothing changes for the admin or for portals on the old theme.Why
The app's heading rule (
h1, h2, h3 { font-weight: 600; letter-spacing: -0.02em }) and the root tracking were unlayered, and so was the design's heading weight, which had to beat them. Unlayered rules beat every layer, the workspace's CSS intenantincluded, so a portal's CSS could set a headline's colour or size but not its weight or tracking.What changes
globals.cssdeclares adesignlayer betweenutilitiesandtenant:@layer theme, base, components, utilities, design, tenant;.@layer design. They beat utilities, as the unlayered rules did, and the workspace's CSS beats them. The heading family stays inbase, so a utility on a heading still wins, as before.:where(:root:not([data-portal-theme])).:wherekeeps their specificity what it was, so rules such as[data-settings-page] h3still win over them.The spec's alternative, moving the app's rules into
basefor every page, would let anyfont-*ortracking-*utility on a heading start winning across the admin and old portals. This keeps those pages as they are.Verification
[data-qb-part="headline"] { font-weight: 400; letter-spacing: 0.05em; }applied in the preview. After publishing, the live headline drew at 400 with 0.05em tracking (1.5px at 30px), and post titles kept the design's 600 and tight tracking.h1, h2, h3or:rootrule left, and the design's type rules in the design layer.