📃 These are primarily notes, intended to be a collection of useful fragments, that will probably never be complete in any sense.

Mobile usability / legibility

"Responsive"

viewport

Mobile-only CSS

There's a bit of a cheat with something like:

@media only screen and (max-device-width: 480px) { ... }

...because that's more or less the largest edge on the largest (thing they want to consider a) phone, and anything much larger starts being able to render as desktop pages - though tablets (and landscape mode phones) are a gray area there, and even touchscreen laptops can be. As can higher-resolution phones.

While it seems to be agreed that you should not target specific pixel sizes, there is no single consensus on what to do instead.

There are a lot of sensible hacks and valid-enough approaches, though

img srcset and sizes

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Wide browser support since roughly 2018 [1] (no IE).

srcset is a comma-separated list of either

url widthdescriptor

or

url pixeldensity

It allows the browser to be in more control of which image it fetches and shows, based on what kind of resolution it's running on / the window is at.

For example,

srcset="image1_14.jpg 140w, 
        image1_20.jpg 200w, 
        image1_48.jpg 480w,
        image1_80.jpg 800w"

The browser decides how it uses this information.

The main reason to use srcset is probably to cut bandwidth for mobile devices, while also having crispy high resolution version on desktop devices, without requiring scripting to do so.

There are other tricks you can use it for - e.g. have smaller images cropped on just their subject, while larger screens show more context.

It used to be that all browsers made this decision at load time, once, then rescaled it. Now, some (Chrome, FF) will made this decision again on window resize.

For backwards compatibility with non-supporting browsers, probably also set src.

Practical - resolutions

Pixel density means "choose this if you have at least this many device pixels per CSS pixel"

Basically, this makes it easy to specify "on devices with high DPI, use a higher-res image within exactly the same layout".

Right now this is primarily about retina displays and such, which to CSS have a lower logical resolution than the physical pixels it has.

This is confusing due to the way it CSS defines the pixel. You could read up, but it may make you grumbly, so you can generally just take a good stab at what amount of pixels and pixel density covers most cases (regular is roughly 150DPI, retina roughly 300DPI, so in generall a 1x and 2x is enough, though a 1.5x as well can be more flexible).

Which variant you specify in src as a fallback is up to you.

Notes:

If not specified, 1x is assumed.
having two entries with the same pixel density is invalid

In supporting browsers, if src is specified, is interpreted as a candidate with implied pixel density descriptor 1x

Things that can save a headache

CSS reset

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

The main reason that CSS resets are a thing is that browsers have some default styling when it comes to margin, padding, font-size, and more.

That's great to get a basic style on a page without having to declare all of it yourself, with some nice-looking whitespace rather than extremely cramped layouting - but the actual styling can vary between browsers.

If you mostly just cared about more consistent styling, then you will find yourself starting with a moderate list normalizing styles.

The most visible of which may be the body's padding and marging, form elements, list elements, and font style of heading elements.

Most of the rest is a lot

When the point is consistent styling, there are less dramatic, more controlled forms of that, see e.g. [2]

If you are going for pixel-precise layouting, then the above may not be enough.

There's stuff like that by default the body element has some margin on all sides, which is fine throwing some text in there, but will mess with precise width, particularly things that want to do 100% width / 100vw.

You may get frustrated and find yourself wanting to do things like:

* {margin:0;padding:0;}

Which is you saying you're starting from scratch, you're doing everything yourself.

Consistency without CSS reset

And yes, you can get consistent styling without CSS resets, by being specific enough.

In fact, there is a good argument that if you are mixing widgets from different sources, you should be that specific anyway, in which case there is no additional need for CSS resets.

* or long list?

You have probably noticed that CSS resets use a long list of most elements, instead of that *.

There seem to be a few arguments:

more attributes than margin and padding needs to be reset - and many of these are much more specific. Consider:

list styling applies to just a few elements

border-collapse: collapse is mostly specific to table

resetting line-height could be done just on body

It is both clearer (and a little less CSSOM work?) to make them only as specific as you need

* also selects form elements - which removes any native form styling, with no way to get that back later

long-list resets avoid doing that to leave that particular choice up to you.

* has lower precedence than a specific name

for resets that doesn't necessarily change things, but it's less confusing to eliminate precedence from the potential list of things to think about

anything you set in an all-of-these-elements selector will no longer be inherited (verify)

