Sign inRegisterCheck connection

Content Versus Chrome: The Blank Inner Page

Why a weather observation article should inherit headers, menus, unit labels, and footer credits instead of hard-coding chrome on every page.

Back to Personal weather station notebooks

The unique part of a weather page should be the observation, the table, or the note you actually wrote. Everything else—the station name, the menu, the unit legend, the footer credits—is chrome, and chrome is a quality-control surface. If each article hard-codes its own header, a units change or a corrected station identifier will update some pages and miss others. The site will still look like one station. It will no longer publish as one station.

The historical file at this URL was a sample blank page: a content region that inherited the include system and contained almost no payload of its own. That emptiness was the demonstration. This article keeps that intent. It is not a second architecture overview (/nb-0200) and not a walk through the include pipeline (/nb-0200/index.php). It is about the seam between inherited frame and unique science.

Historical context

On the original weather-station site, sample.php sat next to the include-stack notebook so a reader could see the chrome working with a nearly empty inner div. Navigation, heading region, and footer were already present. The sentence in the middle was a placeholder. Incoming links that expected a “blank sample page” were looking at that inheritance demo, not at a live dashboard.

The recovered page also captured leftover template chrome (repeated brand strings, jump lists, an access counter). That residue is not useful as an article and is not rebuilt here. The pedagogical point survives without it: a station page is allowed to be almost empty in the middle if the frame is complete.

Content is the payload; chrome is the method note

In laboratory publishing, a figure has a caption, a unit, and a credit. The photograph is not allowed to invent a second caption that disagrees with the paper. A weather site is the same document at website scale.

Content is the payload: today’s rain total and the period it covers, a storm narrative, a calibration note, a climate table, a text bulletin. It is allowed to be specific, dated, and local.

Chrome is the method note that must not vary by article: which station this is, which units the site uses, how to reach siting information, who operates the logger, and that the page is not an official forecast-office product.

When an author pastes a header into an observation article, they have copied the method note by hand. Hand copies drift. Template inheritance exists so the method note is generated, not remembered.

That is why the sample was blank. If the inner page can be empty and the station is still identifiable, navigable, and credited, then every future article can be only payload. Authors are not tempted to “fix” a missing menu by pasting one.

Why observation articles should not hard-code headers

Headers on weather pages do more than brand the operator. They usually carry a clock, a station title, and sometimes a unit summary. Those fields are exactly the fields that must stay synchronized with the body.

A hard-coded header fails in predictable ways:

  • The article still says last year’s station name after the network identifier changed.
  • The article still prints °F after the site policy moved dual-units into a helper.
  • The article’s clock uses the server zone while inherited pages use the station zone.
  • The article’s menu omits a new climate product, so readers of that storm note cannot reach the table that would put the event in seasonal context.
  • The article’s footer omits the “not an official NWS product” line that every other page carries.

Each of those is a quality-control miss, not a design preference. Official station networks spend real effort on consistent station headers for the same reason: a user who pages from one product to another must not have to re-learn which instrument they are reading.

Inheritance as a quality-control tool

Think of the include (or layout, or component shell) as a checklist that runs on every response.

Same footer credits. Provenance is easy to skip when someone is rushing a storm page online. Inherited footers make the skip impossible. The credit does not have to be verbose. It has to be the same credit.

Same unit labels. A legend in the chrome—“temperatures in °F, rain in inches, pressure in inHg”—is a contract. The body may still print dual units, but it prints them through helpers that honor the contract. An article that invents mb on one line and hPa on the next, with no chrome legend, is two unit systems pretending to be one record.

Same navigation. Quality control is not only about numbers. It is about whether the reader can reach the siting page, the text bulletin, and the climate archive from the article they landed on. Inherited menus keep those routes available on a blank page and on a 2,000-word storm note alike.

Same identity on error pages. A missing article that still shows the station header tells the visitor they have not left the instrument. A missing article that shows a bare server error does not.

The blank sample is the test fixture for that checklist. If you can load an empty content slot and still see identity, units, menu, and credits, the QC surface is in place before the first real observation article is written.

What belongs in the inner page

Once chrome is inherited, the inner page should contain only what cannot be shared:

  • The observation or narrative unique to this URL.
  • Figures and tables unique to this URL, still formatted with shared helpers.
  • Links that are specific to the argument (a particular NOAA report, a particular day).
  • Explicit dates on any snapshot. A storm note for 12 August 2005 must say so in the payload. The header clock is “now”; it is not the event time.

The inner page should not contain a second copy of the station title block, a second unit policy, or a second footer. If the payload needs a different title, set a title variable before the chrome includes run, as the include-stack article describes. That keeps the browser tab and the header in agreement without forking the header file.

A conceptual content page, using original names rather than the recovered sample:

<?php
require_once 'settings.php';
require_once 'helpers.php';
$PAGE_TITLE = 'Storm notes for 12 August 2005';
include 'document-open.php';
include 'site-header.php';
include 'site-menu.php';
?>
<article>
  <h1>Storm notes for 12 August 2005</h1>
  <p>Payload only: dated event, measured rain, and what the gauge could not see.</p>
</article>
<?php include 'site-footer.php'; ?>

The article element is the only place new science is allowed to appear. The includes around it are the QC frame.

Practical review

When you inspect a station article—historical PHP or a modern layout—ask:

  1. If I delete the inner HTML, does the page still identify the station, the units, and the operator?
  2. Does this article paste a header, menu, or footer that could disagree with other pages?
  3. Are snapshot dates in the payload, distinct from the header clock?
  4. Do unit symbols in the article come from the same helpers the chrome uses?
  5. Can I reach siting and climate pages from this article without a hand-built mini-menu?

If the answer to (1) is no, the sample-page lesson was skipped: chrome is incomplete. If the answer to (2) is yes, inheritance was abandoned and QC will drift.

Modern relevance

Content-management templates, static-site layouts, and frontend shells all have a content slot. The slot is the sample blank page. Filling it with a second site header is still the error. Weather publishing is simply less forgiving of that error than a marketing site, because the header is carrying metadata.

TNET’s data sources and methodology brief is the modern place that discipline shows up: labels, provenance, and the difference between observed and derived values are part of the published result. The weather notebooks hub lists the related historical notes; this sample remains the inheritance demo, not that hub.

Sources