2

Can't seem to find a decent way of doing this. My editor is a full screen editor, not a normal textarea. Its for full screen editing and the issue is, currently, once you reach the end of the page you are always typing at the bottom of the browser window unless you press enter a bunch of times.

I was thinking adding a bunch of \n\n\n\n\n to the bottom of the textarea that are always there (if you erase them and start typing again it pops them back in), but I wasn't sure how well that'd work or the best way to implement that. Any ideas?

My best idea was, to check if the last N characters of the textarea value were equal to what i deemed to be a good buffer, i.e. 6 \ns by doing a little regex. If it was not equal, it'd add it to the bottom and scroll to the bottom (making it look like padding).

Using just JavaScript and jQuery (1.6, so .prop() examples, not .attr()!)

Here's a screenshot scrolled down (no padding): screenshot

==UPDATE== The problem with padding is that then the editor is seen as not full screen and looks strange:

padding issue

The solution i think needs to go into modifying the actual text on the fly... maybe

Oscar Godson
  • 31,662
  • 41
  • 121
  • 201
  • What about making textarea say 85% height, removing the border with css and instead placing it in a div that's 100% height and with border. And you can set overflow:hidden for textarea to avoid having the scrollbar. – AR. Jul 08 '11 at 21:08
  • Look at Rodaine's answer and my response. Any ideas? – Oscar Godson Jul 08 '11 at 21:20
  • If you set overflow to hidden there won't be a scroller. – AR. Jul 08 '11 at 21:22
  • BTW you misspelled shift in `Alt+Shift+a` and `Alt+Shift+s` :) – Rodaine Jul 08 '11 at 21:24
  • @AR that defeats the purpose of a text editor. You would still need to scroll to see content below the fold. – Rodaine Jul 08 '11 at 21:27
  • hahaha, _shit_ pesky f changes everything. No worries tho, just a test doc ;) thanks for pointing that out! – Oscar Godson Jul 08 '11 at 21:27
  • @Rodaine you can just use arrow keys although it's not super convenient for sure. – AR. Jul 08 '11 at 21:34

2 Answers2

4

Try applying padding with CSS to the bottom of the textarea

.editor {
    padding-bottom: 60px; //or the equivalent of 6 lines
}
Rodaine
  • 1,018
  • 7
  • 13
  • 4
    `6em` instead of `60px` will give you the height of 6 lines. – Chriszuma Jul 08 '11 at 21:09
  • Padding is what I tried, the only issue is it sorta looks weird is the problem. Notice in my updated screenshot the draggable area to make the textarea bigger? If i make the padding bigger, i need to make the editor's height smaller (fine) but then the white draggable piece is like up top and you can see where the textarea ends. It works, but it's ugly. Maybe hide the draggable piece somehow? – Oscar Godson Jul 08 '11 at 21:20
  • I think you're referring to the resize handler? Just add `resize: none;` to the CSS for the editor and it will disappear. – Rodaine Jul 08 '11 at 21:22
  • Awh, this is the issue with padding. Now i remember: https://skitch.com/oscargodson/fe75e/epiceditor --- The text gets cutoff at weird places because it's invisible... – Oscar Godson Jul 08 '11 at 21:35
  • I would need to see some more markup and the rest of the CSS applied to the textarea...I've been messing around with this using the developer tools in chrome on these comment boxes. Setting the style to a fixed height (200%), with padding-bottom (6em) and resize (none). Maybe there is some other CSS being applied/inherited that is causing the unusual cutoff? – Rodaine Jul 08 '11 at 21:48
  • It's just getting cutoff because im scrolling. Create any textarea, type a lot of stuff and then scroll down just a tad. Eventually the text will get cutoff. – Oscar Godson Jul 11 '11 at 18:21
  • So you just want the textarea to scroll only by lines of text so that nothing gets cut-off? – Rodaine Jul 11 '11 at 18:31
  • The behavior is different in Gecko (Firefox) and Webkit (Chrome/Safari). Webkit has the desired behavior (the padding is scrollable), Firefox the undesired behavior (the padding is outside the scrollable region). I'm also stuck on this a.t.m. :-/ *UPDATE*: Here's a relevant mailing list thread: http://forums.digitalpoint.com/showthread.php?t=1164285 – Roman Nurik Aug 20 '11 at 00:29
0

Rodaine's padding-bottom answer is good, but if you don't want to lose that real estate for displaying the content of your document, I have a kinda a crazy idea.

If your font-size and line-height are defined, you could calculate the y coordinate of the text character directly preceding the cursor position (http://stackoverflow.com/questions/263743/how-to-get-cursor-position-in-textarea). Something like ((font height + line height) * current cursor line). Then when that y value passes a particular threshold, you do a negative margin-top or something to move your editing space upward.

ElonU Webdev
  • 2,451
  • 14
  • 15
  • That is a pretty crazy idea... but i like crazy. Sort of like a typewriter when it gets pushed upwords (which would work perfect for my style of editor, see the screenshot above). Ima try it. I could have a super quick, 100-200 millisecond animation of it going up a few lines too – Oscar Godson Jul 08 '11 at 21:21
  • Look at my updated question above about the padding problem. Do you think this would fix that issue? If not, any other ideas? – Oscar Godson Jul 08 '11 at 21:39
  • Nice-looking editor. Reminds me of iA's Writer. Back on topic: yes, my method allows you to still show text right up to the edge of the browser. If you're going to add a little animation, don't reinvent the wheel - use this excellent plugin instead: http://demos.flesler.com/jquery/scrollTo/ – ElonU Webdev Jul 08 '11 at 21:53
  • scrollTo isn't needed anymore :) jQuery allows you to animate scrollbars by doing `$(window).animate({scrollTop:'100px'},100)` – Oscar Godson Jul 10 '11 at 02:28