inherit is occasionally a really useful tool, so let's not effectively disable it up front

(note that this is also an argument against CSS resets at all)

But, more pragmatically

disagreements on what CSS resets are intended to do

most things you zero out will be overridden by you later anyway

CSS selectors

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Beyond the styling used in browsers, there are varied XML/HTML parsing libraries that allow selection of tags by using CSS selectors as queries.

See also XPath, which in some aspects looks rather similar (and allows parent traversal).

There have been better CSS cheat sheets out there for decades. These are the things I tend to have to look up myself.

Positional stuff such as the mostly ancestry-like terms like parent, child; ancestor

a b - descendant - b appearing anywhere under a (direct child, or deeper ancestor, all good)
a > b - child - b appearing directly within a

a + b - next sibling - b appears directly after a.

Note that it looks in one direction: after, not before

a ~ b - subsequent sibling - b appears anywhere after a at the same level

again, in one direction: after, not before, so e.g. div~div selects all but the first div at a level (verify)

a :only-child - selects whatever node there is under a, as long as there is just one
b:only-child - selects b only where it is the only node under its parent

a :first-child - selects whatever the first child under a is
b:first-child - selects b only where it is the first node under its parent

last-child and nth-child(n) analogous to first-child

nth-last-child analogous to nth-child but counted from the end rather than the start

Class

.classname

multiple like .header.red

mostly equivalent to [class~=class_name]

Attributes

[attribute] presence of attribute
[attribute=value] exact value
[attribute*=value] substring in value
[attribute~=value] value contains token in whitespace separated list (?)

e.g. a[class|="externalLink"] (robust to having other classes as well)

[attribute|=value] exactly str, or starts with str-

e.g. a[href|="en"] to match en, en-UK, but not english, energy

[attribute^=value] starts with

e.g. a[href^="https"]

[attribute$=value] ends with

e.g. a[href$=".pdf"]

Multiple tests could be done like

a[href^="https"][href$=".org"]

https://www.w3schools.com/cssref/css_selectors.asp

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Selectors

avoiding name clashes

Class names like header are asking for trouble if you ever merge page content with any other.

Even if you control it will on your site, you don't control others, and javascript plugins may create elements with such classes, and it's why many opt for id/class values that act as psuedo-namespaces, like appname-header.

If things are page-specific, you might also have some value in adding unique IDs to each page, so that you can do

body#about   div.section 
body#project div.section

This can also make sense when you want to allow templates fine control.

Avoiding anonymous descendant selectors

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

For example:

.details div { padding: .5em }

is problematic in that if you nest divs, each inherits its own .5em, and patching that up is a pain.

One way to day direct child is

.details>div  { padding: .5em }

...but in various cases, that inner div is also a meaningful one, so you may prefer:

.details div.section { padding: .5em }

...and generally rely on nested divs inherit a default (quite possibly 0px from your CSS reset).

Relayouting fun

Scrollbars

Browsers may only show a scrollbar on your page when necessary, which means that if the page changes its contents, the scrollbars may be added later, which means a relayout which makes the page jump. If you figure the scrollbars will typically be useful for your page, you can force them with:

html { overflow:-moz-scrollbars-vertical; }

On sizes

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

On units

Filling an area with an image

body height 100%

Some layouting compared

Basics and more classical layouting

Some attempt at overview

On float:

On hiding things

display

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

display:block

The default for things that should probably appear under each other (but position can change that)

such as div, p, h1..h6, header, footer, section

Defaults to full width(verify)

Useful for:

larger vertical sections

display:flex

See flexbox

display:grid

inline things

display:inline

The default for things that should flow with text, as if it were text

such as span, a, em, q, small, img (but see notes)

is sized automatically,

ignores width and height properties you set

basically ignores top/border margin and padding

Useful for:

selectively putting some things in text flow that wouldn't normally be

display:inline-block

Basically:

like inline (flows in text)

can be sized explicitly

respects height and width and such

respects top/bottom margin and padding

Useful for:

Getting things like buttons (particularly when they are styled links) to flow as blocks rather than just the text in them

But:

can mess with what you may consider regular text flow (particularly when sized)

display:inline-flex

display:inline-grid

display:inline-table

display:none

The default for things that should not be visible

such as head, script, style, title, link, datalist, area, param

No box is generated, so will not play in layout (See also CSS2/Controlling box generation)

display:initial

