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

On 01/20/2012 12:01 PM, Glenn Adams wrote:
> it would be nice to include a reference to a more fully elaborated
> refutation of ins/del, rather than simply asserting "it is well known
> ... since the end of the 80's"

I agree with the above, and will also note that the Change Proposal 
doesn't include an assessment of the impacts of this change.

The definition of what we expect from a Change Proposal can be found here:

http://dev.w3.org/html5/decision-policy/decision-policy.html#change-proposal

- Sam Ruby

> On Fri, Jan 20, 2012 at 8:02 AM, Daniel Glazman
> <daniel.glazman@disruptive-innovations.com
> <mailto:daniel.glazman@disruptive-innovations.com>> wrote:
>
>     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://www.w3.org/html/wg/tracker/issues/191>
>
>         http://dev.w3.org/html5/__decision-policy/decision-__policy.html#escalation
>         <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
>         <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 17:52:32 UTC