Vernacular

HTML Made Special

Inconsistency

There are many ways of being inconsistent. They will all tend to hurt your users in different ways.

Inconsistent naming will make it hard to remember which is what, and will cause subtle bugs when processing software looks for the wrong information. This is one of the simplest to get right and yet is often wrong as the result of things being specified on the fly and not revisited later. The typical example is SVG having circle, path, ellipse, etc. but rect instead of rectangle. It does make a language harder to learn.

Incoherent features are harder to spot because they tend to happen when people use your ideas in unexpected ways.

A good example is the different treatment applied to shapes and animations in SVG. The following will work and display a second rectangle inside the g.

<svg ...
  <defs>
    <rect ...="" id="dahut"></rect>
  </defs>
  <g>
    <rect x="10" y="42" ...=""></rect>
    <use xlink:href="#dahut"></use>
  </g>
</svg>
      

But the following, while valid, will not cause the g element to be animated:

<svg ...
  <defs>
    <animatetransform ...="" id="dahut-anim"></animatetransform><
  /defs>
  <g>
    <rect x="10" y="42" ...=""></rect>
    <use xlink:href="#dahut-anim"></use>
  </g>
</svg>
      

Instead the defs will be animated, which will do nothing. This sort of discrepancy confuses authors, many of whom will try the latter at some point. There is no silver bullet to get rid of such issues; the best you can do is that, whenever you add a new construct to your vernacular, either constrain it to places where you can ascertain its behaviour, or, if it is meant to be used in arbitrary locations try to go through the entire rest of your language and to imagine how it would interact with each construct.

Note that while this is most easily exemplified with behavioural features, it applies just as well to semantic ones. The many ways in which one can create bogus, meaningless data will often boggle the developer’s mind.

↖︎ Back to list