- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Fri, 20 Jan 2012 16:02:40 +0100
- To: Paul Cotton <Paul.Cotton@microsoft.com>
- CC: "public-html@w3.org" <public-html@w3.org>, Steven Faulkner <faulkner.steve@gmail.com>
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