initial - reset back to defaults, as per specs(verify)

Useful when some broad things (e.g. CSS reset) set a few details you didn't really want.

Arguably mostly useful for exceptions.

display:inherit

display:unset

For inherited properties: behaves like display:inherit

For non-inherited properties: acts like display:initial

display:table (and friends)

display:list-item

display:ruby (and friends)

Ruby characters are those that are used only for annotative glosses, like how when teaching Japanese, there is often kana or romaji or over newly introduced (or all) kanji.

HTML5 and CSS is working on being able to use these, but as of this writing this is not fully finished, or supported

display:run-in

Run-in text is something like a header that is part of the first line of text.

layouting is aware it should be 'shown that way

can be semantically separate from the paragraph that follows

It's somewhat like a float-left, but is aware of text lines so won't do weird blocky things if sizes do not cooperate perfectly.

basically not supported - introduced years ago, but apparently the spec was not well received

position

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

position:static

Content is in normal flow.

A sequence of position:static elements will become a vertical stack.

position:relative

Content is shown offset to where it not using this would have put it (be it from normal flow or floats).

Does not change layouting; flow-wise this acts like static.

position:absolute

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Content is removed from flow - so no space is allocated in flow.

Positioned with offset to nearest non-static positioned ancestor

...and because everything defaults to position:static, for some isolated use of absolute, that will easily be relative to the document

so use of absolute is often either for document-relative things, or some fairly wel planned nested things

things inside it to the nearest (typically relative or absolute) positioned ancestor

Placed/offset with top/bottom or left/right,

Sized with more explicit width and height (verify)

Useful for

overlays, like a badge in the corner

that moves with the document

things like icons you want to stick onto other elements but should not take space / affect flow

SPAs sometimes do this to permanently section off the viewport in a way that will resize with the window, but never do a complex reflow.

but doing this with more than two rows/columns becomes a bit contrived, and these days there are better options

It' sometimes easier to e.g. say right:0 than to figure out what amount of width you've already used.

position:sticky

position:fixed

fixed can be seen as relative to the viewport, instead of the parent

A fixed element typically needs a top/bottom and/or left/right anchor, even if it's 0.

Used e.g. for overlaying things like a badge in the corner or whole-page progress bar, a footer that's always visible or anything else that doesn't moves with the document.

...some of which are finicky in that you e.g. need extra space above or in your actual document below so that such a fixed element won't block actual content

position:inherit

Tables

Newer

flexbox

flexbox tricks

Grid

multicolumn

Font choice

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

On fallbacks, and the concept of web-safe fonts

Generic font families are used to suggest an overall style:

serif (e.g. choice may be Times New Roman, Liberation Serif, etc.)
sans-serif (e.g. Arial, Liberation Sans, etc.)
monospace (e.g. Consolas, DejaVu Sans Mono, etc.)
cursive (e.g. Comic Sans MS, or something boring and serif)
fantasy (could be anything, really)

The actual font used is chosen by the client, which itself can depend considerably on what is present in the OS.

CSS font-family can take specific fonts, and it'll take the first that's there. Since we aren't very good at predicting what fonts are there, you

may want to list multiple fonts that look like each other.

should probably end with a generic font family (often serif or sans-serif)

keep in mind there may be more visual variation than you think. For example, sans-serif fonts can be divided into condensed (e.g. Arial, Helvetica, Tahoma) and wider (e.g. Verdana) fonts.

The idea of web-safe fonts is that a few fonts are present on most OSes, of various ages.

