Let IAT work with input[type=text] fields as well

[docwhat]

I've gotten this request several times over the years, the latest being Alex.

The idea is that the "edit" gumdrop would appear on for <input type=text> elements as well as for <textarea> elements.

I took a quick stab at hacking the code, but its more than just changing a couple of lines of code. :-/

[viaa]

Hi,

Just to mention again that I would appreciate to have that feature added. I use vimperator and the ctrl-i feature did not work as well for me as "It's all text". I know there is pentadactyl where the ctrl-i may work better, but it is not available for the latest version of firefox.

Thanks,

Alex

[Hasimir]

A related content type to include with this feature request is the HTML5 contenteditable feature, often used in divs like this:

<div class="editable" contenteditable="true"></div>

The edited text would be inserted between the tags as normal for any SGML/HTML. Content types are generally determined by the site, so these days there's a lot of Markdown options (that sample is taken from ello.co and is their standard post thing). Obviously there are plenty of others and growing with the adoption of HTML5.

Now what would be really awesome would be a way of generating rules which IAT could use to adapt to specific sites, even if total support for all input types is infeasible. But grepping for "textarea" in the source code isn't enough to indicate where and how that might be achievable.

[docwhat]

I'm not sure that'll work... The reason is that most contenteditable elements usually have JS doing extra work and other magic.

For example, if a <section> is marked contenteditable then pressing return will create a new <p> node by default. However, you can override this via JS to create anything else; e.g. a <article> node.

There is no way to input things like lists, images, etc. without help from JavaScript.

It would be very easy to break some web-apps that don't expect the user to actually edit the underlying HTML without the JavaScript interpreting results.

Then there is the hidden <textarea> trick that a bunch of the contenteditable stuff uses, where there is a magic <textarea> hidden someplace that gets a stripped version of the markdown to be submitted. Or AJAX that saves things and flags problems, etc.

All in all, I don't think contenteditable is going to be really useful. That being said, I'm willing to take a look at a pull request and possibly add it as an "advanced" feature (requiring going into about:config to turn on). Enough people have asked that maybe someone will come up with something insanely clever, or it'll be worth it on a handful of sites.

If you decide to write this up @Hasimir, then ignore the about:config part, I can add that later... you'll want to take a poke at are:

• itsalltext.js:532
• monitor.js (search for textarea)

Basically, grepping the source in src/chrome for "textarea" and throwing out the comments is going to show you what you need to touch.

[Hasimir]

Ah, cool. Javascript isn't my forté, but I may be able to work it out or find some .js adept who can do so. Still, arcane rewriting stuff on a per site basis might be a bit of a show stopper. It can't, however, hurt to look and see. The worst that can happen is retaining the status quo, after all.