- From: Sam Ruby <rubys@intertwingly.net>
- Date: Fri, 30 Mar 2012 07:21:08 -0400
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- CC: "public-html@w3.org" <public-html@w3.org>
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. > > 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). We are now consider the proposal to be withdrawn, and are marking issue 191 as postponed. - 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 Friday, 30 March 2012 11:21:33 UTC