Base Stylesheets

Reset Stylesheets

Normalize Stylesheets

Classless Stylesheets

The rules of user-based styles

The styles of a webpage, any webpage, always begin with a browser stylesheet — a set of default CSS rules for HTML elements. It's inevitable. Google Chrome, Mozilla Firefox, and every other browser comes with one.

Without this sheet, development would have start from a screen with ghosts; a screen with invincible content. No color rules to differentiate foreground content from background space. No size rules to ensure a visible dimension.

With this sheet, the ghosts come alive; content becomes visible. You start to see things.

Developers, while having a safety net to build upon, must deal with the inconsistencies of styles across all browsers. The horrors of cross-browser compatibility.

Users, on the other hand, deals with poor readability of content. Nonetheless, they can personalize the page with their preference of color mode, font size, and font family. Poor but customizable.

Fair readability for users and inconsistent styles for developers are the banes of browser stylesheets.

Then comes reset stylesheets. It was popularized by Eric Meyer's reset.css in 2007. They flattens presentation styles of content. The ghost you now see looks like another. For one, headings are no different from paragraphs.

Developers get consistent styles across all browsers. In addition, it encourages the use of semantic elements. Devs can no longer, lazily, use elements based on their presentational style.

Users, meanwhile, get poor readability. Worse. It takes extra effort from developers to get that fair readability of browser stylesheet, if they need a doc page.

Poor readability for users and need for styles from developers are the banes of reset stylesheets. We trade fair readability for better consistency.

Then comes normalize stylesheets. It was popularized by Nicolas Gallagher's normalize.css in 2012. It preserves useful defaults and fixes the poor ones.

Developers get consistent styles.

Users maintain fair readability.

Fair readability, unfortunately, is still not enough. It is the bane of normalize stylesheets. Eyes have to sweep a long distance, depending on how wide the viewport is, to read a page. Sometimes, the eyes miss the next line to read.

Then comes classless stylesheets. Lexi Mattick's water.css is a popular choice since 2018. They prioritize better readability. Some classless stylesheet like magick.css strongly recommends using normalize.css.

Developers can get consistent styles.

Users get better readability, and, many a time, fair customizations that are more or less than browser sylesheets. Unfortunately, on poor semantics.

Fair customizations and Poor semantics are the banes of classless stylesheets.

Now comes Base.css, a base stylesheet by Toheeb Ogunbiyi in 2025. A 3 in 1: Base.css, the reset stylesheet; Base.css, the normalize stylesheet; Base.css, the classless stylesheet.

Developers get consistent and semantic styles

Users get better and customizable readability.

The ghosts are their best. Developers can use them as-is or build upon for web apps and web docs. Users can wave their magic wand to wear a different skin on ghosts.

Base.css

Introduction

The web's first multipurpose base stylesheet, with the most semantic rules, for complete customization and personalization.

Base.css is: first, a classless stylesheet; second, a normalize stylesheet; third, a reset stylesheet; and, fourth, every shit between those sheets. An all in one.

Through a mix of 13 properties, for customizations, developers can: reset or normalize a page for web apps, power readability of content for blog posts, and, as well, do both on the same page.

On top of developer's choices, users may personalize the aesthetics of the deployed page with a plugin like Elo.

Base.css is, by far, the most semantic classless stylesheet there is, so far. It's the only stylesheet that has unique styles for components. Verify by switching the classless stylesheets, with Elo, on the illustrations in the following sections.

Start using base.css in 2 steps:

Create a web page with semantic HTML

Link the stylesheet from a CDN, as shown below.

<link rel="stylesheet" href="https://unpkg.com/@toheeb/base/base.css">

Properties

Shape and Fill are the 2 fundamental design elements. Like a yin and yang, you need a fill to reveal a shape and you need a shape to have a fill.

Other design elements in the wild are color, space, form, line, texture, and so on; but, they are far-fetched.

Fill can be 3 things: a color, a blend of colors called gradients, or a free-form blend of colors called textures.

Shapes can be glyphs or objects. Glyphs are text characters while object are media characters. This object can, further, be 3 things: a dot if height and width are collapsed, a line if height or width is collapsed, or a form if in a 3-dimensional area.

In design, any kind of design, color is the basic type of fill. In web design, glyphs are the basic shapes of a page, not objects, since web pages are web documents.

