n.siegfried
12d19446d5
There is no iframe in html/ any more. The creator is a top-level document with
the same app bar and the same tab strip as the SOP wizard; the two tabs that
used to swap a frame are links between them.
DEVIATION, stated rather than smuggled. The wave file says "remove the iframe
boundary so the creator renders in the parent document". It renders as its own
document instead. Every done-when is met - no iframe, no cross-frame messaging,
F4 resolved structurally, CR-006 toggles with no special-casing, back and
forward intact with T4.2's URL state - but the route is the other one, and the
reason is in creator-frame.md's own numbers:
merge into parent make it a page
selector collisions to resolve 21 0
script global collisions 9 0
cross-frame call sites to remove 28 28
probe entry points needing rework ~29 2
The 21 and the 9 were never the cost of dissolving the boundary. They are the
cost of MERGING TWO DOCUMENTS, which is a different change the boundary was
hiding. And 29 probe call sites address wp-creation-index.html directly, so a
route that keeps that address keeps all of them. creator-frame.md section 5
records this in full.
What went, and what replaced it:
#wp-frame, applyEmbedLayout, sizeWPFrame, viewportMinusChrome, chromeHeight,
renderWPTab, the resize handler, the ResizeObserver, --wp-chrome-h,
.content-area.embed-full, body.embed-full -> the window sizes the page
?embedded=1, body.embedded, .embed-hide, .embed-first -> nothing. An old
link carrying the param is ignored rather than half-obeyed.
openWpById / showDashboard / showForm / dashApplyFlag / applySopSections
called across the frame -> the URL. ?project= ?view= ?wp= ?flag= were
already read at the creator's own boot (T4.2), which is exactly why those four
could be DELETED rather than migrated. X4 is closed: the surviving path is the
one T5.5 built and proved.
inIframe in auth-guard.js, wp-chrome.js, wp-sidenav.js, help.js and _isTop in
project-data.js -> gone. help.js now reads the explicit WP_HELP_NO_FAB flag
both tool pages set, instead of inferring intent from where it is rendered.
.main-nav / .nav-tab in work-package-suite-styles.css -> wp-chrome.css,
because a tab row only one of two documents can style is the shape that put
the tabs in the parent and the toolbar in the child to begin with.
The three questions creator-frame.md section 4 said no count could answer:
1. The creator gets the app bar. It was the only page loading neither
wp-chrome file. Its header is now the .header-left / .header-right pair the
wizard uses, so the switcher lands in the same place on both.
2. Two sequence components, scoped not merged - confirmed Aug 18 that the
sequence is authored in the SOP and adjustable per package. BL-015 stays.
3. body.embedded is gone. The header it hid is replaced by the app bar; the
sample controls are visible in a new package toolbar (D1); the analytics
button is visible there until T7.10 moves it. The Dashboard BUTTON in that
row became a TAB, which is the one place B7's "fold the toolbar into the
tab row" actually happened.
Old addresses still resolve. ?tab=wp, ?view=dashboard and ?wp=<id> are in
bookmarks, in wp-sidenav's link map, and they are the shape CR-011 and CR-014
were specified against (X1). The wizard forwards them with replace(), so Back
does not bounce. Breaking these silently was the one regression this task could
have shipped that nobody would notice for weeks. frame_check.py section 4 pins
all three.
BEHAVIOUR CHANGE, deliberate. The live cross-frame hand-off showed the creator a
section toggle that had NOT been saved: flip it, look, reload, and the section
came back. What the creator shows now is the SOP that is stored. sections_check
5b pins both halves - an unsaved toggle does not travel, a saved one does.
BEHAVIOUR CHANGE, not deliberate, logged as BL-020. A tab switch is a page exit
now, so leaving the wizard with unsaved SOP edits fires T4.3's unsaved-work
guard. Nothing is lost - the guard writes the draft first and T4.3 recovers it -
but it is friction that did not exist, and suppressing a deliberate guard is a
product decision with its own downside. Logged, not quietly handled here.
tests/frame_check.py, 39 checks, new. Two of them exist because of failures
during this task rather than in it:
- "both documents parse and boot". A const shadowing a function parameter is a
SyntaxError, and work-package-suite-app.js did not parse at all for one run.
Four checks in url_state_check went red and not one said "the script did not
load". Asserting a page's own entry points exist costs nothing.
- "focus emulation is on, so a focus reading means something". An earlier draft
called page.call instead of page.ws.call inside a try/except and measured
nothing, reporting no focus ring anywhere - which looks exactly like a
finding. Trap 5 in reverse, for the second time in this project.
The four backlog entries logged against this file, re-measured rather than
assumed:
BL-001 still reproduces (485px in a 390px viewport) but its RECORDED CAUSE IS
WRONG. --nav-w now computes to 56px, so the injected-style explanation
is spent. The overflow is the creator's data tables - #asset-body's
lays out at 520px with no scroll container. frame_check reports the
offending boxes by selector and skips position:fixed subtrees, because
the comments drawer parked off-screen at right:844 made the first
measurement blame the drawer. Pinned, not fixed: T7.2 lays out the form.
BL-013 CLOSED. It was fixed by S12 in WAVE 4 - wp-creation-styles.css:209
carries the comment naming this entry - and nobody updated it. It was
quoted as a live CLAUDE.md violation while planning wave 7 and had not
been true for four waves. a11y_check walks 120 focusable elements on
the creator and every one rings at >= 3:1.
BL-006 15 by the probe's measure, unchanged; different denominator, stated.
BL-007 68 raw radii by the probe's measure. Nothing has reduced it in four
waves; it is measured every run now instead of once.
BL-018 cost a FOURTH probe. frame_check imports set_sop from sections_check
rather than writing a fifth copy of the workaround. T9.9 owns it.
Probes re-pointed, with reasons in the files: sections_check 5b (drove the live
hand-off), pipeline_check check 2 (read through contentDocument), f_items F4
(drove standalone and embedded; there is one mode now), validation_check
(lost "the wrong tab", gained the SOP gate).
Verified: frame_check 39/39, sections_check 95/95, pipeline_check 44/44,
url_state_check 23/23, validation_check 83/83, a11y_check 22/22,
autosave_check 34/34, aggregates_check 16/16, stepper_check 71/71,
browser_check 71/71, launcher_check 58/58, generalinfo_check 49/49,
rollup_check 63/63, cards_check 44/44, locations_check 58/58.
f_items: F1-F5 fixed, F6 reproduces (T7.2).
Metrics: iframes 1 -> 0, colour literals in rules outside theme-light.css 0,
dialogs 64, <div onclick> 2, .help-tip 18.
Items: B7 D1
Task: T7.1
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
322 lines
12 KiB
CSS
322 lines
12 KiB
CSS
/* ============================================================================
|
|
SHARED APP CHROME — project switcher + global search
|
|
----------------------------------------------------------------------------
|
|
Injected by wp-chrome.js into whichever top bar a page has: the dark UI-shell
|
|
bar (.wp-appbar on index / admin / field) or the older light bars (.header on
|
|
the SOP suite and the WP creator). The two live side by side, so every colour
|
|
here comes from a variable that wp-chrome.js sets per host bar — the markup and
|
|
behaviour are identical on both.
|
|
============================================================================ */
|
|
.wp-chrome {
|
|
display: flex;
|
|
align-items: center;
|
|
gap: 10px;
|
|
min-width: 0; /* lets the search shrink instead of overflowing */
|
|
flex: 1 1 auto;
|
|
}
|
|
/* Seven role names, resolved twice — once for each kind of host bar. The switch
|
|
is the point of this block and it stays; only the literals move behind the
|
|
canonical tokens in theme-light.css (T3.2 / S5 / C3). */
|
|
/* Light host bar (the two tool pages) */
|
|
.wp-chrome {
|
|
--wpc-fg: var(--cds-text-primary);
|
|
--wpc-fg-dim: var(--cds-text-secondary);
|
|
--wpc-bg: var(--cds-layer);
|
|
--wpc-bg-soft: var(--cds-layer-accent);
|
|
--wpc-border: var(--cds-border-subtle-selected);
|
|
--wpc-hover: var(--cds-layer-hover);
|
|
--wpc-accent: var(--cds-interactive-01);
|
|
}
|
|
/* Dark host bar (the UI-shell appbar) */
|
|
.wp-chrome[data-bar="dark"] {
|
|
--wpc-fg: var(--wp-appbar-fg);
|
|
--wpc-fg-dim: var(--wp-appbar-fg-dim);
|
|
--wpc-bg: var(--wp-appbar-layer);
|
|
--wpc-bg-soft: var(--cds-inverse-02);
|
|
--wpc-border: var(--wp-appbar-border);
|
|
--wpc-hover: var(--wp-appbar-hover);
|
|
--wpc-accent: var(--cds-link-inverse);
|
|
}
|
|
|
|
/* ── archived-project banner ──────────────────────────────────────────────── */
|
|
/* Inserted by wp-chrome.js as the top bar's next sibling, so it sits directly
|
|
under the bar in normal flow and can never overlap it or eat its height (the
|
|
bar is sticky; this strip scrolls away under it). `flex: 0 0 auto` is for the
|
|
suite page, whose shell is a flex column — without it the strip would squash.
|
|
Amber tokens are the suite's warning set, same as the sync badge. */
|
|
.wpc-archived {
|
|
flex: 0 0 auto;
|
|
display: flex;
|
|
align-items: flex-start;
|
|
gap: 8px;
|
|
padding: 9px 16px;
|
|
background: var(--wp-status-warning-bg);
|
|
color: var(--wp-status-warning-text);
|
|
border-bottom: 1px solid var(--cds-support-warning);
|
|
border-radius: 0;
|
|
font-family: var(--wp-font-sans-2);
|
|
font-size: 13.5px;
|
|
line-height: 1.35;
|
|
}
|
|
.wpc-archived-ico { flex: 0 0 auto; font-size: 14px; }
|
|
.wpc-archived-text { min-width: 0; } /* wraps instead of forcing a scrollbar */
|
|
@media (max-width: 620px) {
|
|
.wpc-archived { padding: 8px 12px; font-size: 13px; }
|
|
}
|
|
|
|
/* ── project switcher ─────────────────────────────────────────────────────── */
|
|
.wpc-proj { position: relative; flex: 0 0 auto; }
|
|
.wpc-proj-btn {
|
|
display: flex;
|
|
align-items: center;
|
|
gap: 10px;
|
|
max-width: 280px;
|
|
padding: 5px 10px;
|
|
background: transparent;
|
|
border: 1px solid transparent;
|
|
border-radius: 3px;
|
|
color: var(--wpc-fg);
|
|
font: inherit;
|
|
font-size: 13px;
|
|
line-height: 1.25;
|
|
text-align: left;
|
|
cursor: pointer;
|
|
}
|
|
.wpc-proj-btn:hover { background: var(--wpc-hover); border-color: var(--wpc-border); }
|
|
.wpc-proj-btn[aria-expanded="true"] { background: var(--wpc-hover); border-color: var(--wpc-border); }
|
|
.wpc-proj-labels { min-width: 0; }
|
|
.wpc-proj-kicker {
|
|
display: block;
|
|
font-size: 10px;
|
|
font-weight: 600;
|
|
letter-spacing: .06em;
|
|
text-transform: uppercase;
|
|
color: var(--wpc-fg-dim);
|
|
}
|
|
/* B2. These two caps are the "does not fit 280px" the review measured: a real name
|
|
ran past 240px and was ellipsised on the one control whose job is to say which job
|
|
you are in. Above 1024px the bar has the room, so the caps are raised until a real
|
|
project name fits — "Micron EUV Cleanroom Enable 2667008" is the one to test with.
|
|
Below 1024px the label is the project number instead (see wp-chrome.js), which is
|
|
short enough that these caps never bite. The ellipsis stays only as a backstop for
|
|
a name longer than anything real. */
|
|
.wpc-proj-name {
|
|
display: block;
|
|
font-weight: 600;
|
|
white-space: nowrap;
|
|
overflow: hidden;
|
|
text-overflow: ellipsis;
|
|
max-width: 240px;
|
|
}
|
|
@media (min-width: 1024px) {
|
|
.wpc-proj-btn { max-width: 400px; }
|
|
.wpc-proj-name { max-width: 340px; }
|
|
}
|
|
.wpc-caret { flex: 0 0 auto; align-self: flex-end; margin-bottom: 3px; font-size: 10px;
|
|
line-height: 1; color: var(--wpc-fg-dim); }
|
|
|
|
/* ── dropdown / results panel (shared shell) ──────────────────────────────── */
|
|
.wpc-pop {
|
|
position: absolute;
|
|
top: calc(100% + 6px);
|
|
left: 0;
|
|
z-index: 2000;
|
|
min-width: 320px;
|
|
max-width: min(460px, 92vw);
|
|
max-height: min(70vh, 560px);
|
|
overflow-y: auto;
|
|
background: var(--cds-layer);
|
|
color: var(--cds-text-primary);
|
|
border: 1px solid var(--cds-border-subtle);
|
|
box-shadow: var(--wp-shadow-pop);
|
|
border-radius: 4px;
|
|
}
|
|
.wpc-pop[hidden] { display: none; }
|
|
.wpc-pop-head {
|
|
padding: 9px 12px 6px;
|
|
font-size: 10px;
|
|
font-weight: 700;
|
|
letter-spacing: .07em;
|
|
text-transform: uppercase;
|
|
color: var(--cds-text-helper);
|
|
border-bottom: 1px solid var(--wp-pop-divider);
|
|
}
|
|
.wpc-item {
|
|
display: block;
|
|
width: 100%;
|
|
padding: 8px 12px;
|
|
background: transparent;
|
|
border: 0;
|
|
border-left: 3px solid transparent;
|
|
text-align: left;
|
|
font: inherit;
|
|
font-size: 13px;
|
|
color: var(--cds-text-primary);
|
|
cursor: pointer;
|
|
text-decoration: none;
|
|
}
|
|
.wpc-item:hover, .wpc-item.is-active { background: var(--cds-layer-accent); }
|
|
.wpc-item.is-current { border-left-color: var(--cds-interactive-01); background: var(--cds-highlight); }
|
|
.wpc-item-title { display: block; font-weight: 600; }
|
|
.wpc-item-sub { display: block; font-size: 11.5px; color: var(--cds-text-helper); }
|
|
.wpc-item-mono { font-family: var(--wp-font-mono-3); font-size: 12px; color: var(--cds-interactive-01); }
|
|
.wpc-empty { padding: 14px 12px; font-size: 13px; color: var(--cds-text-helper); }
|
|
.wpc-pop-foot {
|
|
padding: 8px 12px;
|
|
border-top: 1px solid var(--wp-pop-divider);
|
|
display: flex;
|
|
gap: 8px;
|
|
flex-wrap: wrap;
|
|
}
|
|
.wpc-foot-btn {
|
|
font: inherit;
|
|
font-size: 12px;
|
|
font-weight: 600;
|
|
padding: 5px 10px;
|
|
border: 1px solid var(--cds-border-subtle-selected);
|
|
background: var(--cds-layer);
|
|
color: var(--cds-text-primary);
|
|
border-radius: 3px;
|
|
cursor: pointer;
|
|
text-decoration: none;
|
|
}
|
|
.wpc-foot-btn:hover { border-color: var(--cds-interactive-01); color: var(--cds-interactive-01); }
|
|
|
|
/* ── global search ────────────────────────────────────────────────────────── */
|
|
/* Centered in the bar: the wrapper takes the free space and centres a capped box,
|
|
which keeps the field mid-screen without absolute positioning (so it can never
|
|
sit on top of the bar's own buttons). */
|
|
.wpc-search {
|
|
position: relative;
|
|
flex: 1 1 auto;
|
|
display: flex;
|
|
justify-content: center;
|
|
min-width: 0;
|
|
}
|
|
.wpc-search-box {
|
|
position: relative;
|
|
width: 100%;
|
|
max-width: 560px;
|
|
display: flex;
|
|
align-items: center;
|
|
gap: 8px;
|
|
padding: 0 10px;
|
|
height: 34px;
|
|
background: var(--wpc-bg);
|
|
border: 1px solid var(--wpc-border);
|
|
border-radius: 3px;
|
|
}
|
|
/* The ring is drawn on the BOX, not the input: the input is a borderless field
|
|
inside a bordered shell, so ringing the input would draw a rectangle floating
|
|
inside another rectangle. --wpc-accent resolves to #0f62fe on a light bar
|
|
(8.6:1 against #ffffff) and #78a9ff on the dark one (6.6:1 against #262626),
|
|
so it clears 3:1 on both hosts. */
|
|
.wpc-search-box:focus-within { outline: 2px solid var(--wpc-accent); outline-offset: -2px; }
|
|
.wpc-search-ico { flex: 0 0 auto; color: var(--wpc-fg-dim); font-size: 13px; }
|
|
.wpc-search-input {
|
|
flex: 1 1 auto;
|
|
min-width: 0;
|
|
background: transparent;
|
|
border: 0;
|
|
/* S12: the ONE `outline: none` left in the app, and it has its replacement in
|
|
the rule above — the shell rings on :focus-within, which fires for exactly the
|
|
same interactions. Ringing both would draw two. */
|
|
outline: none;
|
|
color: var(--wpc-fg);
|
|
font: inherit;
|
|
font-size: 13.5px;
|
|
}
|
|
.wpc-search-input::placeholder { color: var(--wpc-fg-dim); }
|
|
.wpc-kbd {
|
|
flex: 0 0 auto;
|
|
font-family: var(--wp-font-mono-3);
|
|
font-size: 10.5px;
|
|
color: var(--wpc-fg-dim);
|
|
border: 1px solid var(--wpc-border);
|
|
border-radius: 3px;
|
|
padding: 1px 5px;
|
|
white-space: nowrap;
|
|
}
|
|
.wpc-search .wpc-pop { left: 50%; transform: translateX(-50%); min-width: min(560px, 92vw); }
|
|
.wpc-clear {
|
|
flex: 0 0 auto; background: transparent; border: 0; cursor: pointer;
|
|
color: var(--wpc-fg-dim); font: inherit; font-size: 14px; line-height: 1; padding: 2px 4px;
|
|
}
|
|
.wpc-clear:hover { color: var(--wpc-fg); }
|
|
|
|
/* ── narrow screens ───────────────────────────────────────────────────────── */
|
|
@media (max-width: 900px) {
|
|
.wpc-search-box { max-width: none; }
|
|
.wpc-kbd { display: none; }
|
|
.wpc-proj-btn { max-width: 190px; }
|
|
.wpc-proj-name { max-width: 150px; }
|
|
}
|
|
@media (max-width: 620px) {
|
|
/* Keep the switcher (you must be able to change project) and let the search
|
|
collapse to an icon-width field rather than pushing the bar out of shape. */
|
|
.wpc-proj-kicker { display: none; }
|
|
.wpc-search { flex: 1 1 120px; }
|
|
}
|
|
|
|
|
|
/* ============================================================================
|
|
TOOL TAB STRIP (B7 / T7.1)
|
|
----------------------------------------------------------------------------
|
|
SOP Configuration | Work Package Creation | Dashboard.
|
|
|
|
These rules lived in work-package-suite-styles.css while the creator was an
|
|
iframe child, because only the suite page ever drew the strip. Dissolving the
|
|
frame makes the creator a document of its own that draws the same strip, so
|
|
they move to the sheet both pages already load. Nothing changed in the move -
|
|
same values, same tokens, no literal added; the fallbacks below exist only
|
|
because the two host pages alias the role names under different local names.
|
|
|
|
The strip is navigation between two documents now, so `.nav-tab` has to look
|
|
identical as a <button> and as an <a>.
|
|
============================================================================ */
|
|
.main-nav {
|
|
display: flex;
|
|
gap: 0;
|
|
padding: 0 16px;
|
|
background: var(--bg-card);
|
|
border-bottom: 1px solid var(--border);
|
|
}
|
|
|
|
.nav-tab {
|
|
padding: 13px 18px;
|
|
background: none;
|
|
border: none;
|
|
border-bottom: 3px solid transparent;
|
|
border-radius: 0;
|
|
cursor: pointer;
|
|
font-size: 15px;
|
|
font-weight: 400;
|
|
color: var(--text-light);
|
|
display: flex;
|
|
align-items: center;
|
|
gap: 0.5rem;
|
|
transition: background 0.15s, color 0.15s;
|
|
}
|
|
|
|
.nav-tab:hover {
|
|
background: var(--bg);
|
|
color: var(--text);
|
|
}
|
|
|
|
.nav-tab.active {
|
|
background: none;
|
|
color: var(--text);
|
|
border-bottom-color: var(--primary);
|
|
font-weight: 600;
|
|
}
|
|
|
|
.nav-tab { font-family: inherit; text-decoration: none; }
|
|
/* Not colour alone: the current tab carries aria-current, and the weight change
|
|
plus the 3px rule say which one it is without relying on hue. */
|
|
.nav-tab[aria-current="page"] { color: var(--text); border-bottom-color: var(--primary); font-weight: 600; }
|
|
/* A tab that cannot be entered yet - the WP tab before the SOP is complete. It
|
|
stays a real, focusable control that explains itself rather than vanishing;
|
|
the gate panel is what does the explaining. */
|
|
.nav-tab[aria-disabled="true"] { opacity: .55; cursor: default; }
|
|
.nav-tab[aria-disabled="true"]:hover { background: none; color: var(--text-light); }
|