The ins and del elements and comments thereon

<ins> and <del> were discussed by various people in various threads in 
over the past few years.

I haven't changed anything in the spec in response to these suggestions. 
As discussed below, the elements aren't used much. They are useful to some 
extent and not really causing any harm, but they aren't used enough that 
it would make sense for us to go out of our way to really fix them up and 
make them better (e.g. in the way that <h1> and <div> are used enough that 
it made sense for us to go ahead and introduce a bunch of sectioning 
elements to better handle those cases, or the way that JS toolbars and 
DHTML menus are used enough that it makes sense for us to introduce <menu> 
and <command>).


On Mon, 18 Apr 2005, Anne van Kesteren wrote:
> Ian Hickson wrote:
> > On Mon, 18 Apr 2005, Anne van Kesteren wrote:
> > 
> > > Now I know backwards compatibility is important[1], but DEL and INS 
> > > are insanely complex to use and do not cover all "edit" use cases.
> > 
> > Can you give some examples they don't cover?
> 
> Well, cases were you just want to note that something has changed, but 
> not necessarily want to "markup" what has changed.

Doesn't the title="" attribute cover this case well enough?


> > I'm aware of some, for example to mark a list item as deleted you can 
> > only mark the contents as deleted, not the item itself. But I don't 
> > see these as major enough changes to require changing the edit markup 
> > model.
> 
> Deleting the entire document would be another one of those...

410 Gone seems like the better solution for that.


> > > What XHTML2 does makes more sense to me (introducing a global 
> > > attribute) and also covers the use cases you see most online.
> > 
> > It looked to me like the use of an attribute in XHTML2 was actually a 
> > hack to get around limitations of DTDs and of CSS. HTML5's design 
> > isn't being constrained by either of those so I don't see why edit="" 
> > is better.
> 
> Well, XHTML is an XML language so it could make use of XML Schema or so 
> which is capable of describing the semantics of DEL and INS I believe, 
> although it would be a quite complicated schema.

I assume your opinion has changed. :-)


> |edit=""| is easier to use for tools that compare documents and only 
> want to say some content has changed. I have the feeling it is easier 
> overall, both to use when editing by hand and when code has to be 
> processed by tools, but I'm not sure if I can prove it.

I'm not really sure that this supposed ease outweighs the backwards- 
compatibility story.


> > > Now if you could say somehow that the contents of some element have 
> > > been modified
> > 
> > You can. Wrap those bits you removed in a <del> and wrap the new bits 
> > in an <ins>.
> 
> That information is almost never stored. It would also make software 
> insanely complex.

Wikis seem to handle this ok now... <ins> and <del> are more like what you 
would use on a diff page than on the final document. I'm not sure what 
problem we are really trying to solve here.


On Mon, 18 Apr 2005, Maniac wrote:

> Ian Hickson wrote:
> 
> > I'm aware of some, for example to mark a list item as deleted you can 
> > only mark the contents as deleted, not the item itself.
> 
> And you can't add an item as well...

Indeed, to add an item you have to do:

   <ul>
    <li><ins>...</ins></li>
   </ul>

...which I agree is suboptimal, but I think it's probably acceptable 
really. That is, the cost of allowing the other option is probably higher 
than the benefit gained from it. (e.g. it makes writing editors much 
easier if you know a list is only going to have list items in it.)


> > But I don't see these as major enough changes to require changing the 
> > edit markup model.
>
> I use <ins> and <del> for editing specs and this is in fact *is* a major 
> limitations. Speaking briefly: it is not possible to markup editis for 
> lists (orderd, unordered, definitions) and tables except for replacing 
> the whole list or table altogether.

Or bits inside each item/cell, sure. Tables in particular are a pain 
either way.


On Wed, 15 Jun 2005, Henrik Lied wrote:
>
> I agree with Anne here, I don't think this is a suitable usage-area for 
> INS and DEL. But instead of attaching attributes to the ARTICLE-element, 
> I think I would have done something like this:
> 
> <article>
> <p>Original, unmodified content</p>
> 
> <edit type="inserted" altered="{datetime type UTC}">
> <p>Inserted content</p>
> </edit>
> 
> <edit type="removed" altered="{datetime type UTC}">>
> <p>Removed content</p>
> </edit>
> 
> <edit type="modified" altered="{datetime type UTC}">
> <p>Changed content</p>
> </edit>
> 
> </article>
> 
> Of course, this would break backward-compability...

