No Lacunae Values

A lacuna value is the value of an attribute or element that is used when that attribute or element is not specified, or when it is specified but its content is not understood by the language. This is different from a default value, which is what is used simply when an attribute or element is absent. For instance, if the x attribute on rect has a lacuna value of "0", then the value of x will be "0" for both <rect/> and <rect x="babe, like, you know!"/> whereas the default value would only apply in the first case.

In most cases however, if you're not the sort of person who enjoys showing off their knowledge of Latin plurals, talking of default values is more than perfectly fine. I didn't make this up though, it shows up in the SVG Tiny 1.2 specification. And the difference between only filling a gap when a value is unspecified and also falling back when it is erroneous is important enough that I don't mind you thinking me a pedant — which, chances are, you already did anyway.

Not specifying lacunae values will hurt error processing (and its cousin versioning), and lead to interoperability issues.

Imagine for instance that an author specifies the fill of a rectangle to be #99 instead of the intended #999 because of a typo. The processor can interpret that in several ways:

• Decide it's too big an error, and melt the motherboard.
• Realise it's wrong, and pick a default colour of its choosing (often black, but could be fuchsia).
• Pad with the last character, making it #999, with 0 (#990), or with something else that seemed to make sense while the implementer was rushing to finish so that she could go have a beer with the rest of her team.
• Throw it away, and apply a colour inherited from a fill attribute higher in the tree.
• Throw it away, and consider it null (transparent).
• Take the inherited colour, and only change the red and green components.

Most of the above will produce different colours. And since they'll produce different results in different implementations, there will be no interoperability. (The throwing up approach might sound appealing to XML heads, but as we will see later what is good at the syntax level is not necessarily as good at the language level).

The only solution is for each value to specify the behaviour when it is missing or in error. Not doing so is a great part of what created the HTML mess that we have today, and which is proving so painful to fix.