Bug 9571

Summary: Fix width for textareas in Edit Item screen
Product: Koha Reporter: David Cook <dcook>
Component: TemplatesAssignee: 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: master   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
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
Currently, in the additem.pl script, when the value of a 952 subfield exceeds 100 characters, it is changed from a regular input element into a textarea input. This makes sense, however, it creates an issue with the styling, because the width:auto attribute that adjusts the widths of all the input elements won't work properly with a textarea element.

Currently, if your 952$u is over 100 characters, you will get a textarea of about 10ems or about 1/3 of the length of the other fields. Not only is this ugly aesthetically, but it also makes it difficult to view and highlight the link in that tiny textarea, especially in Internet Explorer where you can't change the size of textareas!

I want to introduce a new style for the textareas on this page so that they're roughly the same length as the regular input elements. I would like them to be identical, but I don't think that's possible using relative width values.
Comment 1 David Cook 2013-02-08 02:59:24 UTC Comment hidden (obsolete)
Comment 2 David Cook 2013-02-08 02:59:48 UTC
(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.
Comment 3 Owen Leonard 2013-02-08 16:34:02 UTC Comment hidden (obsolete)
Comment 4 Kyle M Hall 2013-02-08 16:49:36 UTC Comment hidden (obsolete)
Comment 5 Kyle M Hall 2013-02-08 16:50:24 UTC
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>
Comment 6 Kyle M Hall 2013-02-08 16:50:50 UTC
Both patches solve the issue. I'll leave it to QA to decent which one to use.
Comment 7 David Cook 2013-02-11 00:36:49 UTC
(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.
Comment 8 Owen Leonard 2013-02-11 13:46:40 UTC
(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.
Comment 9 Marcel de Rooy 2013-03-24 16:39:54 UTC
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>
Comment 10 Marcel de Rooy 2013-03-24 16:42:01 UTC
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
Comment 11 Jared Camins-Esakov 2013-03-31 03:41:15 UTC
Owen,

Marcel preferred the CSS version. Thoughts?
Comment 12 Owen Leonard 2013-03-31 14:18:59 UTC
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.
Comment 13 Jared Camins-Esakov 2013-04-02 12:23:24 UTC
(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.
Comment 14 Jared Camins-Esakov 2013-04-02 12:23:50 UTC
This patch has been pushed to master.
Comment 15 Chris Cormack 2013-04-14 06:10:03 UTC
Pushed to 3.10.x and 3.8.x will be in 3.10.5 and 3.8.12