It seems to be like that would really be no better than <ins>/<del>.


On Fri, 17 Jun 2005, Jonathan Leighton wrote:
>
> I was talking to Anne van Kesteren[1] about this, and he suggested I 
> posted to the mailing list.
> 
> [1] http://annevankesteren.nl/
> 
> I think it would be sensible if detail was allowed to be omitted from 
> the datetime attribute. The HTML4 specification says[2] that "If a 
> generating application does not know the time to the second, it may use 
> the value "00" for the seconds (and minutes and hours if necessary)". 
> The WHATWG spec[3] doesn't say anything regarding what to do if detail 
> is not known or needed or wanted, but in my opinion detail should be 
> allowed to be left out. I'd like all the formats in the W3C note on Date 
> and Time Formats[4] to be permitted. Writing "00" when a value is not 
> known seems a bad idea to me because instead of telling the UA that the 
> value is not known, it tells the UA that the value is zero. Leaving the 
> value out entirely would save file size (albeit only a few bytes) and 
> the UA would be able to differentiate between an unspecified value and a 
> value of zero.
> 
> [2] http://www.w3.org/TR/REC-html40/types.html#h-6.11
> [3] http://whatwg.org/specs/web-apps/current-work/#datetime
> [4] http://www.w3.org/TR/1998/NOTE-datetime-19980827

I agree that this is an issue, but I'm not sure how to handle it. Leaving 
data out is all very well, but it means that we can't use (e.g.) the JS 
"Date" object to represent the data, as we really have to represent any 
time specified on the element as _two_ times now -- the start and the end 
of the period (or the middle and the error margin, or some such). This 
gets even more complex when you can't then express two times as a single 
time with missing precision (e.g. 02:00 to 03:00 is just "02", but what is 
02:00 to 02:30?). These problems I think would lead to issues in 
implementations that would then show up in markup as anomalies. I'm not 
sure the gain is worth that.

What's the harm in being over-precise?

I _have_ removed the concept of "00" meaning unknown. Now, all dates are 
(over-)precise moments in time.



On Fri, 17 Jun 2005, Mark Wubben wrote:
> On 6/17/05, Jonathan Leighton <turnip@turnipspatch.com> wrote:
> > That's the whole point -- HTML4 says if you don't know it then put "00",
> > I'm saying that if you don't know if don't put anything so that UAs can
> > distinguish a value of "00" from a value that isn't known.
> 
> I think it'd be better for the UA to assume a time of "00", than to 
> recieve a time of "00" and take it for a fact.

I'm not sure I understand the difference.


On Sat, 11 Mar 2006, Ivan Sagalaev wrote:
>
> In fact usefullness of <ins> and <del> is pretty limited anyway. For 
> example you can't add a row to a table or an item to a list since 
> neither <table> nor <ul> can't contain <ins>... Can this be helped 
> somehow?

For lists it probably could be helped, though at a cost. For tables I 
can't see any sane way to do it while still using <ins> and <del>.


On Sat, 11 Mar 2006, Anne van Kesteren wrote:
> 
> That could be solved using an attribute I guess, similar to "edit" in 
> some XHTML 2.0 proposal. Inserting and removing table cells on the other 
> hand...

The <ins> and <del> elements aren't really used enough to warrant adding 
yet more markup to handle their use case, IMHO.


On Tue, 29 Aug 2006, Michel Fortin wrote:
>
> (Note that everything applying to normal lists in this message could 
> also apply to definition lists and tables.)
> 
> The ongoing thread about a global href attribute versus a block-level 
> <a> element made me think of a similar situation concerning <ins> and 
> <del>. How can we markup removed or inserted list items? Here's a 
> general idea:
> 
>    <ul>
>     <ins><li>Some list item</li></ins>
>     <del><li>Another list item</li></del>
>    </ul>
> 
> But this is invalid. According to the spec the content model for <ul> is 
> "zero or more <li> elements".

    <ul>
     <li>
      <ins>Some list item</ins>
      <del>Another list item</del>
     </li>
    </ul>

