iOS Support

[OscarGodson]

We need to make the editor work on mobile devices, but for 1.0 just iOS5 for now. If more, awesome. I'm sure it'd mostly be CSS with some minor JS checks for touch support.

Maybe even on focus the editor fills the phone so it's just the editor and keyboard.

[LucaRosaldi]

That would be great. Don't forget to display the "preview" and "fullscreen" options which are on hover, though. When I first heard of EE, I opened the demo page with an iPad, I tried the editor and thought "so what?", before having a quick glimpse of the two icons in the right bottom corner and realizing there were other options.

[OscarGodson]

@lucasrosaldi yep! The editor should have a different look for iOS altogether and will need to work with touch events. Hopefully I can get to this in the 0.1.3 release.

[fuddl]

Should be renamed to 'Mobile support' since there is not only iOS any more.

In Chrome for Android its a little hard to use right now.

[OscarGodson]

Android would be a different ticket like how there was Safari, IE9, etc tickets. "mobile" support is too broad. If you want, go ahead and make an android ticket tho :) I want to add support eventually for sure, but the main issue is I don't have an android device.

[fuddl]

ok, I thought this issue is about how should things work on touch devices which would affect iOS and Android equally.

Maybe even on focus the editor fills the phone so it's just the editor and keyboard.

I would like that feature and I offer review it on Chrome for Android once there's a pull request.

[OscarGodson]

We want the same experience like we want the same experience across desktop
browsers, but the code to achieve it it a quite a bit different for
different mobile devices. iOS will probably just be the first to implement
the mobile UX because that's what I have. Android would come next.

On Friday, August 24, 2012, fuddl wrote:

ok, I thought this issue is about *how should things work on touch devices

• which would affect iOS and Android equally.

Maybe even on focus the editor fills the phone so it's just the editor and
keyboard.

I would like that feature and I offer review it on Chrome for Android once
there's a pull request.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-7999105.

[joemccann]

Status on this?

[OscarGodson]

Sigh, soon. I had 2 core contributors but they've gotten busy with other projects/life so it's just me so progress has slowed down but I do generally work on this project every other day. It's set or 0.3.0 which does mean very soon since I'm close to the 0.2.1 release then 0.2.2 will probably be some even smaller fixes and me finishing up IE8 support. Then onto 0.3.0.

[joemccann]

Nice one. I'm probably going to drop this in as a replacement for Ace Editor on http://dillinger.io

[OscarGodson]

@joemccann That'd be awesome. Let me know if you need any help or if there's any bugs that need immediate attention :)

[joemccann]

Will do! I'm gonna create a fork that uses EpicEditor. I need to refactor the front end JS anyway, so this is a really good reason to do so.

[joemccann]

@OscarGodson LOVE EpicEditor. I forked it and tried to integrate into Dillinger, but the problem is the UI piece (namely the iframes) are so tightly coupled to the business logic of EpicEditor that I would be effectively hacking/patching my way to get it to work.

That being said, digging thru your code has inspired me to swap out Ace editor for a bare bones approach of contentenditable and using marked on the client side.

[OscarGodson]

@joemccann I'd be interested in what were the actual problems so I can see if this is something that can fixed or that it just doesn't fit this use case. You can post here or email me oscargodson@outlook.com if you are interested in providing feedback :)

[joemccann]

If you look at how the iframes (presentation layer) is bound to the logic of rendering the markdown you'll see what I mean. If I just wanted to replicate the dillinger functionality but with using Epic Editor, I'd have to hack around and/or strip out the presentation layer logic that is bound to the rendering capabilities. It's certainly possible, but a higher LOE than I can dole out at the moment.

By no means am I dissing the product, EE is fucking bad ass for a drop in markdown editor. Self contained. It's great. But for what I need, I want to leverage the look and feel but have custom logic available to render the markdown on keyup, for example.

[OscarGodson]

@joemccann I replicated the main part here (minus your CSS, of course): http://jsbin.com/uceyun/1/edit

Adding the title, changing themes, etc would be trivial. Are you worried about the line numbers?

I'm only asking because EpicEditor is meant to not only be a drop in editor, but also a set of APIs to build an editor and removing the default pre-packaged stuff by turning on/off options.

[joemccann]

Damn, nice work dude. I guess I was digging too deep!

However, I'm the text is not render the markdown to html??

[OscarGodson]

Not sure I get that last sentence haha. Are you asking how to get the text not as HTML? exportFile defaults to raw text. You can either leave it null or do "text" where "html" is.

[joemccann]

If I type markdown on the left HTML is not rendered on the right

Joe McCann
Sent from my iPhone

On Wednesday, February 27, 2013 at 12:55, Oscar Godson wrote:

Not sure I get that last sentence haha. Are you asking how to get the text not as HTML? exportFile defaults to raw text. You can either leave it null or do "text" where "html" is.

