W3C home > Mailing lists > Public > public-html@w3.org > January 2012

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

From: Glenn Adams <glenn@skynav.com>
Date: Fri, 20 Jan 2012 10:01:22 -0700
Message-ID: <CACQ=j+dYweg-w0P0XFn7e2CzYwcecKVQTeyS-k+Nw-MEJfDiWw@mail.gmail.com>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: Paul Cotton <Paul.Cotton@microsoft.com>, "public-html@w3.org" <public-html@w3.org>, Steven Faulkner <faulkner.steve@gmail.com>
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"

On Fri, Jan 20, 2012 at 8:02 AM, Daniel Glazman <
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:
> ------------
> 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.
> -----------
> 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:02:11 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:47 UTC