Bug 13057 - Remove INS and DEL elements in favor of a new set of attributes
Remove INS and DEL elements in favor of a new set of attributes
Status: RESOLVED WONTFIX
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec
unspecified
All All
: P2 normal
: ---
Assigned To: contributor
HTML WG Bugzilla archive list
: TrackerIssue
: 17693 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-25 12:39 UTC by Daniel Glazman
Modified: 2013-02-12 19:56 UTC (History)
11 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Glazman 2011-06-25 12:39:43 UTC
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
Comment 1 Aryeh Gregor 2011-06-26 22:37:29 UTC
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.
Comment 2 Daniel Glazman 2011-06-27 05:39:20 UTC
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.
Comment 3 Daniel Glazman 2011-06-27 05:45:04 UTC
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.
Comment 4 Henri Sivonen 2011-06-27 06:34:12 UTC
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.
Comment 5 Daniel Glazman 2011-06-27 06:50:08 UTC
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.
Comment 6 Aryeh Gregor 2011-06-27 17:45:31 UTC
(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?
Comment 7 Michael[tm] Smith 2011-08-04 05:14:36 UTC
mass-move component to LC1
Comment 8 Daniel Glazman 2011-08-27 12:26:33 UTC
(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.
Comment 9 Ian 'Hixie' Hickson 2011-12-02 17:02:19 UTC
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.
Comment 10 Daniel Glazman 2011-12-02 17:22:22 UTC
(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.
Comment 11 Ian 'Hixie' Hickson 2011-12-02 18:15:24 UTC
You can either reopen or escalate. I'm assuming you meant to escalate.
Comment 12 Paul Cotton 2011-12-03 19:04:03 UTC
(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
Comment 13 Daniel Glazman 2011-12-07 16:38:28 UTC
(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"
Comment 15 Daniel Glazman 2012-01-20 15:06:28 UTC
Link to proposal for issue 191:

  http://lists.w3.org/Archives/Public/public-html/2012Jan/0106.html
Comment 16 Edward O'Connor 2013-02-12 19:56:24 UTC
*** Bug 17693 has been marked as a duplicate of this bug. ***