—
Reply to this email directly or view it on GitHub (#27 (comment)).

[OscarGodson]

Really? Working for me. What browser? Screenshot?

---

From: Joe McCannmailto:notifications@github.com
Sent: ‎2/‎27/‎2013 10:19 AM
To: OscarGodson/EpicEditormailto:EpicEditor@noreply.github.com
Cc: Oscar Godsonmailto:oscargodson@outlook.com
Subject: Re: [EpicEditor] iOS5 Support (#27)

If I type markdown on the left HTML is not rendered on the right

Joe McCann
Sent from my iPhone

On Wednesday, February 27, 2013 at 12:55, Oscar Godson wrote:

Not sure I get that last sentence haha. Are you asking how to get the text not as HTML? exportFile defaults to raw text. You can either leave it null or do "text" where "html" is.

—
Reply to this email directly or view it on GitHub (#27 (comment)).

---

Reply to this email directly or view it on GitHub:
#27 (comment)

[ghost]

Evernote was unable to submit your note for the following reason:
Emailed note was received, but Evernote did not understand the email address. It may be mistyped, or the user may not exist. Please check to make sure the address was properly entered.

Original message information:
From: Oscar Godson notifications@github.com
Delivered to: teejmya.93468@m.evernote.com
All recipients: OscarGodson/EpicEditor EpicEditor@noreply.github.com;
Subject: Re: [EpicEditor] iOS5 Support (#27)
Sent: Wed Feb 27 10:21:57 PST 2013

To prevent excessive emails, you may not receive another error reply
for the next 360 minutes.

[joemccann]

Chrome stable. I'll try again when at computer.

Joe McCann
Sent from my iPhone

On Wednesday, February 27, 2013 at 13:22, Oscar Godson wrote:

Really? Working for me. What browser? Screenshot?

---

From: Joe McCannmailto:notifications@github.com
Sent: ‎2/‎27/‎2013 10:19 AM
To: OscarGodson/EpicEditormailto:EpicEditor@noreply.github.com
Cc: Oscar Godsonmailto:oscargodson@outlook.com
Subject: Re: [EpicEditor] iOS5 Support (#27)

If I type markdown on the left HTML is not rendered on the right

Joe McCann
Sent from my iPhone

On Wednesday, February 27, 2013 at 12:55, Oscar Godson wrote:

Not sure I get that last sentence haha. Are you asking how to get the text not as HTML? exportFile defaults to raw text. You can either leave it null or do "text" where "html" is.

—
Reply to this email directly or view it on GitHub (#27 (comment)).

---

Reply to this email directly or view it on GitHub:
#27 (comment)

—
Reply to this email directly or view it on GitHub (#27 (comment)).

[Gankra]

Has anyone started on the actual title issue? Do we have any specs for how behaviour should change?

From what I've skimmed we're shooting for:

• permanent preview/fullscreen buttons on mobile
• auto-on-focus full screen (this seems problematic-- how do you exit?)

[OscarGodson]

@gankro

• Yes
• I was thinking of a close button or something. That was just an idea, but im open to anything.

[Gankra]

Any idea how mobile handles fullscreen anything? On desktop it lets you exit with ESC, how does that work on other devices? If there is a convention, I think we should just stick with that (unless it's too weird).

[OscarGodson]

You'd use faux fullscreen if you're on a mobile device or if the resolution is too small. FWIW, on IE10 / WP8 the fullscreen button works great, just can't close it haha

[Gankra]

Ah, okay. Is faux-screen implemented yet, or is that a sub-issue of this one?

[OscarGodson]

@gankro it's how IE9, 10, and how Firefox used to work until a couple months ago. The internal _goFullscreen() method should figure that out for you. I haven't tested it on mobile since the buttons aren't there on iOS, but my guess is that fullscreen should just work™

If not, like if it gives you JS errors, you can manually set it useNativeFullscreen: false in the options, or internally you can override this option if on mobile.

[Gankra]

How do you feel about a config option "showChrome":

• true (always show)
• false (never show)
• "autohide" (default behaviour)

This way, at very least users can be smarter than us and do what they want with the chrome. For instance my deployment is basically a fixed banner/toolbar and then the rest of the page is just a big-ass editor. Since it's so big, I actually set a max-width on the actual text area, so I have tons of real-estate to just always show the chrome, which should make tablets work pretty alright (do we (you) care about phones, or just tablets?).

[Gankra]

Actually, I guess we could also just make "always" be an option for the individual buttons?

[OscarGodson]

I like the states in your previous comment a bit more actually. autohide or just auto makes a lot more sense. You could also alias show to true and hide to false to make it a little more intuitive. But yeah, you can just update the button option to accept auto and make that the new default.

[Gankra]

I think with the chrome autohiding, you really want an all or nothing, so yeah I agree with you that the former is better.

[Gankra]

Done some more hacking. It seems that iOS5 basically broke the iframe standard. By default, it grows to fit its content, and there's no way to actually tell it not to. The only workaround I've been able to find is the -webkit-overflow-scrolling: touch; css property. Basically it flags the element as "natively scrollable" which makes everything work right.

HOWEVER this does not seem to do anything when applied to the actual body (or html). As such, it seems that a div inside the body is necessary as the contenteditable element with this style applied. Is this a feasible change, or will this break everything forever and get us murdered?

[OscarGodson]

So... I dont THINK it would be too crazy. In the _HtmlTemplates' var you'd add like editor and the div sort of how previewer is done. Then, instead of targeting the body you'd target that div for editing. The only issue I can think of off the top of my head, is the focus method would need to change probably a little. Also, if you typed one line and you blurred the editor and you clicked anywhere below that line on the iframe it wouldn't focus on the editing part. You'll need to make it so wherever you click on the editor it focuses on the the div.

[Gankra]

selection issue should be as easy as just removing all the padding/margins, and forcing 100% width/height no?

I was mostly worried about this break some assumptions users make about our structure. Sounds like it's not a huge problem (difference between body and div isn't particularly huge). I'll give it a shot today, see what I can come up with.

[OscarGodson]

Yeah, that should work, just was saying that's the only thing I can think of that'll need changes I think.

As for user assumptions, I'm not sure. I think getElement will have to be updated too to return the div and not the body like previewer. Cant think of why this would break anything, but we can bump the version number to be safe(r).

[Gankra]

Pretty decent mobile support can be achieved by setting autogrow:true and buttons.bar:false in the startup config. These are develop features right now, and not in stable.

[OscarGodson]

👍