Created attachment 1127 [details] screenshot of the textareas in question There are several textareas in the Profile List popup in Web Admin. The textareas that have a “fancy placeholder” are non-resizable. This makes them inconsistent and, in some cases, probably makes the text inside hard to work with.
To clarify, it is only horizontal resize that is disabled for these fancy placeholder textareas.
Resize of these textareas was disabled by purpose in commit r40219 for bug 7909. This is because the horizontal resize was buggy with these textareas. This was described in bug 7909 comment 550: > Textareas with fancy placeholders unfortunately have problems with resizing. By default, you are allowed to resize a textarea, but the surrounding <span> (.input) we use for fancy placeholders doesn't properly follow the resized textarea inside. This, in turn, leads to two problems: > > * When decreasing the textarea width, the placeholder text width doesn't decrease or get hidden (leaving it too big). > * When increasing the textarea width, the textarea expands but not the popup (see Profile List). Other popup textareas expand the popup when resized. > > There might be other potential issues as well, but the two above are the only ones observed so far. In practice, we only have textareas with fancy placeholders on two pages; Introduction Texts and Profile List. Out of these two, only the textareas on the Profile List page are resizable horizontally. > > Vertical resizing works fine. Before “giving up” and disabling resize, we investigated a few other alternatives: 1. “width: auto” on the .input – solves the resizing issue, but means we lose our desired standard widths. 2. “min-width: fit-content” on the .input – properly ensures the .input grows along with the child textarea, but doesn't resolve the issue w.r.t. the popup showing scrollbars instead of expanding. Unfortunately, min-width also conflicts with the automatic hidden overflow we want on the label. 3. “display: inline” on the .input – fixes the resizing issue, but means we can't set width. Inline elements are unaffected by “width”. 4. “display” something that isn't inline outwards on the .input – fixes “all” issues, but means we don't behave like regular <input>:s or <textarea>:s outwards. Regular input elements have “display: inline” by default, and regular textareas have “display: inline-block” by default. 5. “display: inline-flex” on the .input – might work combined with other changes. If we only change to inline-flex we get virtually the same behavior as if we disabled horizontal resize. Something regarding widths on flex containers.
Created attachment 1128 [details] screenshot of problem with resize moved to .input instead of textarea Lastly, we also investigated moving the resize capability to the actual .input rather than the child textarea. Conceptually, this is better and works well for the most part, but it has one problem in practice. When focused or when containing text, our fancy placeholders display the placeholder text in the border of the input/textarea. When in this position, the placeholder text label protrudes a bit outside the layout box of the .input. The issue with moving resize to the .input is that the placeholder text label gets clipped when in the border, as seen in the attached screenshot. This is because, in order for an element to be resizable, it's not enough to set the “resize” property, you must also set “overflow” to hidden or auto. We looked into if this could be solved using “overflow: clip” and “overflow-clip-margin”, but resize doesn't work with this overflow mode. The “clip-path” property doesn't seem to be able to “extend” the rendered area of an element either.