...or:

    <ul>
     <li><ins>Some list item</ins></li>
     <li><del>Another list item</del></li>
    </ul>


> I'm not advocating any solution right now, but I think the spec should 
> be either changed to allow the above, or to add global attributes, or be 
> clarified to explicitly disallow <ins> and <del> surrounding list items. 
> Also, if links are to become applicable to block-level elements, I 
> suggest it follows the same model.

<ins> and <del> are defined to not be allowed in the above contexts; is 
that enough, or do you want an example showing how to use <ins>/</del> in 
lists (like the examples above)?


On Tue, 29 Aug 2006, James Graham wrote:
> 
> As a more basic question, how does anyone actually use the <ins>/<del> 
> elements? In their current form they are too basic to do worthwhile 
> revision control and specifying a generic solution that will meet all 
> needs seems challenging. I also know they can't be that widely used 
> since Hixie's survey [1] says:
> 
>  "Some of the more obscure cases of non-standard tags we found include a 
> series of tags with the st1: prefix, such as <st1:city>, and 
> <st1:placetype>, <st1:country-region>, <st1:state>, which we are told 
> come from Microsoft Office ("smarttags"). Those four tags are used more 
> often than the ins and del elements from HTML4" [2]
> 
> Clearly there are some situations in which basic revision control would 
> be useful but, even then, I'm not sure the revision semantics have value 
> beyond the boundary of the particular environment in which the document 
> is being edited - by this I mean that an aural UA, for example, could 
> not easily make use of an <ins> element in an arbitrary document, nor 
> could the googlebot (I suppose one could argue more strongly for the 
> <del> element). On the other hand an editing application, with support 
> for revision control could easily invent some solution using e.g. a 
> combination of custom classes. This will have the advantage that the 
> application can represent as much or as little information as it 
> requires (allowing for e.g. multi-level revision histories and extra 
> metadata about the change) and the disadvantage only that the semantics 
> are not recognised outside the application.
> 
> [1] http://code.google.com/webstats/index.html
> [2] http://code.google.com/webstats/2005-12/editors.html

Yeah; I think before we add more stuff to support <ins> and <del>, we 
should wait to see if anyone is able to use them, maybe in conjunction 
with custom data-* attributes and classes, to do something useful.


On Wed, 30 Aug 2006, Alexey Feldgendler wrote:
> 
> Probably, lists should implement a special DOM interface which allows to 
> iterate over the list items. Tables have such an interface.

Is there much of a need for that? Adding it just to handle <ins>/<del> 
seems... not good.


On Tue, 29 Aug 2006, Michel Fortin wrote:
> > 
> > <ul>
> >   <li><ins>Some list item</ins></li>
> >   <li><del>Another list item</del></li>
> > </ul>
> 
> The meaning of your markup is that you inserted and deleted some text 
> within each list item, not that you added or deleted a list item like in 
> mine. Semantically there is a difference, subtle maybe but still there.

Yeah, but, does it really matter?


> Also, while your markup gives the same visual rendering while using the 
> default browser stylesheet (which underlines <ins> and overstrikes 
> <del>), the result will be completely different if you want to hide the 
> inserted or deleted parts. Using this CSS rule:
> 
>     del { display: none }
> 
> you'll see a one-item list for my markup, while for your markup you'll 
> see a second, empty list item.

Indeed. I'm not sure this is a critical issue though.


On Wed, 30 Aug 2006, Ric Hardacre wrote:
> 
> Another related thought we could discuss for revision control using ins 
> and del is that they could do with a couple of attributes, a datetime 
> and an author:
> 
> <p>On a dull and dreary afternoon <ins datetime="2006-27-08 12:34:56" 
> author="Ric Hardacre">I added this text while</ins> the rain poured 
> down</p>

