13057 2011-06-25 12:39:43 +0000 Remove INS and DEL elements in favor of a new set of attributes 2013-02-12 19:56:24 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED WONTFIX TrackerIssue P2 normal --- 1 daniel.glazman contributor ayg eric.sun hsivonen ian jonas kennyluck mike pcotton public-html-admin public-html-wg-issue-tracking rubys public-html-bugzilla oldest_to_newest 50311 0 daniel.glazman 2011-06-25 12:39:43 +0000 I have written a complete blog article [1] explaining why <ins> and <del> should be dropped. These elements just cannot be used as is by content editors for Visual Modification Marks. [1] http://bit.ly/mGYiP2 50332 1 ayg 2011-06-26 22:37:29 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: We only introduce new elements and attributes for extremely common use-cases, and there is no reason to believe this use-case is extremely common. The low uptake of <ins> and <del> is fairly strong evidence that they don't serve a very common need. As such, introducing new attributes to have a similar effect would waste implementer effort that could be better spent on more useful features, and further complicated an already extremely complicated language. Use-cases like this that are not extremely common are why we have extensibility points like class, data-*, and microdata. If the <ins> and <del> tags are a real problem for major WYSIWYG editors, I encourage them to innovate using existing extension points. If the feature is popular and successful, they can then report back on the results, including real-world cases where attributes are used successfully but <ins> and <del> don't work. At that point, if there's evidence of widespread usage of the extensions, it might be worthwhile to consider standardization. 50354 2 daniel.glazman 2011-06-27 05:39:20 +0000 This bug alone shows how rotten the HTML WG process is. Amazing. " The low uptake of <ins> and <del> is fairly strong evidence that they don't serve a very common need." HEY OF COURSE !!! The elements are not implementable and I proved it ! Did you really read my prose. In the meantime, *all* text editors (think M* Word or challengers) offer Visual Modification Marks. Not implementable as is in HTML. 50355 3 daniel.glazman 2011-06-27 05:45:04 +0000 Oh, and speaking of implementation, your comment is just stupid: there is nothing to implement in a browser, except possibly two CSS rules in a stylesheet. 50356 4 hsivonen 2011-06-27 06:34:12 +0000 Reopening. The rationale given for WONTFIX is a bad reason for *keeping* <ins> and <del>. It's a sensible rationale for not introducing alternatives. I suggest making ins and del inline-only (not removing them in order to avoid upsetting people who are using them as inlines on their blogs) and adding a common attributes for flagging any block as inserted. The default styling should probably be along the lines of outline-right: solid black 0.3em;. Personally, I'm unconvinced about the suitability of deletion tracking as an HTML feature. 50357 5 daniel.glazman 2011-06-27 06:50:08 +0000 Excerpt from section 3.2.3.8: "These attributes are not intended for use by software that is independent of the site that uses the attributes." Period. Not applicable in our case here. 50372 6 ayg 2011-06-27 17:45:31 +0000 (In reply to comment #4) > Reopening. The rationale given for WONTFIX is a bad reason for *keeping* <ins> > and <del>. It's a sensible rationale for not introducing alternatives. > > I suggest making ins and del inline-only (not removing them in order to avoid > upsetting people who are using them as inlines on their blogs) and adding a > common attributes for flagging any block as inserted. Isn't this "introducing alternatives"? What strong use-case is there for new attributes here? 53513 7 mike 2011-08-04 05:14:36 +0000 mass-move component to LC1 55912 8 daniel.glazman 2011-08-27 12:26:33 +0000 (In reply to comment #4) > Personally, I'm unconvinced about the suitability of deletion tracking as an > HTML feature. FWIW, deletion tracking is xml-based in word since 1998 IIRC... I am fine with HTML5 dropping INS/DEL if we can make an extra-spec about change tracking. But one thing is sure: the current INS and DEL elements are totally unusable as is. 60782 9 ian 2011-12-02 17:02:19 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Agreed with earlier comments that there isn't a strong rationale for a new feature here. I don't see much value in dropping <ins> and <del> though. Like with <samp> and other rarely used elements that we've kept around, they are relatively harmless. Also, I don't buy that they're impossible to use. They're quite easy to use, actually. "ins and del are, by definition, both inline-level and block-level elements." We don't have those terms anymore. They are simply "transparent", like <a>. "If in a Wysiwyg editor, you select the textual contents of a paragraph, turn on a "Visible Modification Marks" feature and hit the Delete or Backspace key, the editor has the option between <del><p>....</p></del> and <p><del>...</del></p>." That would be true of any edit description mechanism. "The user has no way to make a difference between the two but the two are NOT strictly equivalent. In the latter case, it is still theoretically possible to place the caret in the paragraph but BEFORE or AFTER the del element and insert new chars. In the former case, the whole paragraph is deleted and the user can't insert anything inside any more." This is not a particularly problematic difference. So what if some editors let you add text in a paragraph whose contents are all deleted and another editor only allows you to add a sibling paragraph? "In the latter case just above, it's impossible for the user to know if a caret placed at the beginning of the paragraph is before the paragraph, inside the paragraph but before the del element, or at the beginning of the del element." That's a generic problem with nested elements like multiple nested <span>s, and has nothing to do with <ins>/<del>. Word Perfect solved that problem in the early 90s with "view codes" mode. "much more importantly, ins and del cannot cover one trivial case : since there is no equivalent to SGML inclusions in XML, the following is impossible: <ul><del><li>a</li></del><li>b</li></ul>." The spec covers how to mark up deleted list items. "It is for instance totally impossible to mark an element as entirely deleted if the parent container's model does not allow the del element..." This does not appear to be a practical problem. You can just mark the child's contents as being deleted. 60791 10 daniel.glazman 2011-12-02 17:22:22 +0000 (In reply to comment #9) > "It is for instance totally impossible to mark an element as entirely deleted > if the parent container's model does not allow the del element..." > > This does not appear to be a practical problem. You can just mark the child's > contents as being deleted. ?!? This is entirely different and I don't think you read me well. This is the most important problem for content editors. <ins> and <del> as they are are ONLY useable in source code editors. I am then not satisfied by your answer because it leaves in the spec something that is known to be unimplementable in content editors, does not provide any solution for this feature. This feature should be deprecated/dropped, or shaped differently. It is well known by editor implementors since 1991 that the only plausible way to implement this feature is through attributes. I am then reopening this bug, and escalate it. 60813 11 ian 2011-12-02 18:15:24 +0000 You can either reopen or escalate. I'm assuming you meant to escalate. 60895 12 pcotton 2011-12-03 19:04:03 +0000 (In reply to comment #10) > I am then reopening this bug, and escalate it. Can you please "suggest title and text for the tracker issue"? /paulc 61096 13 daniel.glazman 2011-12-07 16:38:28 +0000 (In reply to comment #12) > (In reply to comment #10) > > > I am then reopening this bug, and escalate it. > > Can you please "suggest title and text for the tracker issue"? > > /paulc "Replace/complement <ins> and <del> elements by a cleaner wysiwyg-safe attribute-based solution" 61256 14 rubys 2011-12-08 18:45:22 +0000 https://www.w3.org/html/wg/tracker/issues/191 62937 15 daniel.glazman 2012-01-20 15:06:28 +0000 Link to proposal for issue 191: http://lists.w3.org/Archives/Public/public-html/2012Jan/0106.html 83030 16 eoconnor 2013-02-12 19:56:24 +0000 *** Bug 17693 has been marked as a duplicate of this bug. ***