@[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 @inputs:

[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

  • perchance@lemmy.worldMEnglish
    2·
    8 months ago

    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.
    • VioneT@lemmy.worldOPMEnglish
      1·
      8 months ago

      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") where forget 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 the getComputedStyle.