- From: Sam Ruby <rubys@intertwingly.net>
- Date: Tue, 28 Feb 2012 13:55:28 -0500
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- CC: "public-html@w3.org" <public-html@w3.org>
This proposal has a number of problems that need to be addressed before the chairs will accept it. 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, 28 February 2012 18:55:56 UTC