-
Notifications
You must be signed in to change notification settings - Fork 333
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Autogrow support #132
Comments
That would be great to have. |
👍 |
This shouldn't be too hard actually. Someone asked how to do this on StackOverflow so I took a stab at it. It's actually pretty easy if anyone wants to implement this before I get to it: var editor = new EpicEditor();
var updateEditorHeight = function () {
var editorHeight = $(editor.getElement('editor').body).height();
// +20 for padding
$('#epiceditor').height(editorHeight + 20);
editor.reflow();
}
editor.load(function (){
updateEditorHeight();
});
editor.on('update', function () {
// You should probably put a check here so it doesn't
// run for every update, but just on update, AND if the
// element's height is different then before.
updateEditorHeight();
}); The important bits being just the @techwraith - I know you wanted to know how hard this would be too awhile back. |
This doesn't seem to work on Chrome. The body height just keeps on increasing! I'm not sure why. Works perfectly on Firefox. |
So I started poking at making this possible in a desperate attempt to cobble something usable for #27. We need to make the internal iframes all have In particular, this makes the body always the size of the parent iframe, meaning the document will indefinitely grow but not shrink. Is there any reason to exclude the doctype? I assume up until now it was just never considered. |
For anyone who needs/wants it, this code works for adding autogrow externally:
(edited several times to fix mistakes) |
Note that this works right in FF without the doctype fix, but only grows in chrome (and presumably all webkit) without it. (it is also a quick strip-out of what I actually used, so I might have borked something in the translation) |
Cleaned up to comply with EE's code style, and made it so that the window scrolls as the thing grows. Edit: Adding this to the end of /docs/main.js makes the docs page work pretty well in ios! (with the doctype fix) |
@jeremybenaim actually added DOCTYPEs already here. You could probably cherry-pick this into master, maybe? |
Any reason why this was never merged in? |
It was in the IE8 branch that I never finished and didn't have a need–until now–to merge it in. |
Alright, I'll consider merging it in (or hacking in my own version). Anyway, here's the final version of the autogrow hack:
It will now resize when you change between preview/edit mode. Also doesn't rely on jquery at all now, meaning this could be fairly easily merged internally. |
Note: it appears that the latest firefox update changes the behaviour of document.documentElement.scrollHeight to match that of IE, instead of that of webkit. I am not clear if this is a bug or not (as the webkit approach to this value, imo, makes much more sense-- and is the one documented on mdn). As such, the solution above does not work in the latest versions of FF/IE (they both grow indefinitely). Additionally, due to a quirk of innerText unique to IE, the solution above will not work for trailing whitespace (because it gets stripped, and EE can't tell a change even occured). My browser literally updated itself right before I was going to submit a PR to make this a proper feature, which led to a lot of swearing and confusion. |
The develop branch now supports autogrow through autogrow:true, with more granular subcontrols if you pass autogrow an object instead. |
👍 |
@gankro One weird thing, maybe it's just the docs?, but rather than the typable area getting pushed down it's like the whole page scrolls. Super weird feeling. |
I keep noticing myself holding enter down, making the textarea bigger, then scrolling back to the top. Can we not scroll the whole window down? |
Both are happening. The typeable area grows, and the page scrolls to follow the cursor It does create an odd stand-still illusion. I do this mostly for iOS support, where it seems more than happy to let the bloody thing scroll away. It could definitely be tweaked, but I think it works alright. |
If you're doing it mostly for mobile anyway to just sniff iOS? Feel awkward on desktop, personally. Feels like an old school typewriter where the paper comes out the top :P |
If you could leave that in as an option, that would be great. I'd love to On Monday, July 22, 2013, Oscar Godson wrote:
|
@techwraith leave which thing exactly? Moving the page upwards rather than pushing downwards? Have you played with it? Curious what your thoughts are on it. |
Typewriter mode :) I use that in byword in full screen mode all the time. I haven't tried On Monday, July 22, 2013, Oscar Godson wrote:
|
Yeah, if you could clone, pull up index.html, and try it out that'd rock just to know we're talking about the same things and we could do it as an option (forced on iOS tho) |
Looks good to me, it works really well if the backgroud of the parent element of the editor is the same as the background of the editor. |
I'll have to try that out. Cool, maybe we'll make that an option then. |
It is actually autogrow.scroll:true/false It's just true by default. I just ran a double-check on all the browsers, and it seems to not just be iOS, but Safari in general. Both desktop and mobile are willing to let the cursor fall off the page. I highly recommend keeping scroll:true as the default. I'd rather not have it browser sniff for safari, especially if that means inconsistent cross-browser behaviour. It also makes the experience with preview/edit toggling better, as it scrolls to the same relative place when preview/edit causes a resize. Just to be totally clear: if someone doesn't like it, it's always one config setting away. It seems it's just a matter of the default should be (and if browser sniffing should occur). I highly recommend true be the default for reasons stated above. |
So do you guys want me to change anything, or...? |
It's fine as is as long as I can turn that off for my stuff. If I get lots of people asking about it or wanting to turn it off we can look at it again. Thank you for doing all this! |
For those who want to use an maximum height: Just replace this in the hack (#132 (comment) ): // Old
if (newHeight != oldHeight) {
// New
if (newHeight != oldHeight && newHeight < 1000 )
// and change 1000 to whatever ;) |
@basteyy EpicEditor now supports autogrow and has a maxHeight option :) see the README and the options table. |
Perhaps we should do a minor point release to have this stuff official? |
indeed. This weekend I'll do it. |
#132 (comment) Okay, i just read the docs on your website ;) |
If
autoGrow: true
, in/decrease the height Npx each line of text put into the editorThe text was updated successfully, but these errors were encountered: