Examples
Sidebar regions
A whole page rather than a piece of one: the sidebar regions of the theme are filled for this page, so the content sits between a navigation column and a column of page metadata. Every other example is markup dropped in the content region, which says nothing about where the content region is; this one is about the columns beside it, and the only way to see those themed is to put blocks in them. The blocks are built for the example rather than placed, so the page is the same on every site and nothing has to be placed to see it, but they are ordinary block render arrays in ordinary regions, so the aside, the region and the block markup are the ones the theme really outputs. A theme that declares neither region gets neither, and the page reads as an ordinary one-column page. The content is deliberately long: a sidebar only shows whether it scrolls with the page or stays in view once the content beside it is taller than the window.
Sidebar page and layout
The two sidebars on one page, which is how a page of a real site is usually built: a page sidebar on the left, outside the content and carrying the navigation of the library, and a layout sidebar on the right, inside the content region and carrying what this page is. Three columns, two of them sidebars, and only one of them belonging to the page. What the combination adds is that the second measurement depends on the first: the page sidebar takes its width out of the window and hands the rest to the content region, and the layout has to place its column in what is left rather than in the width of the window. That is where a layout that decides on a media query and a layout that decides on a container query stop agreeing. It also puts two thresholds in the way of narrowing the window rather than one -- the width where the layout folds its column, and the width where the page sidebar stacks and hands the room back -- and it is the only page where the two kinds of sidebar can be told apart by eye without switching tabs.
Content edit form
Content edit form with a body field using the Full HTML text format, and a body plain field using plain text.
User forms
The three forms a visitor meets on their way into a site: log in, register, and request a password reset. Each one reproduces the elements core builds for an anonymous visitor, so the markup matches the real page, but none of them authenticates, creates an account or sends a mail.
Ajax buttons
The markup ajax adds to a page, which no template holds until something is pressed: the five progress indicators, the throbber a select or a check box carries, the wrapper buttons add rows to and remove them from, the modal and off canvas dialogs, the messages a command hands to the page, and the error state an element is rebuilt in.
Hierarchical tableselect
The forms a tree is administered through, which are the two places a table lists a hierarchy: the terms of a vocabulary and the links of a menu. Three tables, because the shape takes two elements to build. The first is a real tableselect over a tree of terms, so the column of check boxes and the select all cell in the header are the ones the element builds, with a row selected, a row disabled and the indentation markers a row carries per level. The second is the overview form of a menu: a table whose rows are form elements, so each one holds the state of a link, its weight, its parent and an operations dropbutton, the whole table is draggable, and the check box column has to be built by hand because it cannot be asked of the element there. The third is the same element with multiple turned off, which is the picker: radio buttons instead of check boxes, no select all cell, and the rows a link may not be moved under disabled. Nothing is saved, and the trees are made up, so the page renders the same on every site.
Sidebar layout
The other kind of sidebar, and the one it is easy to confuse with the first: not a region of the page, but a region of the layout the content is laid out with, inside the content region and inside the same block as the body it sits beside. It is what an entity displayed through a sidebar layout renders as, so it holds what the thing is -- its state, what it belongs to, when it last changed -- rather than the navigation of the site. The layout is a real layout plugin, asked of the layout plugin manager and handed the regions it declares, so a theme that ships its own sidebar layout is the one being checked here; the core two column layouts stand in for a theme that ships none. Its regions hold field blocks, the wrapper layout builder puts around a field, because the space between two of them in a meta column is set on the block rather than on the field. The page fills no sidebar region, so the layout has the full width of the content region to work in.
Entity reference form
Content edit form with single and multiple value entity reference fields, rendered with each of the reference widgets: autocomplete, autocomplete with tagging, select list, check boxes/radio buttons, and the simple and complex inline entity forms. The values are dummy ones, so the page renders the same on every site.
Views exposed forms
The top of a view, in six combinations: a header on its own, exposed filters on their own, exposed sorts on their own, all of it at once with the reset and pager controls, grouped filters, and the sort links a table style puts in its header cells. Every variation is a real view, built in memory and never saved, listing the same dummy people rather than the content of the site. Nothing is queried, so applying a filter or a sort no longer changes what is listed; the widgets are here to be themed, and they still come back in the state they were submitted in. The exposed forms submit to this page and share its query string, the way several views on one page do, so applying one is visible in the others that expose the same identifier.
Demo
UI Examples demo.