Fullscreen & other button improvements: non-left-click, ESC, overlay issue, sizing, suggestions

[scscgit]

• Buttons (including full-screen) unexpectedly react to right-click and middle-click on mouse down, instead of only left-click on mouse up, which I believe is the most intuitive behavior. (Let's use GitHub issue editor as an example.) Easily reproducible on https://alex-d.github.io/Trumbowyg/demos/. If the defaults stay as they are, at the very least this could be configurable, as it's a UX requirement for some consumers.

• Full-screen mode can display incorrectly depending on parent elements. I'll illustrate this as a Vuetify-specific issue (with a default setup) as a use-case, so you can consider if this has a greater impact, and if there are any universal solutions.

  • Repro: https://codepen.io/cTAlENtATI/pen/YzQzymK (Tested on Chrome 92.0.4515.159 | Firefox 91.0.1 (64-bit))
  • App Bar <v-app-bar app style="z-index: 200"> covers the buttons, making it impossible to exit fullscreen mode, but only when Trumbowyg is under <v-overlay>. (Note that the z-index: 200 is properly overridden by a higher value if the textbox is outside.)
  • The text color also used to cause issues like displaying white color on white background, especially when not using :dark="false" on v-overlay, but I observed that behavior even with this prop (currently can't reproduce).
  • There is one workaround that can be used to limit the boundary of fullscreen, so that it stays in the parent <v-card>, using .v-overlay .trumbowyg-fullscreen { position: absolute; } style, which I'm currently using in my project's use-case (as it's usually not under v-overlay).

• As a feature suggestion, the fullscreen mode could support being closed via ESC key press. (This would also make it possible to recover from abovementioned styling hazard.)

• When inside element with a defined width, e.g. <v-card style="width: 400px">, Trumbowyg doesn't respect this boundary and thus completely breaks the page layout when a single word gets too wide (sometimes even pushing element completely outside the browser window, making the issue irrecoverable). As a workaround, I always use .trumbowyg-editor { word-wrap: anywhere; } style, but I'd suggest for this to be safely handled by default.

• It's difficult to reduce height directly by default (if we prefer it to auto-expand only once after there is a longer input), e.g. we have to use .trumbowyg-editor { min-height: 120px; }. Sometimes this still causes other issues like an empty (unusable) space at the bottom under input (screenshot).

  • Fixed by also applying

    .trumbowyg-box {
      // Remove redundant empty space if the total height of buttons and input
      // doesn't exceed 300px. Complements min-height value in .trumbowyg-editor
      min-height: auto;
    }

  

• Trumbowyg library doesn't directly expose array of default buttons to be used in config, so we can't properly re-use it, for example only exclude one entry (e.g. full-screen).

  • Also it's quite difficult to properly style the buttons on smaller sizes (as a compact widget) without large spaces between them.

• Fullscreen button in small resolution pushes the starting position of the text in input further down:

  

• Minor issue: we can't directly style this input (e.g. outline: 2px solid red;); but luckily this seems to be fine if we wrap it in another div.

• Buttons have large z-index value, by default displaying over any other library elements, e.g. Vuetify's v-footer or v-overlay. Workaround: .trumbowyg-button-pane { z-index: auto; }

  

• I was also unable to get this compatible with Storybook, specifically only the icons are missing:

  

[imaginarytools]

I addressed a couple of your issues here: #69 and #1286.

Namely the ability to style the toolbar at a granular level, and making the toolbar work outside the container of the element being edited. each can be set dynamically as you identify which type of configuration you need.

[scscgit]

Hi, thanks for your input. I see there's a lot of code with plenty of gathered technical details, but it's a bit difficult to compare which changes are related to this, I think it'd be helpful especially for other users if you could paste some screenshots with the old and new behavior. Hopefully the changes will be eventually integrated via PR to make workarounds unnecessary (and to parametrize the elements with any useful & tested styles), though it seems the project hasn't been very active recently :)

I'm assuming your changes are mostly related to making it able to style elements in our projects, i.e. "style the buttons on smaller sizes"?