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.
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