Browsers, since time memorial, provide means to modify properties of glyphs like font size and font family. It stops at that. To modify other properties, you need a browser extension like Elo.

CSS, on the other hand, provides partial and indirect support for customizations. While CSS cascade down user's preferences of font size, it doesn't for font family. It takes some workarounds to ensure cascade from the document root. This cascade is needed for customization of design elements.

Font family

Given a page with no declaration for font family, content will inherit the user's preference from the browser settings. And, responds to user's changes.

The moment a webpage has, at least, a declaration, a thing developers do, it stops responding to user's changes in the browser settings. Nothing a user prefers that will supercede a developer's preference. This limitation only applies to the option via browser settings. It doesn't applies to extensions like Elo.

A font family declaration is a set of typefaces to create safer designs, not richer designs. Subsequent typefaces are fallbacks in case the previous typefaces fail to load.

To create richer designs, a design with mulitiple typefaces: 2, 3, 4, or any number, a developer need the respective no of declarations. Similarly, a user need the respective no of forms to change those declarations.

Using multiple typefaces requires a sound knowledge of type pairings. A knowledge many designers and developers suck at.

Rather than presenting multiple forms to users, delegating the nerdy task of type pairing to simple users who want nice pairing without any effort, we present one form for one typeface. A re-engineered typeface.

As of now, OpenType fonts can include alternate glyphs of some main glyphs. It takes CSS's font-variant-alternates property to choose preferred alternates.

Rather than having alternates of some glyphs, we'll have alternates of the whole glyphs. We'll have Many-in-one font. There'll be no need to look for nice pairs; it's baked in.

So, a font, for a script like latin, will have glyphs for characters (letters, puntuations, and numbers) in the following variations:

Class
- Space: monospace and proportional
- Type: sans, serif, and cursive
Axis
- Weight: thin (100) to black (900)
- Width: ultra-condensed (50%) to ultra-expanded (200%)
- Style: normal and italic
Cases: smalls, caps, and small caps
roles: caption, body, and display

One font becomes a font system. Users can choose a font, with all typeface variations, and have the webpage responds to the variations it supports.

Line Height

Line height distributes space around lines of text in a block. In the spirit of continuity, it should also manage that between blocks, and containers. In short, it should manage the vertical space of a document.

For cohesion within blocks, because of their differing sizes, line height decreases as the font size increases.

The lead that line height creates, a subtraction of one x-height from one line-height, on a basic block, paragraph blocks, becomes the base space unit. Not some arbitrary 4-point or 8-point grid unit. Afterall, glyphs, not objects, are the primary shape of a document.

Lead, together with a lead scale, creates an arithmetic sequence of space units for content gaps, and section margins.

When a block-level object media is at either start or end of a block, they impose a margin start or bottom to compensate for their lack of ascender space or descender space; respectively.

Line length

Line length caps content. It helps the reader's eyes flow easily from a line end to the start of the next line.

It caps blocks and mixes, not containers, to allow for multi-column content within containers.

The cap on mixes ensures markers and borders are beside their blocks.

On segments, at a screen width beyond the line length, an extended cap, an extension by one leading, makes their markers visually apply to all content, rather than the nearest block or mix.

On paragraph separator, a quarter cap conveys a thematic change. By quarter, or anything significantly less than 1 and more than 0, there's a visual distinction from partitions.

With a padding inline on landmarks, on root containers, all content get a breathing space to the inline edges of the viewport.

Color

Browser stylesheets come with color pallete for dark and light color mode out-of-the-box.

Developers can declare their support for either or both modes via a color-scheme meta tag in HTML or style property in CSS. To respect this support, developers must use light-dark() function to declare pallete rather than using the prefers-color-scheme media query.

Users, on the other hand, may choose their preferred mode via the browser settings.

Both users and developers can't theme the color pallete because browsers use named colors which are uncustomizable.

Customizable Color pallete builds on color components of color models.

CSS supports many color models. Human-based models such as HSL, HSB, HWB, and LCH are more intuitive than Computer-based models such as Hex, RGB, and Lab. They describe colors with components that aligns with how humans perceive and interpetes color.

Of the human-based models, LCH is the only choice for a customizable design. It has a perceptually uniform model. Users can change a component of a color and other colors in the pallete will adjust accordingly. Better still is OKLCH — an improved version of LCH. OKLCH uses Lightness, Chroma, and Hue components.

