# HG changeset patch
# User Henry S. Thompson <ht@markup.co.uk>
# Date 1497280824 -7200
# Node ID 95faecfcc1b5575a63ffc768d4bf3adf49ef370d
# Parent  b66bcfae65d63b75893eb171bdbd0343c6d0a178
consistent defn style

diff -r b66bcfae65d6 -r 95faecfcc1b5 annotate.html
--- a/annotate.html	Mon Jun 12 17:20:14 2017 +0200
+++ b/annotate.html	Mon Jun 12 17:20:24 2017 +0200
@@ -98,13 +98,20 @@
 menu (allowing multiple selection in the array-valued case), but features with
 dictionary values will require cascading sub-forms.</p><p>The next two sections document the annotator-supplied and
 software-supplied features.  Except for 'comment', whose value is free text,
-allowed values are tabulated.</p></div><div><h2>3.  Annotator-supplied features</h2><div><h4>3.1.  All types</h4><dl class=" "><dt><b><a name="comment">comment</a></b></dt><dd>string: unconstrained.  By its nature difficult to
+allowed values are tabulated.</p></div><div><h2>3.  Annotator-supplied features</h2><div><h4>3.1.  All types</h4><ul class="naked  "><li><a name="comment"><b>comment</b></a>
+&#160;&#160;string: unconstrained.  By its nature difficult to
 exploit, really should only be used to document a problem with the available
-feature&amp;value vocabulary or structure.</dd></dl></div><div><h4>3.2.  Both one-dimensional types</h4><dl class=" "><dt><b><a name="type">type</a></b></dt><dd>string: <code>"data"|"key"|"label"</code><p>"key" is my preferred word for what Dresden call "attribute".  In the
-simpler cases, think of it as what you might use in an HLOOKUP or VLOOKUP cell.</p></dd><dt><b><a name="content">content</a></b></dt><dd>fvd:
-      <dl class=" "><dt><b><a name="type">type</a></b></dt><dd>string: <code>"currency"|"date"|"datetime"|"integer"|"float"|"key"|"label"|"string"|"time"</code></dd></dl><p>The "key" and "label" content types are for use (as in the Dresden
-paper example) where compound keys/labels are indicated by row or column spans.</p></dd></dl></div><div><h4>3.3.  Matrices</h4><dl class=" "><dt><b><a name="type">type</a></b></dt><dd>string: <code>"table"|"data"|"label"|"condition"</code></dd><dt><b><a name="content">content</a></b></dt><dd>fvd:
-      <ul class=" "><li>string: <code>"rows"|"columns"|"cells"</code></li></ul></dd></dl><p>When a form for a matrix is completed, if <code>type</code> is 'data' a pop-up should offer to auto-fill
+feature&amp;value vocabulary or structure.</li></ul></div><div><h4>3.2.  Both one-dimensional types</h4><ul class="naked  "><li><a name="type"><b>type</b></a>
+&#160;&#160;string: <code>"data"|"key"|"label"</code><p>"key" is my preferred word for what Dresden call "attribute".  In the
+simpler cases, think of it as what you find as the first row/column of the 2nd argument to an HLOOKUP/VLOOKUP call.</p></li><li><a name="content"><b>content</b></a>
+&#160;&#160;fvd:
+      <ul class="naked  "><li><a name="type"><b>type</b></a>
+&#160;&#160;string: <code>"currency"|"date"|"datetime"|"integer"|"float"|"key"|"label"|"string"|"time"</code></li></ul><p>The "key" and "label" content types are for use (as in the Dresden
+paper example) where compound keys/labels are indicated by row or column spans.</p></li></ul></div><div><h4>3.3.  Matrices</h4><ul class="naked  "><li><a name="type"><b>type</b></a>
+&#160;&#160;string: <code>"table"|"data"|"label"|"condition"</code></li><li><a name="content"><b>content</b></a>
+&#160;&#160;fvd:
+      <ul class="naked  "><li><a name="type"><b>type</b></a>
+&#160;&#160;string: <code>"rows"|"columns"|"cells"</code></li></ul></li></ul><p>When a form for a matrix is completed, if <code>type</code> is 'data' a pop-up should offer to auto-fill
 based on <code>content/type</code>.  If chosen, this fills the matrix with
 named ranges of the appropriate orientation (rows, columns or, in the case of
 <code>cells</code>, both).  If