TEXTAREA rows Set to a Value Which is Too Small To Display
The first problem is an easy one to fix. The problem is that if TEXTAREA rows is set to a value less than 5, it cannot display the scroll bars. The reason for this, is that it takes all five rows to display the smallest slider and the two stacked arrow buttons below it. If Safari cannot display the graphics for the slider, it omits them altogether and instead shows a gray bar on the right-hand side of the TEXTAREA.
Keep in mind that depending upon what font size you are using and the characteristics of that font, the minimum number of rows may differ. But generally for the plain default for Safari should be around 5 rows.
Some Examples of this problem - All have the same amount of text:
TEXTAREA - 1 Row - No Scroll bar:
TEXTAREA - 2 Rows - No Scroll bar:
TEXTAREA - 3 Rows - No Scroll bar:
TEXTAREA - 4 Rows - No Scroll bar:
TEXTAREA - 5 Rows - Scroll bar!!!:
Observe on this last example how the scroll bar is at its smallest.
Safari TEXTAREA does not always Display a Scroll Bar when Rows is 5 or Greater
Believe it or not, but just because you set rows to 5 on the TEXTAREA tag, does not ensure that you will always get a scroll bar when you need it. Why? I don't know. I think it is a legitimate bug on Safari's behalf.
The nature of this issue is that if you have rows set to five, the scroll bars will not appear until the text actually spans down to row seven! While the text is 6 rows long, you either cannot see the first row or the last row depending upon the position of the cursor.
The solution to this problem, is that instead of fully in-lining your text as follows:
<textarea cols="20" rows="5">Please assume there is six lines of text here!</textarea>
Just add a linefeed to the end of the text so that way the </textarea> tag begins on a new line in the source document. Back on your application server, you may have to strip off any trailing whitespace to preserve data integrity, if it is even an issue. An example would be:
<textarea cols="20" rows="5">Please assume there is six lines of text here!
</textarea>
The way this solution works, is that when your actual text finally overflows on to row 6, because you added that extra linefeed to the source, it is actually overflowing to row 7 and enables the scroll bar.
The user cannot really see that extra linefeed and does not really realize it is there. This solution does allow the TEXTAREAs to be properly displayed with scroll bars upon page load if they need it.
The limitation that this has, is with the actual users. If the position the cursor after the final linefeed and they start typing before the text rows reach that threshold, then the same behavior will occur, unfortunately. Play around with the example below to see how it behaves.
EXAMPLE of Bad Overflow
TEXTAREA - 5 Rows - 4 Rows of text PLUS Linefeed - No Scroll Bar:
TEXTAREA - 5 Rows - 5 Rows of text PLUS Linefeed - No Scroll Bar:
TEXTAREA - 5 Rows - 6 Rows of text PLUS Linefeed - Scroll Bar!:
TEXTAREA - 5 Rows - 4 Rows of text NO Linefeed - No Scroll Bar:
TEXTAREA - 5 Rows - 5 Rows of text NO Linefeed - No Scroll Bar:
TEXTAREA - 5 Rows - 6 Rows of text NO Linefeed - No Scroll Bar:
TEXTAREA - 5 Rows - 7 Rows of text NO Linefeed - Scroll Bar!:
PLEASE READ - Problems with the Examples!
How wonderful blogging is. Once again the examples have unexpected results when posted through the blog! In the source code I do have a linefeed, but the blog went ahead and inserted a <br /> in its place. So all of these examples are a bit hosed. I will need to try to find a way to preserve the linefeed. If anyone can provide the answer, I would greatly appreciate it!
Believe it or not, even though the <br /> has been added, all of the examples are displaying correctly in Safari as the headings state: So if it says it has no scroll bar, it has none. If it says it has a scroll bar, then it does have a scroll bar.
Other Information
It should also be noted that Safari also support the attribute wrap which is not part of the HTML 4.01 standard. Possible values are: soft, hard, and off.
How Other Browsers Handle these Conditions
First off, let me state that I do not have access currently to too many different browsers. If you have one that is not listed in this list or of a different version that behaves differently, please post a message stating how it handles these conditions. Thanks you!
Safari v2.0.3 - Mac OS X v10.4.6 - MacBook Pro - 2.16 GHz Intel Core Duo - All tests and comments based up this configuration.
FireFox v1.5.0.4 - Mac OS X v10.4.6 - MacBook Pro - 2.16 GHz Intel Core Duo - There are no issues with the vertical scroll bar. It appears like when ever text does overflow, FireFox always displays the vertical scroll bar. One thing FireFox does do differently, is that when you set rows to 1 it displays 2 rows. At a minimum it displays the slider and the slider starts to cover up the two arrow buttons as needed. So when it is displaying two rows of text (rows=1) you just see the slider. When three rows of text (rows=2) you see the slider plus the down arrow button. Four and more rows you can see the slider and both buttons. So it appears like in all cases that I have setup for testing, the actual display is 1 line more than what rows has been set to.
Another obvious difference, is that FireFox enables the horizontal scroll bar for long text that has no spaces. If there are no spaces in the text, FireFox will not wrap it. That said, FireFox does give higher priority to wrapping text to try and eliminate the horizontal scroll bar. Safari will wrap long text with no spaces. The extra linefeed is NOT needed with FireFox nor is there any issue with any line of text overflowing without scroll bars being enabled.
References
Apple's Safari HTML Reference - Standard HTML Tags
4 comments:
Sorry to rain on this particular parade, but I get no scrollbars in ANY of your examples, using Safari 2.0.4 (419.3).
Jacob, thanks for the feedback.
But no parade in progress. As I stated in the text the blog "modified" the contents of the textarea so the results may not be valid. I was just happy it was still displaying the same, although it might not have been based upon the defect.
There is a chance that apple has found a fix and rolled it out. Who knows.
It was something on my mind at the time. When you get down to it, it never was a problem that you could not work around.
It now appears that with Safari Version 3.0.4 (5523.10.6) you need set rows to 6 now. 5 isn't enough.
Bill, thanks for your comment. I took a look using Safari v3.0.3 (522.15.5) for Windows! It appears like under my first set of examples that Safari does not display anything with textarea set to 1 row. But then even when it is set two 2 rows or more, it tries its best to display a fragmented scroll bar. At 5 rows, it shows the whole scroll bar, but without the blue jewel. It now takes 6 rows to actually see the blue jewel and see it move in respects to position, as you have pointed out.
One thing that has also changed is that now Apple does give you the chance to resize the textareas to dynamically make them fit the content a little better.
Post a Comment