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

On 02/28/2012 01:55 PM, Sam Ruby wrote:
> This proposal has a number of problems that need to be addressed before
> the chairs will accept it.

If these problems are not addressed by March 28th, we will consider the 
proposal to be withdrawn.

> For starters, it doesn't contain the required sections:
>
>
> http://dev.w3.org/html5/decision-policy/decision-policy.html#change-proposal
>
>
> Additionally, it is missing essential details (example: "whatever is the
> way to do it"). Finally it is missing rationale for some of the changes
> (example: @reviewer attribute or the 'reviewed' or 'to-be-reviewed'
> states of the @change attribute).
>
> - Sam Ruby
>
> On 01/20/2012 10:02 AM, Daniel Glazman wrote:
>>
>> 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 Tuesday, 20 March 2012 13:09:00 UTC