The primary color component is Hue. Lightness and Chroma creates variations. Variations for one hue is a monochromatic pallete; for 2 hues is diadic; for 3 hues is triadic; and so on.

CSS can programmatically create a live pallete from one hue using calc(). A 90deg deviation creates a complementary scheme; a type of diadic. Other deviations create as richer as possible of a pallete. A live and responsive pallete, based on one hue, thanks to OKLCH().

CSS has no native property for color hue, but an equivalent custom property works (--color-hue)

Styles

Styles are the differentiating factor. They are what makes a component look, feel, and sound distinct.

The web is filled with unsemantic styles: the absence of styles, the misuse of styles, the lack of unique styles. This can be seen through the lens of base stylesheets, as of writing.

None identifies landmarks, segments, preheading blocks, postheading blocks, and many other components. Absence of styles.
Some infer a navigation style on any list found within a nav element without ensuring its accessibility. Misuse of styles.
All use same styles on multiple components. Like same bold font weight on Title Phrase and Keyword Phrase. Lack of unique styles.

Blocks

All lead blocks, heading blocks and title blocks, are bolden to draw attention to their content.

Preheading blocks are inline-leveled to introduce as many taxonomies as possible without taking much screen space. Postheading blocks remained block-leveled as it buttress main headings.

Each heading group prompts a parent section that sit besides other parts called segments. Moreso, the root section prompts the main landmark that, also, sit besides other parts called landmark.

It takes lines to demarcate parts, and icons to distinguish those partitions. Same partitioning styles apply to some other components. For aesthetics purpose, landmarks use inline borders capped to one-half of the line length.

Sections use the same partitioning styles of windows to distinguish segments. All segments but heading groups and custom segments use no icons. Heading groups are uniquely identified by its bold heading block; custom segments are, well, custom to the developer.

In addition, sections use tier systems to relate their heading level and position.

A title's card, like a heading's section, is partitioned to separate leads from followers. Expecially, leads from sets of followers like we may have in a description item.

Yet, out of all 4 titles, only a detail's title and a fieldset's title influence the partition of their card.

Furthermore, a detail's title positions its marker outside of its block. Safe, because of the card's style, it wouldn't collapse on other markers, like a list marker if it's the first child of a list item.

All follower blocks, plain paragraphs and preformatted paragraphs, maintain normal font weight.

Unlike plain paragraphs, preformatted paragraphs use monospace font to preserve their semantics — preformats. If a proportional font had been used, it requires that same font to preserve any preformats.

Mixes

Mixes use all-round borders to define the boundary of their content — their mix of some title blocks, of any paragraph blocks, and of any mixes.

The border infers an inline padding to breathe space for content, and to create a margin area for markers of child mixes. This inline padding is balanced by the margin block start of the leading content and margin block end of the trailing content.

Most cards, cards without titles, except general cards, are iconified for distinction to similar cards like it were for windows.

The other cards, cards with titles or captions, including other mixes with titles, are partitioned like windows.

List layers use markers to identify their items. Ordered Lists use decimal leading zero, Unordered Lists use squares, definition lists use circles, Menu List use discs.

Illustration testing Mixes

Mix styles in the wild

Starting from the inline end of the title, a line runs, turn down, runs, turn right, runs, turn up, runs, turn left, and runs, around the content, to the inline start of the title.

With those lines, browser stylesheets ensure that a fieldset element contains its mix of content with a visible boundary.

Like browser stylesheets, most classless stylesheets use the same styles. Great!

Unfortunately, that style, the ability to see the borders of a mix of content is limited to only fieldset element. Some extended it to details element, like new.css and water.css, but none extended it to all mixes until Base.css.

With all mixes having borders, to visualize the boundary of their content, there's a need to test for space consistency with paragraph blocks — the sibling blocks of a mix.

It takes 3 samples of components to test for space consistency for all 2 boundary scenarios: a paragraph block, this paragraph, which has no borders; a fieldset card, which has partial borders because the title dissallows a full border at block start; and any other block, since they have all-round borders.

Fieldset title

This fieldset after a pararaph tests for the space between a no-border component and a partial-border component — one of two the boundary scenarios.

Besides, there's a test for a demarcation between the title and the content.

Details title

This details after a fieldset tests for the space consistency between two component with adjacent no-borders — two of the two boundary scenarios.

Besides, there's a test for a demarcation between the title and the content.

