@[email protected] ^^

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 && el.dataset.rememberPluginSize 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, then window.getComputedStyle(el).resize might need to be used instead, since I think user agent styles tend to allow resizing in both axes by default.