Share via

Preventing Automatic Hyperlinking in ContentEditable HTML

  • Article

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. https://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.

-Eric

Comments

  • Anonymous
    September 17, 2009
    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.

  • Anonymous
    September 17, 2009
    @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!

  • Anonymous
    September 18, 2009
    The comment has been removed

  • Anonymous
    September 20, 2009
    Another request: We can avoid editing a block with contentEditable=false. In this situation, the selection corners shouldn't allow to resize it.

  • Anonymous
    October 02, 2009
    The comment has been removed