Well, datetime we have, but author we don't. It seems like you could put 
the author in title="" for now, though (or data-author="" if you are 
writing a custom tool that's going to use it.)


On Wed, 30 Aug 2006, Michel Fortin wrote:
> 
> The most convincing reason I've seen for keeping such an exception is 
> backward compatibility in a table context. While something like this 
> would make perfect sense to me as an indication that a new row was added 
> to a table:
> 
>     <table>
>          <tr><th>Some Header</th><th>Some Header</th></tr>
>          <tr><td>Some Data</td><td>Some Data</td></tr>
>     <ins><tr><td>New Data</td><td>New Data</td></tr></ins>
>     </table>
> 
> ... browsers just won't allow <ins> inside the table; they'll take the 
> <ins> element and put it just before the table in the DOM.

Yeah the above would be a disaster in text/html, as well as being a pain 
in the neck for CSS renderers.


On Thu, 11 Oct 2007, Henri Sivonen wrote:
> 
> http://www.w3.org/html/wg/html5/#cite3
> > The cite attribute may be used to specify a URI that explains the change.
> > When that document is long, for instance the minutes of a meeting, authors
> > are encouraged to include a fragment identifier pointing to the specific
> > part of that document that discusses the change.
> > 
> > If the cite attribute is present, it must be a URI (or IRI) that explains
> > the change. User agents should allow users to follow such citation links.
> 
> Currently, mainstream UAs don't interoperably fulfill the requirement of the
> last sentence quoted above. Therefore, as far as implementation goes, this
> counts as a new feature although the language feature is roughly a decade
> old[1].
> 
> Given that the language feature hasn't gained UA support in a decade, I think
> it is time to reassess the demand for the feature and how well the feature
> addresses the demand if there even is demand. See also[2].
> 
> [1] http://www.w3.org/TR/REC-html40-971218/struct/text.html#adef-cite-INS
> [2] http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/message/%3C44F4892E.9030404%40cam.ac.uk%3E

I'd rather leave cite="" in for now, and remove it at the CR stage if we 
can't get two complete implementations of HTML5 because of this feature. 
(Same applies to <q cite> and <blockquote cite>.)



On Mon, 12 Nov 2007, Daniel Glazman wrote:
> 
> I would like to come back to the ins and del elements. They are far, 
> very far from being the best solution for editing environments.
> 
> The most common example of that is a selection starting with a paragraph 
> and ending in the middle of a sublist item (see [ and ] in the prose 
> below):
> 
>    [<p>this is a paragraph</p>
>    <ul>
>      <li>list item level 1
>        <ul>
>          <li>list item] level 2</li>
>        </ul>
>      </li>
>      <li>another list item level 1</li>
>    </ul>
> 
> To delete the selection, you need three del elements, one being 
> block-level, the two others being inline-level (please note a li element 
> cannot be contained inside a del element, and it's painful...) :
> 
>    <del><p>this is a paragraph</p></del>
>    <ul>
>      <li><del>list item level 1</del>
>        <ul>
>          <li><del>list item</del> level 2</li>
>        </ul>
>      </li>
>      <li>another list item level 1</li>
>    </ul>
> 
> From an editing perspective, that's hell. Another solution used a lot in 
> SGML editing environments is called Paired Elements and it's able to 
> better represent the selection :
> 
>    <del id="foo" end="bar"/><p>this is a paragraph</p>
>    <ul>
>      <li>list item level 1
>        <ul>
>          <li>list item<del id="bar" start="foo"/> level 2</li>
>        </ul>
>      </li>
>      <li>another list item level 1</li>
>    </ul>
> 
> For people with enough SGML background, think IDREF.
> 
> That's harder to style but that's MUCH easier to edit, and the ins and 
> del elements are made to help/improve editing right ? In particular, you 
> don't have to care any more about the real caret's position when the 
> cursor is at the beginning of the sublist item. Is it before the del 
> element or at its beginning ? This question is the most severe problem 
> using del and ins elements in a wysiwyg editing tool.
> 
> I know it's kind of disruptive here but please consider paired elements 
> with two extra CSS pseudo-elements ::deleted and ::inserted. An API 
> allowing to know if a given DOM point (node, offset) has a deleted or 
> inserted status is also needed.

It seems like what you'd want is to convert lengths of <ins> and <del> 
elements into paired elements when loading an HTML file, have the editor 
work on those elements, and then reserialise such paired elements to <ins> 
and <del> elements on the backend. Wouldn't that be the best of both 
worlds? (The other world being backwards compatibility -- you'd need to 
support converting <ins> and <del> to the new format anyway, and 
reserialising it seems like the easy part.)


On Sat, 19 Jan 2008, Ben Boyle wrote:
> 
> http://dev.w3.org/html5/spec/Overview.html#prose1
> 
> This sentence:
> For the purposes of this requirement, del elements and their
> descendants must not be counted as contributing to the ancestors of
> the del element.
> 
> Is that last "del" a typo? Should it be something like this:
> For the purposes of this requirement, del elements and their
> descendants must not be counted as contributing to the ancestors of
> any element.

No? I don't understand what your porposed text would mean. The text in the 
spec is what I meant. I'm not sure how else to phrase it...


On Mon, 21 Jan 2008, Ben Boyle wrote:
> 
> Ok, yes, it's getting through to me. Still find it a bit of a tangled 
> description. Is the "ancestors of the del element" important? Perhaps in 
> the context of that paragraph it can be omitted in the interests of 
> simplicity and clarity, i.e. just say "del elements and their 
> descendants must not be counted" (as fulfilling the requirement for 
> prose content).

I think we want to be precise in these definitions, since there are going 
to be very few people reading them (basically only validator authors) but 
they are going to be amongst the most pedantic people we can find.


On Tue, 25 Mar 2008, Keryx Web wrote:
> 
> This is from Thomas Thomassen on WSG's list:
> 
> ------------
> I was working on some examples for the use of <del> and <ins>.
> http://www.thomthom.net/blog/2008/03/document-history-viewer-making-use-of-del-and-ins/
> 
> As I was working on this I wanted to mark up a list where items had been 
> added and removed. That's when I realised that you can't wrap up <li> 
> <dt> or <dd> in <del> or <ins> elements because <ul>, <ol> and <dl> only 
> allows list items as their direct child.
> 
> The <del> and <ins> then have to be wrapped inside the list item.
> 
> <ul>
>   <li>Item 1</li>
>   <li><del>Item 2</del></li>
>   <li>Item 3</li>
> </ul>
> 
> When I hid the <del> using display: hidden; the list would render 
> something like this:
> 
> * Item 1
> *
> * Item 3
> 
> Because I could wrap up the entire list item, the bullet point would 
> still remain.
> 
> To me it appears illogical to not wrap the <del> or <ins> around the 
> list items when you add and remove items to the list. I'm guessing it's 
> a case where every scenario wasn't accounted for when the specifications 
> was written. (Yes, I know that I could add an extra class to the list 
> item that I wanted to hide, but it's not the point. It shouldn't be 
> necessary.)
> 
> However, when this scenario presents itself I see it as fine to break 
> the specification and mark it up like this:
>
> <ul>
>   <li>Item 1</li>
>   <del><li>Item 2</li></del>
>   <li>Item 3</li>
> </ul>
> 
> This seem to render exactly as I expect it to do in every browser I've 
> tested.
> 
> * Item 1
> * Item 3

I agree with the sentiment. I'm not sure we can fix this though, 
especially while considering, e.g., editors.


On Wed, 26 Mar 2008, Tab Atkins Jr. wrote:
>
> I'm coming around to the opinion that <dl>, <ul>, and <ol> (and the new 
> list elements in html5) should allow a larger set of elements as their 
> direct children.  I've been playing around with <hn> within <ul> or <ol> 
> (with the intended semantics being that it's a header *for the list*), 
> as it provides a nice tight binding that makes it easier to style and 
> move around with CSS.  I could also use <section> or <div>, of course, 
> but my solution communicates exactly the semantics I want and nothing 
> else.

(<figure> is now available for this case.)


> Being able to wrap <li> (and the equivalents of <dt> and <dd>, etc) in 
> <ins> or <del> seems appropriate and useful, at least to authors that 
> actually use <ins> and <del>.  Note, though, that there is a slight 
> uncertainty about how <ol> should number in this case.  Luckily, the 
> browsers I'm testing this in (FF2, Opera9, and IE7) seem to treat things 
> in the most reasonable default way.  With default rendering, the <del>'d 
> part is treated as a proper part of the list and affects numbering.  If 
> you clean up the document by setting {display:none} on <del> and 
> {text-decoration: none} on <ins>, though, the list renumbers so that the 
> <del>'d list items are ignored in the numbering.
> 
> Since we have complete consistency between the major browsers (I just 
> haven't tested in Safari), it shouldn't be an issue to have this in the 
> spec.  At the very least, this would be appropriate for quirks mode, but 
> I see nothing wrong (and quite a bit right) with making it part of the 
> spec proper.

Do we really want to break the invariant that <ol> and <ul> always contain 
only <li>s, though? That seems like a big step to make, and one likely to 
break all kinds of tools.


On Thu, 27 Mar 2008, Henri Sivonen wrote:
> On Mar 25, 2008, at 21:44, Keryx Web wrote:
> > The <del> and <ins> then have to be wrapped inside the list item.
> > 
> > <ul>
> >  <li>Item 1</li>
> >  <li><del>Item 2</del></li>
> >  <li>Item 3</li>
> > </ul>
> 
> For various legacy parsing reasons and in the table case for CSS table 
> model reasons, this kind of thing is seriously more trouble for 
> implementors than it is worth. From an implementation cost/benefit point 
> of view, I am against allowing ins/del in more places.

That's my concern too.


On Fri, 28 Mar 2008, Keryx Web wrote:
> 
> Allowing list markup in tables seems to be a nightmare to spec and 
> implement - and teach! Ins and del in tables is no priority of mine 
> either.

I could imagine that it would be non-trivial to teach, yes.


On Fri, 28 Mar 2008, Tab Atkins Jr. wrote:
>
> Yes, if you have any insight as to why it is difficult, please share.  
> As it is, browsers (specifically, FF2, IE7, and Opera9) seem to handle 
> it just fine. 
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Ctitle%3EIns%2FDel%20within%20lists%3C%2Ftitle%3E%0D%0A%3C!--%0D%0A%3Cstyle%20type%3D%22text%2Fcss%22%3E%0D%0Adel%20%7B%0D%0Adisplay%3A%20none%3B%0D%0A%7D%0D%0A%0D%0Ains%20%7B%0D%0Atext-decoration%3A%20none%3B%0D%0A%7D%0D%0A%3C%2Fstyle%3E%0D%0A--%3E%0D%0A%3Col%3E%0D%0A%09%3Cli%3EOne%3C%2Fli%3E%0D%0A%09%3Cdel%3E%3Cli%3ETwo%3C%2Fli%3E%3C%2Fdel%3E%0D%0A%09%3Cli%3EThree%3C%2Fli%3E%0D%0A%09%3Cins%3E%3Cli%3EThree.5%3C%2Fli%3E%3C%2Fins%3E%0D%0A%09%3Cli%3EFour%3C%2Fli%3E%0D%0A%3C%2Fol%3E
> Note - this is obviously triggering 
> quirks mode.  FF2, in fact, refuses to style the <ins> and <del> 
> elements if you give the page a proper DOCTYPE. The other two browsers 
> seem to accept it just fine, though.

IE doesn't seem to handle that at all well.


> In DOM terms, both FF and Opera create a well-formed, identical tree.  IE
> does something... weird.  I don't really understand what's going on there in
> the DOM, mainly because I've never seen a red tagname before.  However, it
> obviously styles things correctly.  Note, though, that IE drops the tags
> when it displays the InnerHTML.  Odd.

Red tag names mean that the element has two parents.


On Wed, 2 Apr 2008, Matthew Paul Thomas wrote:
> 
> <ins>, <del>, and <mark> are the three cases I can think of where the 
> appropriate content model could be described as "roughshod" -- there's 
> no logical reason (other than ease of implementation) for any of them to 
> fit neatly inside the element hierarchy of the rest of the document.
> 
> For example, a couple of lines of an ancient poem might be interpolated 
> by an editor where insects had eaten away at the original manuscript, 
> and those insects had paid no attention to the HTML element hierarchy:
> 
> <p>
>   ...<br>
>   ...<br>
>   ...<br>
>   <ins>...
> </p>
> <p>
>   ...<br></ins>
>   ...<br>
>   ...<br>
>   ...
> </p>
> 
> Similarly an editor might insert extra sentences into the middle of a 
> paragraph, and therefore split the paragraph in two to prevent it being 
> over-long: <p>...<ins>...</p><p>...</ins>...</p>.
> 
> Conversely, she might remove text from two adjacent paragraphs, and 
> therefore collapse them into a single paragraph: 
> <p>...<del>...</p><p>...</del>...</p>.
> 
> And a highlighted portion of an essay or article can easily include 
> multiple paragraphs, and/or a whole paragraph plus part of an adjacent 
> paragraph. <p>...<mark>...</p><p>...</p><p>...</p></mark>
> 
> The real-world things that the <ins>, <del>, and <mark> elements 
> represent can all cross element boundaries at will, just like the text 
> selection in a Web browser can. But with the current (and all previous) 
> content models for these elements, those effects need to be faked using 
> multiple elements.
> 
> I don't know what use this observation is. Maybe it means <ins>, <del>, 
> and <mark> shouldn't be HTML elements, but should be something else 
> instead.

Like what? Making them something else sounds... expensive.

Not that I disagree with your reasoning. I think it makes a lot of sense.


On Wed, 2 Apr 2008, Daniel Glazman wrote:
> 
> Excellent post. I have to add that from a Wysisyg editor's perspective, 
> and I said it many times in the past, ins and del are almost the only 
> elements that are intrinsicly block-level AND inline-level.
> 
> In other terms, if you select the whole text inside a paragraph and 
> remove it, it is <p><del>foo</del></p> or <del><p>foo</p></del> ? 
> Discrimination is impossible, it's a nightmare.

Yeah. I think your earlier idea about making it ranges separate from the 
original markup makes a lot of sense for editors.


On Wed, 2 Apr 2008, Nicholas Shanks wrote:
> 
> I concur. Excellent summary of how these elements are not hierarchical, 
> but overlaid over the content of the document. The only way I can see to 
> have these in a well-formed DOM is by using empty elements for both the 
> start and end.
> 
> <p>…<ins-start/>…</p><p>…<ins-end/>…</p>
> 
> However, that said, I believe more strongly that the ins, del and mark 
> are metadata about the document, not specifically *part* of the 
> document, and as such, perhaps they need to be moved completely out of 
> flow, either into the <head> or into an auxiliary metadata file. They 
> are seldom used AFAICT, not being mentioned on [1], and I think there is 
> a valid reason for this lack of use which should be addressed. Are the 
> elements necessary in HTML, should the information they convey be 
> specified in another manner completely?
> 
> [1] http://code.google.com/webstats/

They're used enough that I think it makes sense to keep them for 
back-compat reasons. I'm not sure it makes much sense to develop them 
further, though.


On Wed, 2 Apr 2008, Tab Atkins Jr. wrote:
> 
> Nicholas Shanks, you may well be right.  <ins>/<del>/<mark> (idm) are a 
> form of embedded metadata, but how would we extract such out of the html 
> flow? This isn't metadata about the document, after all, but about 
> particular pieces of content within the document.  You can't even use 
> the dom to target it, since, as noted, idm properly aren't hierarchical 
> and can cross dom boundaries.
> 
> I like the paired-elements proposal, much better than my earlier ideas 
> of being able to wrap <li></li> in idm.  It gives you all the power of 
> idm while retaining a well-formed dom tree.  However, it's not ideal.  
> The stuff in the range is no longer targetable with CSS, frex.  We could 
> poke at CSS3 to have a new pseudo-element set for idm, but meh.

These are valid concerns too.


On Wed, 2 Apr 2008, Nicholas Shanks wrote:
>
> What is the benefit of the @start attribute on the ending tag? Shouldn't 
> the @end attribute be sufficient. I fear that if you let HTML authors 
> loose with something like this they'll end up with mis-matching pairs, 
> and while still able to create those (e.g. two start tags ending at the 
> same ID; or pointing to non-extant IDs) the surface area for error is 
> greater if the end tag has to be the inverse of the start tag too.

I don't think we'd really want to have the paired elements in the markup 
itself; as you say, they could lead to all kinds of weird meaningless 
markup. I do think the idea makes sense for editors, though; as mentioned 
earlier, the most logical behaviour as far as I can tell would be for an 
editor to convert <ins> and <del> markup to ranges on parsing, and to 
reinsert them when serialising. That lets the user (author) have a nice 
logical UI presented to him, while being compatible with existing content 
and UAs, without the editor having to deal with painful <ins> and <del> 
elements in the DOM.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'