`.
* There are format-definitions, which typically start with wording such as:
```html
A string is a
foo if it consists of...
```
or
```html
A
foo is a string containing...
```
These aren't algorithms per se, but they're wrapped in `
` by special dispensation.
* Even algorithms that appear in examples should be marked up.
Note that this list isn't exhaustive. There are things that are clearly algorithms that don't fit into any of the above categories. There are cases where it's unclear.
And it's possible that we'll change our minds about what should be marked as an algorithm.
### `
` and `var-scope`
For every `` element, one or more of the following should be true:
* It has the `ignore` attribute.
* It is within an element with the `var-scope` attribute.
* It is within an element with the `algorithm` attribute.
* It is within a `` element with `class="domintro"`.
The build process will complain if it finds an 'unscoped' ``, one for which none of the above is true.
Most of the time, any `` element that you introduce will be within a `` or a `
`. But for other cases, the question arises as to whether to mark a `` with `ignore` or mark an ancestor with `var-scope` (possibly creating a `` to have the `var-scope`). Here are some guidelines:
- When you have a set of consecutive algorithms that share variables, put `
...
` around the algorithms and any preamble that mentions the shared variables.
- In any context that has two or more `
` elements with the same variable-name, mark the context with `var-scope`, or put a `` around it, so that the `
`s will participate in var-highlighting.
- Even when a context has only single-use ``s, it can be easier (if there's enough of them) to mark the context `var-scope` rather than mark each `` as `ignore`.
- But if a context has only one ``, or two with different variable-names, probably use `ignore`.
But there's an additional situation in which to use `ignore`. In addition to looking for unscoped ``s, the build process will examine the ``s within each algorithm. Typically, a given variable-name will appear at least twice in an algorithm: once when it's declared/defined, and one or more times when it's used. So it's suspicious if a variable-name appears only *once* within an algorithm, and the build process will raise a warning about it. If you have a `` that should be ignored by this check, mark it with `ignore`.
### Common mistakes around prose style
Most of the style conventions in this section are covered by Infra or the WHATWG style guide, but the editors often have to correct them in contributions anyway.
- Use the [algorithm declaration conventions](https://infra.spec.whatwg.org/#algorithm-declaration) in the Infra Standard.
- **"If foo, then bar"** instead of "If foo, bar". [Example](https://github.com/whatwg/html/pull/10269#discussion_r1568114777).
- **"Abort these steps" vs "return"**: Use "return" to exit a whole algorithm or method. Use "abort these steps" to terminate a set of substeps or [in parallel](https://html.spec.whatwg.org/C#in-parallel) steps and continue at the next step in the "outer" procedure. See examples in [this section on parallelism](https://html.spec.whatwg.org/C#parallelism) and elsewhere throughout the spec, as well as https://github.com/whatwg/infra/issues/258.
- **Usage of positional, optional, and named[^1] (i.e., linkable) parameters**. Follow the [algorithm parameter conventions](https://infra.spec.whatwg.org/#algorithm-params) in the Infra Standard. In particular, use named/linkable optional parameters in your algorithm declaration when callsites pass in values for them while omitting earlier-positioned optional parameters.
- When **nesting 3+ conditions** in a list, the style should look like so:
```html
Foo.
-
If (all|any) of the following are true:
condition 1;
condition 2;
condition 3; (and|or)
condition 4,
then…
Baz.