Bikeshed Documentation

Living Standard,

9. Definition Tables

Several types of definitions have well-established presentations, as a simple "key/value" table providing all of the details in a standardized format.

Bikeshed handles these specially, with a dedicated set of <pre class=xxxdef> blocks. The information in the block is presented in a simple line-based Key: value format, similar to <pre class=metadata>, and this is transformed into a standardized table.

All of the def tables look like this:

<pre class='propdef'>
Name: flex-basis
Value: content | <<'width'>>
Initial: auto
Inherited: no
Applies to: <a>flex items</a>
Computed value: as specified, with lengths made absolute
Percentages: relative to the <a>flex container's</a> inner <a>main size</a>
Animation type: length
Canonical Order: per grammar
</pre>

9.1. Arbitrary Def Tables

If you want to display your own key/value rows in a similar way to the built-in types defined below, you can use a plain <pre class=simpledef> block.

<pre class=simpledef>
first row: some info
second row: different info
second row: merged with the previous row
</pre>

will render as:

first row: some info
second row: different info merged with the previous row

Parsing is extremely simplistic:

9.2. CSS Property Tables

CSS properties are defined with a <pre class="propdef"> block.

Name, Value, Initial, and Inherited are all required.

All the other keys listed in the block above are optional. If left unspecified, they’ll be given a usually-reasonable default value:

All values are placed directly into the output HTML as written, so HTML tags, Bikeshed autolinks, etc can all be used as normal.

If defining a shorthand property, put a "shorthand" class on the block. This will change the block to only require Name and Value; Canonical Order is still allowed, but continues to default to "per grammar" as usual. All other keys will default to "see individual properties", which is usually all you need.

If adding some values to a property, rather than defining the property itself, put a "partial" class on the block. It will now require a New Values key, rather than Value, but is otherwise normal.

Additional keys beyond what is described here can be provided; they’re placed after all the built-in keys.

The end result looks like:

Name: flex-basis
Value: content | <<'width'>>
Initial: auto
Applies to: flex items
Inherited: no
Percentages: relative to the flex container’s inner main size
Computed value: as specified, with lengths made absolute
Canonical order: per grammar
Animation type: length

9.3. CSS Descriptor Tables

CSS descriptors (like properties, but for at-rules) have def blocks similar to, but simpler than, propdef blocks.

Name, Value, and Initial are required keys, just like propdef blocks. Additionally, For is required, giving the name of the at-rule the descriptor is for, like For: @counter-style. The rest of the propdef keys are not meaningful for descriptors.

Like propdef blocks, a "partial" class can be put on the block to indicate that you’re adding values to an existing definition; Name, For, and New Values must be provided.

While not technically descriptors, media features can be defined with this block as well, if an "mq" class is put on the block. It then only requires Name, For, and Value.

Additional keys beyond what is described here can be provided; they’re placed after all the built-in keys.

9.4. HTML Element Tables

HTML/SVG/etc elements can use a <pre class="elementdef"> block. (The content and presentation of this block is similar to that in the HTML standard, but is closer to that in the SVG standard.)

Additional keys beyond what is described here can be provided; they’re placed after all the built-in keys.

9.5. IDL Method Argument Tables

IDL methods can have their arguments defined & documented in a <pre class="argumentdef"> block:

<pre class=idl>
  interface Foo {
    undefined bar(long arg1, DOMString? arg2);
  };
</pre>

<pre class=argumentdef for="Foo/bar()">
arg1: here's the first arg
arg2: the second arg is different!
</pre>

The argumentdef block must specify what method the arguments are for in a for attribute on the <pre>. The contents of the element must then, on each line, list the argument name, a colon, then a description of that argument.

It will produce a table listing each argument, its description, and automatically contain its type, nullability, and optionality (determined from the IDL block), like:

Arguments for the Foo.bar() method.
Parameter Type Nullable Optional Description
arg1 long ✘ ✘ here’s the first arg
arg2 DOMString? ✔ ✘ the second arg is different!

Note: This automatically wraps the argument names in a dfn; this is meant to be the canonical location of the argument’s definition.

You can wrap the argument names in |var| syntax to also get a <var> around them, if you are placing the argument def within an algorithm block and want to highlight additional uses of it, like:

<div algorithm="Foo/bar()">
  <pre class=argumentdef for="Foo/bar()">
  |arg1|: Here's the first arg
  </pre>

  When a {{Foo}}'s <dfn method for=Foo>bar(|arg1|)</dfn> method is called:

  1. Do something with |arg1|.
  2. ...
</div>

← 8 Bibliography Table of Contents 10 WebIDL Processing →

CC0 To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 21 January 2026, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.