[Workbench] Edit box for project description should be bigger
Edit box is woefully small. See picture. Ironically the rendered Description tab looks more reasonable when the content is not tiny: the edit box should encourage the user to write lots of useful content.
Fill the entire tab with the text entry box, instead of putting it in a popup. Perhaps this involves using "inline" mode in x-editable, and adding some CSS?
The "Save" button should be at the top (so it's visible immediately, even when the textile content is long).These might not be strictly necessary to bundle here, but could be relevant:
- Use an "Edit" button instead of the pencil icon.
- Use a "Save" button instead of a checkmark icon, and "Cancel" instead of an "x" icon.
#5 Updated by Radhika Chippada over 6 years ago
Notes about the update:
- The edit button for project description is now displayed on top of textarea; uses btn-primary with pencil on left; 10 rows of display area with inline editing;
- I did not update Ok and Cancel button icons to use text. This is managed by x-editable global templates http://vitalets.github.io/x-editable/docs.html#global and is set application-wide in editable.js. I could not see how we can change these only for the inline-editable and not everywhere else and hence left it as is.
- I also could not figure out how to change the placement of the Ok and Cancel buttons to either the top or bottom of the textarea (just for this inline-textarea). Hence, I let them be on the right hand side of textarea and used 98% of page for the editable instead (css).
#7 Updated by Brett Smith over 6 years ago
The new CSS will set 98% width for any inline X-Editable component. I'm concerned that this could surprise future developers who might try to use an inline editable. Is it possible to constrain this CSS further so it only applies to project description editing?
The existing code in
htmloptions[:btnplacement] to be a symbol. The new conditional branch looks for the string
'top'. For consistency, please change this, and the call in _show_description.html.erb, to the symbol
#9 Updated by Brett Smith over 6 years ago
Reviewing e146ad3. The changes address the previous issues, so thanks much for that.
The span tag is generated with all of the attributes included in
htmloptions. Now that we're adding several button options to
htmloptions, they're being rendered as (invalid) attributes on the span tag. For example, working on a development API server loaded with test fixtures, modifying the description for "A Project" has a span tag like this:
<span id="zzzzz-j7d0g-v955i6s2oi1cbso-description-1430770175757123" class="editable editable-textile editable-done-setup editable-pre-wrapped" [… data attributes…] btntext="Edit" btnplacement="top" btnclass="primary" tabindex="-1" style="display: inline-block;">
Is there a good way to prevent these key-value pairs from being rendered as attributes on the span tag?
#11 Updated by Brett Smith over 6 years ago
Reviewing 6e10831. This seems really great. Thanks for sticking it through. Just one small thing from here: this is also a preexisting bug, but now that we have the infrastructure to clean things up, it would be good to move the
tiptitle option from
nonhtml_options (since it's not a verbatim HTML attribute either, just like the btn-related ones). There are only a couple of templates using it (
app/views/projects/), so making the switch should not be difficult. If that's a straightforward change you can go ahead and merge with it. Thanks.