This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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.
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.
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.
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.
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.
(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?
mass-move component to LC1
(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.
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.
(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.
You can either reopen or escalate. I'm assuming you meant to escalate.
(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
(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"
https://www.w3.org/html/wg/tracker/issues/191
Link to proposal for issue 191: http://lists.w3.org/Archives/Public/public-html/2012Jan/0106.html
*** Bug 17693 has been marked as a duplicate of this bug. ***