Document Content Changes: INS and DEL

 [Note: in this mail I use all uppercase for element names simply to
  make them stand out in a plain text environment such as mail.
  Similarly I use the @attribute-name convention]

 Many things could be said to be wrong with HTML - but one of the
 details it got right was the INS and DEL element types. In a standard
 often said to be obscure and imprecise, theirs is a singularly clear
 definition:

   "INS and DEL are used to markup sections of the document that have
    been inserted or deleted with respect to a different version of
    a document (e.g., in draft legislation where lawmakers need to
    view the changes)."

 A use-case is even mentioned. XHTML 2 has not treated the need for
 document change markup as well:

   "Edit: rather than use explicit ins and del elements to mark changes
    in a document, an attribute edit may be used on any element for
    the same purpose." - W3C Editor's Draft 09 January 2009

 The example given for XHTML 2 is, quite frankly, rather horrid:

    <p>I will do it next <span edit="deleted">week</span>
       <span edit="inserted">month</span>.</p>

 Instead of

    <p>I will do it next <del>week</del> <ins>month</ins></p>

 We have, in the past, discussed the use of @role, and I have then, like
 now, stated that I am not wholly in favour of its use, but that I
 accept it when used to enhance, or refine, the semantics of existing
 elements.

 However: here we have a case where we take *existing semantic markup*
 and throw it out in favour of, in effect, a micro-format attached to
 meaningless elements. It's not a direction I, for one, see any
 particular point in taking. Subsequently I suggest we keep INS and DEL
 as is, and add the elements CHANGED and MOVED if required.

 If we do add these elements we need to do some extra work on them. As
 it is they are almost worthless - changed HOW? Or should we have two
 CHANGED with the different content in each? Moved WHERE? Use a HREF to
 point out where it was moved to? INS and DEL are nicely atomic; the
 others are far more fuzzy - and fuzzy ain't good.

 Bottom line: why should we throw out elements from HTML and XHTML 1.*
 which not only have explicit use-cases, but good definitions? I suggest
 we don't, but rather keep what works and fits with our design goals. In
 this case, specifically:

   "More usability: within the constraints of XML, try to make the
    language easy to write, and make the resulting documents easy
    to use"

 INS and DEL are certainly easier to write and use than the above SPAN
 example.

-- 
 - Tina Holmboe       siteSifter                  Greytower Technologies
            http://www.sitesifter.co.uk          http://www.greytower.net
      Website Quality and Accessibility Testing

Received on Saturday, 10 January 2009 18:24:45 UTC