@[email protected] - pinging dev :)
Here is my implementation of ‘remembering’ the resized size of the textarea
inputs. It is using the ResizeObserver
(documentation) and will only observe textarea
elements with resize
style property enabled.
It is enabled with the :
[remember(root, "@inputs")]
EDIT: It would only save the resized size if you have inputs on the textarea.
EDIT 2: Fixed width responsiveness (for elements with width: 100%; max-width: ... ; resize: vertical
where if the width gets lower than its maxed, it would save the width and fix the size without option to resize it back (since it is only resize: vertical
). It now only saves the resizable direction i.e. height if resize is vertical
and vice versa. For both
or normal textarea
it would save both width and height.
Here is the modified plugin: https://perchance.org/t2w8fixecn
Here is an example of it: https://perchance.org/5tfbmi0gtc
oops I forgot the ping doesn’t work in the body lmaoo
Nice! This would be a ‘breaking change’ in programming lingo, so it’d need to somehow be an explicit opt-in. Maybe a
data-remember-plugin-size=1
attribute on textareas? Or"@inputs,@textareaSize,a,b,c"
if global control is enough?For the data attribute approach you’d add
after
el.type == 'textarea' && el.style.resize != 'none'
. I like this better than global control, since it seems reasonable to only want certain textarea sizes to be remembered in some cases.Another possibility here which might be more future-proof / forward-looking is
data-remember-plugin="size,foo,bar"
- i.e. a general options attribute which allows customizing the remember plugin’s behavior on that input. I’m thinking out loud here, but I kinda like that approach. I’m not sure what “foo” and “bar” could end up being, but maybe e.g. options to allow forgetting after a certain number of minutes/hours/days, and stuff like that. Not that you’d implement that now, but it just allows for that sort of thing in the future without things getting messy.In this case you’d use something like
(el.dataset.rememberPlugin || "").split(",").map(a => a.trim()).includes("size")
.
A couple more thoughts:
- Some devices have different screen widths - e.g. horizontal/vertical orientation for mobiles and tablets. I don’t think this will cause much trouble, but I can imagine some edge cases where it would be annoying - e.g. you made the textarea wide while in horizontal orientation, and then later you came back to the site in vertical, but the textarea is now too wide to grab the little gripper to resize it, so the app appears “broken” to you. It’s tempting to put responsibility for this onto the gen author, but it’s probably not something that most perchance devs would realize.
- I’m not sure if
el.style.resize !== 'none'
is needed, but if it is, thenwindow.getComputedStyle(el).resize
might need to be used instead, since I think user agent styles tend to allow resizing in both axes by default.
I’ve updated it to only save the resize with the
data-remember-plugin
data attributes.It can probably also be used to check if certain elements can be saved and not (i.e.
data-remember-plugin="resize, forget"
) whereforget
can be an attribute to not save the inputs on that element.As for the different screen widths, I may have fixed it by only allowing the value to be saved the directions that the resize is allowed e.g. If the element has
resize: vertical
only the height would be saved and not the width.I also changed checking the value of the
resize
with thegetComputedStyle
.