proposal for ISSUE-191: replace ins and del elements by an attibute-based solution

Le 08/12/11 19:53, Paul Cotton a écrit :

> ‘Replace/complement <ins> and <del> elements by a cleaner wysiwyg-safe
> attribute-based solution’
>
> Per the HTML WG Decision Policy, at this time the chairs would like to
> solicit volunteers to write Change Proposals for ISSUE-191:
>
> http://www.w3.org/html/wg/tracker/issues/191
>
> http://dev.w3.org/html5/decision-policy/decision-policy.html#escalation
>
> If no Change Proposals are written by January 21th, 2012, this issue
> will be closed without prejudice.
>
> Issue status link:
>
> http://dev.w3.org/html5/status/issue-status.html#ISSUE-191

Here is the proposal:

1. DIAGNOSIS
------------

It is well known among wysiwyg authoring tool implementors since the
end of 80's (I insist: 80's) that an element-based solution for
insertion and deletion is not enough. In the case of a content model
not allowing these elements (think ol/ul in html for instance), using
elements here require the use of the old mechanism of sgml inclusions.
One might object that not having <ul><del><li>foo</li></del></ul>
is not a problem but in fact it is. It is important to be able to
declare the whole list item has been deleted - and became non-editable -
instead of deleting its content and preserving the possibility to place
a caret before or after the <del> but still inside the <li>.

Implementors worked around the problem using proprietary attributes (for
instance versions of MS Word based on XML) or paired processing
instructions (various SGML/XML-based editors) to mimic the behaviour of
a text-only editor.

HTML4 introduced the <ins> and <del> elements and these elements survive
in html5. The original diagnosis still stand: the <ins> and <del>
elements cannot cover all the cases needed by the industry and represent
a viable solution only in source editing mode.

2. PROPOSAL
-----------

It is proposed to "deprecate" the ins and del elements, whatever is the
way to do it and switch to an attribute-based solution known to be able
to handle all cases, for both source editing and wysiwyg editing.

- @change attribute

   value: [ 'inserted' | 'deleted' ] [ 'reviewed' || 'to-be-reviewed' ]?

     the inserted value means the element and its contents were added to
       the original document
     the deleted value means the element and its contents were deleted
       from the original document
     the optional and exclusive reviewed and to-be-reviewed values mean
       the insertion and deletion have to be reviewed; the reviewer is
       described in human readable form by the contents of the @reviewer
       attribute

- @reviewer attribute

   value: Text

     an arbitrary value meaningful only when the change attribute
     contains the reviewed or to-be-reviewed value and meant to be
     displayed for human consumption ; can be for instance a name, a
     mail, a twitter id, etc.

- the @cite as currently defined in the html5 spec on ins and del
   elements

- the @datetime  as currently defined in the html5 spec on ins and del
   elements

With such a proposal the bogus case described in the diagnosis above

   <ul><del><li>foo</li></del></ul>

becomes the valid <ul><li change="deleted">foo</li></ul>.

Deleting a simple chunk of text 'foo' inside for instance

   <p>foo bar</p>

requires the insertion of for instance a <span>. But it already required
the insertion of a <del> element, so there is no extra cost here.

The conceptual model of insertions and deletions in html is not
changed and the new model allows source editing AND
solves the issues raised by ins and del in wiswyg environments.

The 'reviewed' and 'to-be-reviewed' values of @change and the associate
@reviewer attribute allow to establish a minimal workflow of changes in
a collaborative environment.

This solution or a very similar one is already implemented by multiple
vendors of the editing industry, including Microsoft, in editors based
on markup. It is simple to implement. It's trivial to implement for
browser vendors since it's only a question of UA stylesheet and no
specific browser-based behaviour is expected.

The proposal solves a 15 years old problem. Vendors stopped complaining
about it in the past mostly because the XHTML2 WG refused at that time
to deal with HTML4 errata. The absence of visible feedback in 2012 does
not mean the problem does not still stand. I think the proposed solution
is so simple it's worth seriously considering it.

</Daniel>

Received on Friday, 20 January 2012 15:03:14 UTC