While testing for space consistency, we've provided 2 cases to test for demarcations within mixes. The other mixes worth demarcating are Figures, Tables, and Description Lists.

This caption is at the start of a figure. There should be a clear demarcation from the content it describes.

This caption is at the end of a figure. There should be a clear demarcation from the content it describes.

You should read a caption without having to scroll. If this table has no scrollbar, meaning you can't test the statement, force it. Force a scrollbar by reducing the viewport width untill one shows up.
1	6	11
Empty column should be visible without a stress. There's one after this column.	Similarly, empty row should be visible without a stress. There's one after this row.	The 4 parts of a table, this table, should be clearly demarcated. For example, with thicker lines.

Unlike caption, where its content should fit a viewport, content of a cell, or a span of cells, may spread across multiple viewports and that's unfortunately okay. Like this very paragraph

A dl item with 3 dd items:: You should be able to tell that this is the third of the dd items in this dl item.

Like dl, there are 3 other list layers. Marker type distinguishes them.

ol, no matter how deep, should use an unlimited list-type value. Like decimal; Unlike lower-roman.
1. ol, no matter how deep, should use an unlimited list-type value. Like decimal; Unlike lower-roman.

ul, menu, and dl, all lists with items in no particular order, no matter how deep, should use unique shapes for markers.

ul, menu, and dl, all lists with items in no particular order, no matter how deep, should use unique shapes for markers.

ul, menu, and dl, all lists with items in no particular order, no matter how deep, should use unique shapes for markers.
- ul, menu, and dl, all lists with items in no particular order, no matter how deep, should use unique shapes for markers.

List style type

ul, menu, and dl, all lists with items in no particular order, no matter how deep, should use unique shapes for markers.

List style type: ul, menu, and dl, all lists with items in no particular order, no matter how deep, should use unique shapes for markers.

The remaining mixes, mixes with no titles, no captions, no items, but not the custom card like this very card containing this paragraph, should be distinguishable even when with empty content. There are 7 below.

Mixes Rules

Use borders to mark the boundaries of all mixes.

With the presence of borders, add padding inline for space at inline ends,^a

Then, margin block of double --line-lead since border conceal ascender and descende space.^b The margin block on paragraphs act as padding block for the mix.

Redeclare: display of block to target transparent mixes;^c text-decoration of none for del and ins elements;^d and color for a elements.^e

For any second mix in a row, 2 bordered components, except fieldset whose title is not bordered, the margin top, for separation, is a triple --line-lead.^f

For dl, a padding top compensates the lack of a paragraph's margin top.^g
Position icons of mixes in the margin area of the mixes' parent, right under that of segments which is, also, under that of landmarks.
Partition cards

Separate caption from content in a figure.^a

Separate title from content in a fieldset or details.^b

Separate multiple titles and descriptions, respectively, in items of description layers.^c

Separate caption, heads, bodies, foots, and cells in a table layer.
Style list layers

Provide space to accomodate 3 digit markers.^a

Apply: decimal-leading-zero to ol, square to menu, disc to ul, and circle to dl.^b

Make marker size smaller to content size.^c

/* 1 */
ul,
ol,
dl,
menu,
figure, 
dialog,
address,
details,
fieldset, 
blockquote, 
a:has(:is(p, pre)),
del:has(:is(p, pre)),
ins:has(:is(p, pre)),
map:has(:is(p, pre))
{
  border: 
    calc(1px * var(--border-width))
    solid
    var(--border-color)
  ;

  /* 1a */
  padding-inline: calc(2 * var(--line-lead) * var(--border-width) / var(--border-width));

  /* 1b */
  margin-block: calc(2 * var(--line-lead));

  /* 1c */
  display: block;

  /* 1d */
  text-decoration: none;
}

dialog {
  margin: auto;
}

dialog::backdrop {
  background-color: color-mix(in srgb, currentColor 20%, transparent 100%);
  backdrop-filter: blur(1em);
}


/* 1d */
:is(
  ul,
  ol,
  dl,
  menu,
  table,
  figure, 
  address,
  details,
  fieldset,
  blockquote, 
  a:has(:is(p, pre)),
  del:has(:is(p, pre)),
  ins:has(:is(p, pre)),
  map:has(:is(p, pre)),
) + 
:is(
  ul,
  ol,
  dl,
  menu,
  table,
  figure, 
  address,
  details,
  blockquote, 
  a:has(:is(p, pre)),
  del:has(:is(p, pre)),
  ins:has(:is(p, pre)),
  map:has(:is(p, pre)),
) 
{
  margin-block-start: calc(3 * var(--line-lead));
}

