Default edit box to sane size

[iangreenleaf]

Per #26, I think we'll get rid of the edit box preference and instead set it to something useful by default and let the user resize it with browser controls. Open questions:

• What exactly is a sane size?
• Can we make this responsive for mobile?
• Can we detect when a user resizes it and save that for them? That would be amazing, but should maybe wait until after launch.

[iangreenleaf]

@hannaliebl maybe this is something you would be interested in taking a look at? Namely, can we make the text box responsive to screen size?

[hannaliebl]

Sure, I can take a look at this, later tonight.

[hannaliebl]

So, to make this responsive to any screen size the best bet is to set the textarea it to a percentage-based width; however, it will be based on the width of the parent element, and since this whole layout is based on fixed em widths, it will never be truly responsive as it stands now. I could, however, go in and change the layout to use widths everywhere–I'm going to try this in my branch and see if it's easy to do and make sure it doesn't have unintentional side effects.

[iangreenleaf]

Hmm, so we'd be somewhat at the mercy of the stylesheet's overall positioning scheme, huh? That's not great news, given the wide variety of stylesheets Plans supports. If there's any way to make it independent of the parent, that would be awesome. If not, is there a way to set a sensible (but non-responsive) width in cols and then have it overridden when the stylesheet allows?

[hannaliebl]

If no changes are made to the underlying HTML structure and id/class names, couldn't the default stylesheets be retooled to use percentage-based widths, for example, without any harm done to any custom stylesheets, or am I misunderstanding something else about the way the stylesheets work with Plans?

[iangreenleaf]

Yeah, that's possible and worth considering, but would have the downsides of potentially being a labor-intensive update, and still leaving custom stylesheets in the dark without an easy upgrade path.

I'm thinking that while this issue is still worth addressing, it's sounding complicated enough that we shouldn't try to tackle it until after launch. For the moment let's just use people's stored column preferences if they exist, and we'll plan to return to a better solution later.

Thanks for looking into this! Even though we didn't find an easy solution, it was still very helpful to get your input.