Arial (sans-serif) (Arial and Helvetica could be fallbacks for each other)
Helvetica (sans-serif)
Verdana, sans-serif {{comment|(less common on some unices?)

"Times New Roman", Times (serif)

"Courier New", Courier (monospace)

Impact

Modern fairly-safe choices

In that most modern, updated computers have them, varying a little with OS. You still want to use one of the safe choices as a fallback.

Palatino Linotype, Palatino (serif)

Tahoma (sans-serif)

Arial Black (sans-serif)

Trebuchet, "Trebuchet MS" (sans-serif) (less common on some unices?)

Impact (less common on some unices?) (also: fairly unreadable as regular-size text)

Comic Sans MS (less common on some unices?) (also: fairly unreadable as regular-size text)

Unsorted, possibly not safe

Lucida Console

Gill Sans

Myriad, Myriad Pro (sans-serif) - comes with various Adobe products, so most designers have it, but relatively few clients

Wingdings, webdings, Symbol (symbol fonts are mostly an IE hack(verify))

http://www.speaking-in-styles.com/web-typography/Web-Safe-Fonts/

@font-face

unicode-range

Glyph fallback

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

it seems browsers take glyphs from the first font in the list that has it.(verify)

unicode-range lets you say "use only this range"

which with some trickery lets you combine glyphs from different fonts

that is, you can e.g. define/alias a font, say 'take only this one character', and put it before all other fonts.

assume that
- browsers will delay loading loading fonts until more important things are satisfied
- browsers may not display anything while loading a font. Others will display fallbacks first

This matters in two ways I can think of

cases where this mixes glyphs from different fonts

cases where large fonts have to be downloaded

For simple western text, none of the configured fallback fonts may ever be loaded, so you may not see this in basic tests

If you have a generic family or web-safe font first, it'll probably cover more text faster - but less control over styling

looks can matter to the order you specify.

Something like unifont has a simple version for a *lot* of things. Which is useful as a final fallback, but it'll be uglier than most other fonts that have the glyph.

...but at the same time, putting it at the end for this reason may mean all the fonts on the way are downloaded, just to fall back to this one.

Services like Google Fonts can be nice

as a CDN-of-sorts for fonts

and it can be told serve a subset of glyphs from a large font.

If you have downloadable fonts (look for @font-face) in your font stack, you may as well first mention their name as if they are local fonts, for the few people who do have them installed, and fall back on the downloaded version.

Media queries

CSS-capable browsers will usually take:

CSS that applies to all media (all), which seems the default
CSS that applies when rendering to specific media (like screen, print, projection, handheld, braille, tv, and a few others.

Note browsers may not support more than a few. Normal browsers seem to do print and screen.

Generally, for-media styling is either done by putting most of your styling in the omniscient all stylesheet and exceptions in each specific media stylesheet, or sometimes by making (or auto-generating) full stylesheets for each medium.

Small screens

Printing

'print version'

You can, in theory, make a print version look completely different, but keep in mind that people will generally expect a print to look like the screen.

It's useful to remove things like navigation menus in print to save a little ink and make it look cleaner, but avoid going overboard.

Consider a 'print version' link, e.g. being a simpler on-screen version as well.

different sheets

One solution is to write a print layout from scratch, but it's often easier to add overrides, so that it mostly gets styled mostly the same way it normally would.

One easy way to do that is to add a print CSS file, that adds to the all sheet only when media is print:

 <link type="text/css" rel="stylesheet"               href="site.css" />
<link type="text/css" rel="stylesheet" media="print" href="print.css" />

With print.css probably containing rules like

making colored text black/white again (color:black) in case the browser doesn't and would try to dither-shade instead
removing background images (background:none)
removing or thinning borders and separators (border-color:black, and border-width:1px, etc)
removing elements like interactivity and menus entirely (display:none; visibility:collapse;)

The last e.g. via a noprint class and sticking that class on everything you don't want printed - or start from nothing and have a print class that you stick on the things you do want printed. Depending on which you have more of.

There are other styles of doing the same as the print-sheet import above, including

<style type="text/css" media="print">@import "print.css";</style>

and

<style type="text/css">
@import url("print.css") print;
</style>

other media-specific specification

You can import a particular stylesheet to apply to a specific medium:

You can also specify rules for specific media in inline css, such as

@media print { body { font-size: 10pt } }
@media screen { body { font-size: 13px } }
@media screen, print { body { line-height: 1.2 } }

You can't do it on elements, though; the best you can do is using a class.

Tricks

Lowering inline images

Inline icons and such often look a little too high. A class like like:

 .imglower { vertical-align: -15%; }

...often goes a long way.

Paragraph indenting

text-indent applies to only the first line, so to indent only the first line:

 text-indent:2em;

To indent everything except the first line (note that you can use lists to do the same thing), try tricks like:

 text-indent:-1.5em;  margin-left:1.5em;

overflow

The overflow (also separated into overflow-x and overflow-y) has four possible values:

visible: (default) content is not clipped
hidden: content is clipped
scroll: scrollbars are always added
auto: scrollbars are added only when there there is overflowing content (UAs have some choice, but that is the common behaviour)

whitespace behaviour like in <pre>

To get more literal whitespace treatment (newlines, spaces), set white-space:pre

You may also want to know about white-space:nowrap; it acts something like overflow:hidden.

image decorating e.g. a link

The following looks like the image is added as content:

.link-https {
  padding-right: 16px; /* assuming known image size */
  background: url(lock_icon.gif) center right no-repeat;
}

(trick stolen from mediawiki)

::before and ::after

Mostly used with content to create a pseudoelement, something that renders before the actual content, e.g.

div.prepname::after {
  content: "Name: ";
}

Or

.dquote::before { content: "«" }
.dquote::after  { content: "»" }

Acts like display:inline by default, but you can alter display:, position:, etc.

I've centered ::before text with something like:

div.specific::before { content:'text'; width:100%; text-align:center; position: absolute; top:50%; }

Note that since pseudoelements are not a regular part of the DOM, thy are not as easy to manipulate.

padding-margin-border-widths taking too much space?

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

For a long time, I'd try to use as few elements as possible, but run into the issue that

'width describes the width of the content box, and e.g. 100% takes 100% of the parent width

...so any added padding, border on the same element adds to that context box width, so will stick out, and no amount of fiddling with the content box percentage can fix that for small/large enough sizes.

The above behaviour describes box-sizing: content-box.

You may be interested box-sizing: border-box, which basically says "make width the total width", basically subtracting the padding and border from the content box size.

border-box is default on things like table, and most form elements.

content-box is default on things like div (and apparently most things?)

Both have their uses. The first is more practical if the contents have a known size (e.g. an image), the latter is more practical if the whole must have a fixed size, e.g. for layout elements.

Apparently you have to set a height, or the border will still act like content-box (verify)

Outlines

As an addition to the above, it is sometimes convenient to use outlines:

These are border-like things that take no space.

They are basically just drawn on top, so will easily run into content, and are less configurable than borders.

When using borders to show things like widget focus (but avoiding relayout), it can be simpler to use an outline rather than a border also using box-sizing:border-box.

outline

Per-page CSS in a single file

Sending CSS inline in a page each time can be a convenient way to control the scope at which that CSS applies, meaning you don't have to worry about collisions between short classnames.

However, centralizing CSS is useful, as you save some bandwidth if you avoid sending the CSS in each and every copy of the page. If you put it in a site's monolithic CSS file it will likely be cached too, meaning the CSS will load and apply faster.

A simple way to work around scoping problems is to manually create a scope per page by putting an id on each page's body. For example, a site's result.html could contain:

<body id="reshtml">

And the site css something like

#reshtml .header { }
#reshtml .results .row { }
#reshtml .results .row .name { }
/* ...etc */

text typesetting

text-align

text-align:

left
right
center
justify (often called 'justified' or 'full')
inherit

CSS3 will have a more detailed text-justify

line-height

Takes:

normal
inherit
a number, e.g. 2 for double-spacing or 1.5 for something less. (May be <1, but not <0)
a percentage (relative to font size(verify))
a specific length (e.g. in px or em)

word-spacing

letter-spacing

Cursor

auto (browser chooses)

default (non-special cursor; usually the arrow)

wait (often an hourglass)
text (select/edit I-bar, which is often the default on text)
pointer (often a hand)
help (often a questionmark)
crosshair

For interfaces:

move
e-resize, ne-resize, nw-resize, n-resize, se-resize, sw-resize, s-resize, w-resize

Non-standard (introduced in IE), not necessary supported:

progress (usually hourglass besides arrow)
all-scroll
col-resize, row-resize (think frame resizing)
no-drop, not-allowed (usually a circle with a bar through it)
url: an arbitrary image (one of the less supported ones, and there are varying extra browser-specific requirements)
vertical-text (rotated I-bar)

Quirksmode has a detailed list of what browsers support what cursor styles.

Vertical text

Semi-sorted

SASS, SCSS

Semantically Awesome Style Sheets (SASS), and often its SCSS (Sass Cascading Style Sheet), are basically a CSS-looking DSL that compiles to plain CSS.

It is more expressive, allowing things like:

nested syntax, is sometimes more natural than css selectors

reusing values through variable-like things

note that CSS3 has variables itself

reusing blocks of proprerties

@mixin and @include (note these can be parametrized)

or @extend (superclass style)

color-math like darken, lighten, saturate, complement [3]

@import is combined in the translation step, not a separate HTTP request as it is in plain CSS

also making it no-cost to organize large stylesheets into parts

deal with templates and predefined styles a little more flexibly

Less

Leaner Style Sheets (Less, sometimes LESS)

https://en.wikipedia.org/wiki/Less_(stylesheet_language)

https://lesscss.org/usage/

Strict mode, quirks mode

var()

the pain of vertical layouting

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Sometimes you want a-full-screen layouting instead of scrolling-because-of-variable-content.

While 'relative to screen sizes' exists, but 'relative to containing element' only exists in absolute measurements, not percentages(verify).

This means dividing the screen is very hard to do neatly (though there are workarounds for two or three elements, mostly consisting of abusing margins on one or both sides as positioning).

It also seems impossible to scroll nested things when needed (overflow:auto style) for containers that are not absolutely sized, while relative sizing will almost as a rule break layouting as percentage refers to page size, not container size. This can in some cases be worked around using - ironically - tables.

Also, 100%-ing height tends to not work well. If you want to do this, make sure you specify a height (probably 100%) at all levels (apparently because if some level computes to none, all children will too(verify)).

Depending on the case, this may be doable enough, or impractical.

Incidentally, the same seems to apply to max-height tricks.

These days there are also viewport height, which does not require the size to be set throughout the tree.

box model

Refers to the way box sizes are calculated/rendered; see e.g. [4].

IE for a long time did not fully comply to those specs (they basically couldn't in the initial implementation of their rendering engine), and (for backwards compatibility) still does not do so in quirks mode.

Box model:

Images

CSS sprites

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

CSS sprites refer to using an image file to contain more than one logical image. Think, for example, of having an image store the normal, rollover, and clicked state for a starring system, button, or similar.

The largest upside is that you can store many buttons/states in a single file, reducing the amount of images that will have to be loaded for a web page, and thereby the load time through lag, apparent load time, and avoid things like late-loading hover states (although pre-loading images is not very hard either).

In the case of CSS, you include the same file repeatedly, an use styling (width, height, ) to create viewports of sorts so that each use actually shows the sub-image you want. This is usually done by exploiting the background property, specifically for background-position [5].

Preloading images

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Image preload means that page items aren't randomly visually fast and slow to respond.

Common methods:

One common way is to pre-load images by using <img> tags that are not displayed. There are various ways of doing this, such as:
- display:none on the images, or on a div around a few images, etc.
- position a div containing img tags outside the window, and overflow:hidden on the containing element to avoid scrollbars
- use background: with the transparent color, the image, no-repeat, and a position that means the image will not be visible.

Alternatively, you can use javascript. Preloading scripts often do the invisible DOM element thing, but can choose to delay it until after the page has loaded, to avoid slowing down the initial load. A downside is that it means that the paranoid script-disabling crowd will get no preload.

You usually want to stick pre-loading on the end of your page (elements at the end of the body, or onload scripting), since you probably want to minimize the effect on the initial load time. You're likely loading images that are only necessary for later interaction, and have enough imagery for the initial load anyway.

Layouting and CSS notes

Mobile usability / legibility

"Responsive"

viewport

Mobile-only CSS

img srcset and sizes

Practical - resolutions

Things that can save a headache

CSS reset

CSS selectors

avoiding name clashes

Avoiding anonymous descendant selectors

Relayouting fun

Scrollbars

On sizes

On units

Filling an area with an image

body height 100%

Some layouting compared

Basics and more classical layouting

Some attempt at overview

On float:

On hiding things

display

display:block

display:flex

display:grid

inline things

display:inline

display:inline-block

display:inline-flex

display:inline-grid

display:inline-table

display:​none

display:initial

display:inherit

display:unset

display:table (and friends)

display:list-item

display:ruby (and friends)

display:run-in

position

position:static

position:relative

position:absolute

position:sticky

position:fixed

position:inherit

Tables

Newer

flexbox

flexbox tricks

Grid

multicolumn

Font choice

On fallbacks, and the concept of web-safe fonts

@font-face

unicode-range

Glyph fallback

Media queries

Small screens

Printing

'print version'

different sheets

other media-specific specification

Tricks

Lowering inline images

Paragraph indenting

overflow

whitespace behaviour like in <pre>

image decorating e.g. a link

::before and ::after

padding-margin-border-widths taking too much space?

Outlines

Per-page CSS in a single file

text typesetting

text-align

line-height

word-spacing

letter-spacing

display:none