/* 1f */
:is(p, pre) + fieldset:has(> legend)
{
  margin-block-start: calc(1 * var(--line-lead));
}

/* 1g */
dl
{
  padding-block-start: var(--line-lead);
}

/* 2 */
:is(
  figure, 
  address,
  blockquote, 
  a:has(:is(p, pre)),
  del:has(:is(p, pre)),
  ins:has(:is(p, pre)),
  map:has(:is(p, pre)),
)::before
{
  transform: translate(-3.2em, 1em);
  top: 4em;
}


/* 3a */

figcaption:first-child
{
  border-block-end: 1px solid var(--border-color);
}

figcaption:last-child
{
  border-block-start: 1px solid var(--border-color);
}


/* 3b */
legend,
details[open] > summary
{
  border-block-end: 
    calc(1px * var(--border-width))
    solid
    var(--border-color)
  ;
} 


/* 3c */

dt:not(:last-of-type)
{
  background-image: 
    linear-gradient(to right, var(--border-color) 0, var(--border-color) 2ch, transparent 2ch, transparent 3ch)
  ;
  background-size: 1ch 1px;
  background-position: left bottom;
  background-repeat: no-repeat;
}

dd
{
  border-block-start: calc(1px * var(--border-width)) solid var(--border-color);
  margin-block-start: calc(1 * var(--line-lead) * var(--border-width) / var(--border-width));
}


/* 3d */

table
{
  border-collapse: collapse;
  width: 100%;
  display: block;
  overflow: auto;
  margin-block: calc(2 * var(--line-lead));
}

caption
{
  display: block;
  border: 1px solid var(--border-color);
  text-align: start;
  position: sticky;
  left: 0;
}

thead
{
  border-block-end: calc(var(--border-width) * 2px) solid var(--border-color);
}

tfoot
{
  border-block-start: calc(var(--border-width) * 2px) solid var(--border-color);
}

th, td
{
  border: calc(var(--border-width) * 1px) solid var(--border-color);
}

th
{
  padding-block: calc(1 * var(--line-lead)) calc((1 * var(--line-lead)) + var(--lh-pad));
}

td 
{
  vertical-align: top;
}


/* 4a */
ol, 
ul, 
dl,
menu 
{
  padding-inline-start: calc(3ch * var(--border-width) / var(--border-width));
}


/* 4b */

ol {
  list-style-type: decimal-leading-zero;
}

menu
{
  list-style-type: square;
}

ul {
  list-style-type: disc;
}

dl > div
{
  display: list-item;
  list-style-type: circle;
}

/* 4c */
::marker
{
  font-size: .75em;
}

Phrases

Form phrases maintain their dimension within a line. Specifically, their block dimension within a line height to avoid line overflow. All except textarea forms which are, by semantics, multi-line forms. With borders, forms distinguish their input areas within a block.

Text Forms, like Picker Forms, use icons for labelling and consistency.

Beside Form Phrases are Media Phrases. Media Phrases can be Text Media or Object Media.

Except image media with a height of 16, a height to keep images flow inline with font size — like icons, object media use a block layout for maximum viewing experience.

Text Media phrasing computer outputs need a monospace typeface to preserve any space sensitivity. Other phrases inherit the block's typeface.

General Text, General code, and Text Media targeting machines and programs need no distinction from others. Those targeting humans do.

For unique styles, other Text Phrases use icons to delimit inline sides except for the following phrases with common styles:

strong, like other leads, use a bold weight.
mark related a highlights with a background color
del relate a deleted text with a line through.
ins signals inserted text with a solid underline
abbr relate an abbreviation with a dotted underline
var relate a variable with an italic font style.
sub relate a subscript with a reduced font size at the baseline
sup relate a superscript with a reduced font size at the capline
small relate an aside content with a redued font size
q and ruby maintain their quotes and positioning styles.

The rules of user-based styles

Introduction

Properties

Classless State

Reset State

Classless state

Font family

Font Size

Line Height

Heading Level 1

Heading Level 2

Heading Level 3

Heading Level 4

Heading Level 5

Heading Level 6

Line length

Color

Styles

Blocks

What's in a heading level?

The coming of the first subsection

The coming of the second subsection

Mixes

Phrases