Rethink approach

[kaicataldo]

Now that this extension has been in existence for a bit, I'd like to discuss how we want it to work going forward. I wrote the initial code for this and therefore set the current direction we're on, but I'm having second thoughts about this approach. The big challenges with the current approach are:

1. The extension has to be aware of the DOM structure of the pages where it can work. This results in broken behavior when a site changes their markup and is a huge maintenance burden. I don't know how quickly we'll be able to respond to sites updating their markup, which could lead to a period of time in which the extension doesn't work. This doesn't seem sustainable from a maintenance perspective and unreliable from a user perspective.
2. Due to the above, adding support for new pages requires someone looking at the markup and figuring out how to make it work (which can be challenging when you're dealing with asynchronously loaded components). This means that users are quite limited in terms of where they can use this extension.

The solution I'd like to propose instead of the current approach:

1. Instead of finding specific textarea elements on specific pages, what if the extension worked on any textarea element on a given page? Rather than adding a button, we could take a few approaches:

2. Allow the user to specify a keybinding that will automatically format the text in a focused textarea element. This is how I personally would want to use it and I think is the simplest approach.

3. Automatically show a floating tooltip with a button on focused textarea elements (or maybe a dropdown that appears on the top right where the extension is visible). We would probably want to add a way for users to limit where these show up, which could be done by adding the ability to enable the extension for certain URLs as well as potentially for given classnames of textareas to look for. If this is configurable, users can use this extension anywhere.

Both of these solutions would allow us to completely forego the need to know the DOM structure of a page, as well as allowing users to use it wherever they want without us having to add support.

Thoughts? If folks are supportive of this idea, I can implement this and see what everyone things. :)

cc @lipis @nickmccurdy

[sibiraj-s]

Instead of finding specific textarea elements on specific pages, what if the extension worked on any textarea element on a given page?

I implemented #290 for Firefox, where we should be able to format any Textarea on the page (except those in iframe's), via context menu.

Chrome doesn't let us to identify elements where context menu is clicked hence it is not implemented. A Workaround has to be done

[Anita-ihuman]

The second option sounds great !! That way they can either choose to format or not

[nickserv]

This seems to be a duplicate of #20 and #21 but I'm in support of these ideas too.

[kaicataldo]

I'll try to find some time to implement something. I'd like to start with option 2, because I think it's the simplest approach, and will allow us to iterate from there if we feel like it needs a more robust GUI.

[nickserv]

Could we close this as a duplicate and track it in #20? Or would you prefer to keep it around as a meta issue? Or close #20 and #21 moving their requirements into here?

[kaicataldo]

I'm fine with having one issue! I'm not sure the other two issues are the same as this one, since they're additive. I'd really like to remove the current functionality because I think it's far too high of a maintenance burden. I'm personally not against leaving them all open for now.

[kaicataldo]

Apologies for the delay on my end. We had a death in the family and I'm slowly getting caught up.

[Anita-ihuman]

Oh I am sorry for your loss accept condolence