Preventing Automatic Hyperlinking in ContentEditable HTML

Today, a question from the mail bag…

Q: Is there a way to stop IE from “auto-magically” recognizing and creating hyperlinks inside HTML?

First, a bit of context. Web developers can use the ContentEditable property to allow users to edit part of a HTML page. This mechanism is often used to allow users to edit “rich text” when composing a blog post, comment, or HTML email. Similarly, Client Application developers can use the same property when hosting the Web Browser Control (WebOC), again for similar purposes.

However, you’ll notice that if you type text that looks like a hyperlink (e.g. http://example or a@example) into the editable HTML region, the web browser will automatically convert that text into an active hyperlink. In many cases, this automatic conversion is desirable, but in some cases it may not be.

Client Application developers can call IOleCommandTarget::Exec, passing IDM_AUTOURLDETECT_MODE and a boolean value specifying whether or not automatic detection should occur. Unfortunately, this command ID is not mapped to a command identifier string which can be used when calling document.ExecCommand().

This means that, unfortunately, current versions of IE do not offer a way to disable automatic hyperlink recognition from script in the page. There’s no great workaround for this. Some web developers have pointed out that script may execCommand(Unlink) to remove all hyperlinks from the current selection, but this may not be desirable for all scenarios.


Comments (5)
  1. AlfonsoML says:

    Hi Eric

    Thanks for bringing this up. Do you think that it’s worth filing a feature request about this? (I mean: does it has any change of ever get fixed?)

    It’s a pity that although IE was the browser that created ContentEditable and brought all that wonderful power to the web it has let it slept, no improvements at all over the last versions, but with a little work it could improve several parts that would make it stand over the rest of the browsers clearly.

  2. @AlfonsoML: This limitation is definitely on our radar. Content-editing is becoming an increasingly important scenario for webdevs and users, so it’s definitely an area where we want to do better. If you have suggestions for other "little work" could be done to improve ContentEditable, please do let me know!

  3. AlfonsoML says:

    Ok, let’s go:

    When a resizable object is selected and the iframe is scrolled, the resizing handles are drawn outside the iframe.

    Load click on the picture so it’s selected and then scroll the editor. Now the buttons on the toolbar are below a ghost layer marked by the resizing handles.

    Related feature request: the ability to mark an object as non-resizable so the handles never appear for it (without the need to use onclick handlers)

    If the body of an iframe is marked as ContentEditable and it’s in Standards rendering mode, the body becomes collapsed, to get focus the user must click on the very first line, the only place where the cursor becomes a bean instead of an arrow.

    Several styles like width or height (sorry, I don’t know all of them by heart) applied to an element (div for example) turns the element into a special object, in order to edit its content the user must perform lots of clicks, double clicks and curses to make it work.

    Pasting might bring lots of garbage and old tags.

    A nice feature is being able to resize and edit a table as easy as Firefox

    Make the selection objects work properly so they don’t ever return an object in a document different than the one that requested it. (also execCommmands must be applied only on the document where it’s being executed, no matter if some text is selected in the outside frame)

    Resizing a picture by one of the corners should keep the aspect ratio.

    There might be other parts, little bugs that can be worked around, and of course big wishes that are too far away.


  4. AlfonsoML says:

    Another request:

    We can avoid editing a block with contentEditable=false. In this situation, the selection corners shouldn’t allow to resize it.

  5. Joshua says:

    Alphonso’s request to avoid all the double-clicking required to actually edit content within ‘special’ objects (which so for I’ve determined to be any block-level element in an iframe that has contentEditable=true set on the iframe) would be very helpful.  Again, take a page from Firefox which allows direct content editing just by placing your cursor in the block element and typing away.  

    Also, his request to allow the cursor to show in a contentEditable iframe upon clicking ANYWHERE in the iframe (and not just the first line) would also be very helpful.

    And finally, finding a nice way to make the "resize handles" an option on inserted tables and images would be helpful, instead of having them on all the time. While you can avoid the actual resizing via ‘onresizestart="return false"’, it would be nice to have the actual appearing of handles optional.

Comments are closed.

Skip to main content