This looks nice, but I'm not sure about it functionally, and about the amount of JS it would potentially require vs the improvement it would provide.

Can we style a real <select /> like that, or would we have to implement an element in JS? (I don't think we can colorize options in a <select />.) I'm a bit hesitant about replacing a <select /> with a JS element here because it's used heavily and we'll either lose functionality (tab focus, keyboard navigation) or need to spend a significant amount of time rewriting it in JS.

(We've swapped some other elements for JS (notably, policy controls), and the tradeoff is more reasonable there because they're rarely used and a <select /> can't do the job, but I still find it annoying when they don't respect tab order or react properly to keyboard input.)

With actions, move submit button to left (keeps clicking and focus in a much tighter area)

This seems inconsistent (every other submit button in the product is on the right?) and not very valuable? Does this solve a problem?

hints below

This also seems inconsistent with other elements in "real" editors (Word, Google Docs), and other text editors on the web. Is this mostly to get the "Action" closer to the text?

(The majority of remarkup boxes do not have a submit button and do not have any actions. Doesn't it make these just worse?)

I also worry that this makes commenting a little more confusing, because the element looks more like a transaction, and the action looks more like a header. Users occasionally have difficulty figuring out how to take actions, even with the action form being huge and explicit and very form-like with a clear "action" field.

We also have actions which are not typeaheads, like "Close Task" in Maniphest, where you select a status. Since sub-controls on actions must now fit next to the "Action" dropdown, I worry this reduces flexibility or increases cost -- form elements must be tailored to look good and work in this context.

It definitely looks nicer, but seems to make the UI inconsistent in service of primarily aesthetic goals to me, and possibly regress usability. What are your overall goals / what problems are you solving, beyond the current element being kind of ugly?

To back up a level and give more context, I ended up here for two main reasons. First is I wanted a comment widget that could fit in a timeline (or more specifically a dialog that is holding a timeline, like for workboards). Second is I do think we have a bit of an onboarding problem that could be solved with a more direct UI.

Also, from time to time I feel it is helpful to ignore all "rational" arguments and go through the exercise of creating something to solve the problems I see mentioned randomly here. Maybe at a small company with limited resources, this idea isn't the best, but I think at least we'll have something to point to for a discussion when it does come up and have a holder for those conversations. If the idea sucks then the idea sucks. :)

Can we style a real <select /> like that, or would we have to implement an element in JS? (I don't think we can colorize options in a <select />.) I'm a bit hesitant about replacing a <select /> with a JS element here because it's used heavily and we'll either lose functionality (tab focus, keyboard navigation) or need to spend a significant amount of time rewriting it in JS.

(We've swapped some other elements for JS (notably, policy controls), and the tradeoff is more reasonable there because they're rarely used and a <select /> can't do the job, but I still find it annoying when they don't respect tab order or react properly to keyboard input.)

I tried this in a few variations, and this seemed the "cleanest" UI wise. I think if I take 5 steps back, I could throw together a mock with selects in the bottom, remarkup back on top, but that seemed like a regression to current users, though likely easier for newer users.

This also seems inconsistent with other elements in "real" editors (Word, Google Docs), and other text editors on the web. Is this mostly to get the "Action" closer to the text?

(The majority of remarkup boxes do not have a submit button and do not have any actions. Doesn't it make these just worse?)

I modeled the interaction based on it's common use (comment or comment + action). I don't think of the box as a "real" editor to Word or Docs. The buttons just provide JS/text hints at what the appropriate Remarkup is, so leaning towards getting out of the way for people who know Remarkup seemed the right direction. This pattern is also common in Gmail, Facebook, Disqus, etc. I've studied these for a few weeks and it seems the pattern is a more simple primary (your text) vs secondary (marking up, attaching items).

Can we style a real <select /> like that, or would we have to implement an element in JS? (I don't think we can colorize options in a <select />.) I'm a bit hesitant about replacing a <select /> with a JS element here because it's used heavily and we'll either lose functionality (tab focus, keyboard navigation) or need to spend a significant amount of time rewriting it in JS.

What I like to do is just make the select transparent, the menu still is visible when focused, and you just position it on top of your UI so that people think they're clicking some cool-looking selector, when in fact they're just clicking an invisible <select> element.