Summary: | Fix width for textareas in Edit Item screen | ||
---|---|---|---|
Product: | Koha | Reporter: | David Cook <dcook> |
Component: | Templates | Assignee: | David Cook <dcook> |
Status: | CLOSED FIXED | QA Contact: | Marcel de Rooy <m.de.rooy> |
Severity: | minor | ||
Priority: | P5 - low | CC: | chris, kyle, m.de.rooy |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Attachments: |
Bug 9571 - Fix width for textareas in Edit Item screen
Bug 9571 [Alternate] Fix width for textareas in Edit Item screen [SIGNED-OFF] Bug 9571 - Fix width for textareas in Edit Item screen [SIGNED-OFF] Bug 9571 [Alternate] Fix width for textareas in Edit Item screen Bug 9571 - Fix width for textareas in Edit Item screen |
Description
David Cook
2013-02-08 02:51:27 UTC
Created attachment 15152 [details] [review] Bug 9571 - Fix width for textareas in Edit Item screen (In reply to comment #1) > Created attachment 15152 [details] [review] > Bug 9571 - Fix width for textareas in Edit Item screen To test: Before applying patch... 1) Create a new item for any biblio with a URL (subfield u) of over 100 characters (you can use www.lettercount.com to count the number of characters in your URL). 2) In any browser (I've already looked at IE, Firefox, and Chrome on Windows), edit the item (either by clicking "Edit Items" from the Normal view of the bib record then clicking "Edit" next to the applicable item, or clicking on the "Items" view in the bib record and clicking "Edit item" next to the relevant item). 3) Notice that the textarea for the url is absolutely tiny. Difficult to read and difficult to interact with. Apply patch. 1) Notice that the textarea is roughly the same size as the other input elements on the page. --- Ideally, I would like the textarea to automatically be the same length as the other input elements, but I'm not sure how to do that just with CSS and while still only using relative values. Open to hear other ideas about how this can look even better. Created attachment 15173 [details] [review] Bug 9571 [Alternate] Fix width for textareas in Edit Item screen This alternative patch modifies the script where the input markup is built and adds an alternative configuration for textareas. This gives the textareas explicit "cols" and "rows" attributes. I think this solution is preferable to a style fix because it solves the bug while eliminating some invalid markup (no "size" or "maxlength" attributes on textareas, which are invalid without explicit dimensions). To test, add a nice big chunk of text to an existing item's item field like "Public note" (952$z), save, and edit again. The field should now be displayed in a more comfortably-sized textarea. Created attachment 15174 [details] [review] [SIGNED-OFF] Bug 9571 - Fix width for textareas in Edit Item screen This patch adds a style for textareas on the Edit Item screen of addbiblio.pl so that they are roughly the same length as the other input elements around it on the page. To test: Before applying patch... 1) Create a new item for any biblio with a URL (subfield u) of over 100 characters (you can use www.lettercount.com to count the number of characters in your URL). 2) In any browser (I've already looked at IE, Firefox, and Chrome on Windows), edit the item (either by clicking "Edit Items" from the Normal view of the bib record then clicking "Edit" next to the applicable item, or clicking on the "Items" view in the bib record and clicking "Edit item" next to the relevant item). 3) Notice that the textarea for the url is absolutely tiny. Difficult to read and difficult to interact with. Apply patch. 1) Notice that the textarea is roughly the same size as the other input elements on the page. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 15175 [details] [review] [SIGNED-OFF] Bug 9571 [Alternate] Fix width for textareas in Edit Item screen This alternative patch modifies the script where the input markup is built and adds an alternative configuration for textareas. This gives the textareas explicit "cols" and "rows" attributes. I think this solution is preferable to a style fix because it solves the bug while eliminating some invalid markup (no "size" or "maxlength" attributes on textareas, which are invalid without explicit dimensions). To test, add a nice big chunk of text to an existing item's item field like "Public note" (952$z), save, and edit again. The field should now be displayed in a more comfortably-sized textarea. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Both patches solve the issue. I'll leave it to QA to decent which one to use. (In reply to comment #3) > Created attachment 15173 [details] [review] [review] > Bug 9571 [Alternate] Fix width for textareas in Edit Item screen > > This alternative patch modifies the script where the input markup is > built and adds an alternative configuration for textareas. This gives > the textareas explicit "cols" and "rows" attributes. I think this > solution is preferable to a style fix because it solves the bug while > eliminating some invalid markup (no "size" or "maxlength" attributes on > textareas, which are invalid without explicit dimensions). > > To test, add a nice big chunk of text to an existing item's item field > like "Public note" (952$z), save, and edit again. The field should now > be displayed in a more comfortably-sized textarea. I like the idea of using explicit "cols" and "rows". I wasn't sure whether it would be preferable to do that or use CSS, so I went with the latter. I think it might be an idea to increase the number of "cols" to 69 or so, so that it is closer to the length of the other input fields, but I might just be in favour of that number, because it looks better on my monitor. The same might not be true for others. (In reply to comment #7) > I think it might be an idea to increase the number of "cols" to 69 or so, so > that it is closer to the length of the other input fields Unfortunately "cols" doesn't map directly to text inputs' "size" attribute, and different browsers size them differently. I chose the size I did because it looked correct in Firefox :) Of course the size of both text inputs and textareas could be controlled by CSS, but we already have differently-sized selects and inputs, so I don't think it's much of an issue. Created attachment 16834 [details] [review] Bug 9571 - Fix width for textareas in Edit Item screen This patch adds a style for textareas on the Edit Item screen of addbiblio.pl so that they are roughly the same length as the other input elements around it on the page. To test: Before applying patch... 1) Create a new item for any biblio with a URL (subfield u) of over 100 characters (you can use www.lettercount.com to count the number of characters in your URL). 2) In any browser (I've already looked at IE, Firefox, and Chrome on Windows), edit the item (either by clicking "Edit Items" from the Normal view of the bib record then clicking "Edit" next to the applicable item, or clicking on the "Items" view in the bib record and clicking "Edit item" next to the relevant item). 3) Notice that the textarea for the url is absolutely tiny. Difficult to read and difficult to interact with. Apply patch. 1) Notice that the textarea is roughly the same size as the other input elements on the page. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> QA Comment: I picked the css variant. Looks just little better in this perspective than hardcoding rows and cols in code. But it is arbitrary. Passed QA Owen, Marcel preferred the CSS version. Thoughts? What about doing both? Does the CSS correctly size the fields when the rows and cols are set? I'd like the markup to be valid. (In reply to comment #12) > What about doing both? Does the CSS correctly size the fields when the rows > and cols are set? I'd like the markup to be valid. Yes. I am satisfied with this. Pushing now. This patch has been pushed to master. Pushed to 3.10.x and 3.8.x will be in 3.10.5 and 3.8.12 |