Organism, and it contains another
Shell
Two columns: the panel that belongs to the design process, and the product. 62 instances across 62 screens, and it is the outermost component in the system.
It is the only place where something that is not the product sits inside the same box as the product. base.css says the same thing from the other side: #sidebar is documentation chrome and it is declared there because it travels with every screen.
height:100vh at the desk and auto at 360, and both are load bearing. Pinned to one viewport, the columns scroll and the page does not, which is what makes the pane foot sticky and the queue head stay. At 360 the layout is a block, the document takes the scroll back, and every zone releases its own.
Stage 07 found this from the outside. min-height:100vh let the shell grow with its content, so bottom:0 had no scroll container to resolve against and the decision sat two viewports down. One word between a console and a very long web page.
The product still calls it .wf-shell, and step 6 renames it together with screen.
Anatomy
A diagram of the two columns, not a scaled scene. The shell is a browser window, and the one property that matters most about it, being exactly one viewport tall, is the property a documentation page cannot have. Drawing it and saying so is honest; rendering a 300px box and calling it the shell would not be. What is real below: the panel is --nav-w at 236px, and the two bands inside the product are --zone-top at 56px and --zone-strip at 26px.
dark, shipped
--nav-w · 236px
the project panel. Chrome, not product, and it is the only thing in this box that is not Harrier
height:100vh at the desk, so this column scrolls and the page does not
height:auto at 360, so the document takes the scroll back
a row, and the column inside it is screen. Only one of the two stacks
drawn at the desk. At this width the row is a block: the panel sits over the product and the page takes the scroll back
light, the pair
--nav-w · 236px
the project panel. Chrome, not product, and it is the only thing in this box that is not Harrier
height:100vh at the desk, so this column scrolls and the page does not
height:auto at 360, so the document takes the scroll back
a row, and the column inside it is screen. Only one of the two stacks
drawn at the desk. At this width the row is a block: the panel sits over the product and the page takes the scroll back
.shellthree declarations:display:flex,align-items:stretch,height:100vh. It reads nothing at all, because it is layoutalign-items:stretchwhat makes both columns full height rather than as tall as their content. Without it the panel ends where its last link does and the rule down its side stops halfwayheight:100vhnotmin-height, and the difference is a defect stage 07 found from the outside. A minimum lets the box grow with its content, and aposition:stickyfoot then has no scroll container to resolve against#sidebarthe project panel, at--nav-w. Declared inbase.cssrather than here, because it travels with every screen and belongs to the process rather than to the productscreenthe product, and the other child. A column, where this is a row- at 360
display:blockandheight:auto. The panel stacks over the product, and every zone inside releases the scroll it was holding for the desk
Behaviour at width
Below 1280, the system's one point (Width), the shell stops being a flex row pinned to one viewport and becomes a block of height:auto. Both halves are load bearing. At height:100vh the columns scroll and the page does not, which is what makes the pane foot sticky and the queue head stay; below the point the document takes the scroll back and every zone releases its own. Stage 07 found this from the outside: min-height:100vh let the shell grow with its content, so bottom:0 had no scroll container to resolve against and the decision sat two viewports down.
Variants
There are none, on any axis, and this is the only component in the system where that is true of every axis at once.
| Axis | Value | Uses | The rule |
|---|---|---|---|
| form | no values | – | One form on all 62. Three declarations do not have a second version |
| viewport | no values | – | Prohibited as an axis, and it is the one that looks most like a variant. Width is layout, and the register took the viewport twins off the variant list for exactly this reason. The 360 rendering is the same component answering a media query |
| route | no values | – | The door and the console are the same shell. The route is screen’s axis, one level in, because what changes is what is in the column and not that there is one |
| panel | no values | – | Prohibited, and it is a scope decision rather than a design one. The panel is on every screen because this is a portfolio build. A shipped Harrier has one column, and that is a deletion rather than a variant |
When to use it
Once per page, as the first element in the body, holding exactly two children. There is no case in this product where it is used differently, and no case where it is nested.
Where she meets it. Never, and it would be a defect if she did. What she meets is its consequence: the queue head that stays while two hundred rows go past, the verdict buttons that sit at the foot of the pane instead of two screens down, and the fact that a console at 1440 behaves like an application rather than like a document. All three are height:100vh.
Rule and anti-rule
The two drawings below are proportional in width and 130px tall: the comparison is about which box holds the panel, and neither arrangement has a height token.
Do
the process
the product, whole
Two children, side by side. The product column is untouched by the panel beside it, and deleting the panel leaves a shipped console rather than a hole.
Do not
the product, now holding something that is not it
Never inside. screen is the product and nothing else, which is why base.css declares the panel as documentation chrome from the other side. Put the panel in there and the product has to make room for the process, and the day the panel goes the product does not know how to be whole.
States
It has none, and it is not interactive. It reads no colour role either: this is the one component in the system whose entire declaration is geometry.
dark, shipped
--nav-w · 236px
and it has no other
light, the pair
--nav-w · 236px
and it has no other
Narrow the window past 900 and the row becomes a block. That is the whole of what this component ever does, and it is the only thing here a reader can produce rather than take on trust.
What it reads, and where it stands
| Role | Surface | Where on the component | Dark | Light |
|---|---|---|---|---|
--bg-page | fill | nowhere. The shell sets no ground of its own; this is the page ground it stands on, painted by base.css on the body | ||
--text-primary | ink 4.5:1 | nowhere. Inherited straight through to both children, and named here so the empty row is a statement rather than an omission |
Two rows and both of them are empty, which is the point. The outermost component in a design system reading no colour at all is what keeps the theme a property of the root rather than something a container can override on its way down.
Copy this
The one line in the head is the theme, and it is in the head because of when it runs. design/system/theme.js puts the chosen ground on the root element before the first frame; design/_shell.js is loaded at the foot of the body, which is after the browser has already drawn the page in the other one. A screen that omits it does not break: it renders dark, and the bar quietly comes back with one control instead of two, because the shell will not render a button that cannot change anything. That is the failure this note exists to make loud, since nothing about the page looks wrong.
A screen is not drawn, it is assembled: this skeleton, plus classes from the system, plus the screen’s own content. Nothing on a screen carries a style of its own, and a detail that is missing goes into a component file first and onto the screen second. The five zones are node 0.1 of the IA and each has its own page: Z1, Z2, Z4, Z5, Z6.