Editor font size

[Dani]

After receiving some complaints that the editor font size was too small, I went ahead and significantly increased it to mimic live posts. What do you think? Is it better now or too big?

[~s.o.s~]

Looks a lot more prominent now. Any way you can make the preview of the same size?

BTW, not sure if you know this but fenced code blocks don't produce preview and work differently than native code tags. For e.g. fenced code blocks with Python/Py language looks different than the the code produced using indentation in the Python forum.

[Dani]

Yes, I know. Fenced code blocks are incredibly buggy. That's why I'm kinda discouraging their use.

[~s.o.s~]

In that case, it was a wise choice to remove them from the 'formatting help' section. Also, please look into making the preview text same size as the posted text and having demarcation between the post text and the preview text. Right now the preview text seems to float between the text area and the submit button.

EDIT: I would also like to raise a feature request in case it already isn't in the queue: ask user for confirmation before moving out of the current page in case he has something written in the post body. That would prevent accidental close of the tab or a refresh from losing the contents of the post body.

[Dani]

It makes no sense to me to make the preview text any bigger. There should be no reason that it needs to be read. Not only did you just write it so you already know what it says, but the editor itself is now much larger. The only reason it is there is so that you can see formatting.

I am actually considering getting rid of the preview entirely because I can't seem to get it to match entirely with the way posts ACTUALLY render (so that makes it very confusing), and also because there have been a few complaints that it lags.

[Dani]

Also Sanjay, since both your requests are in line with SO, Since you already went there, I might as well finish. SO makes the editor in a small font and the preview in a large font. We do the opposite. I think having both big is silly ;)

[~s.o.s~]

It makes no sense to me to make the preview text any bigger. There should be no reason that it needs to be read. Not only did you just write it so you already know what it says, but the editor itself is now much larger. The only reason it is there is so that you can see formatting.

I guess I'm the weird one out here who looks at the preview text when composing posts instead of the the text area. :)

I am actually considering getting rid of the preview entirely

That would be a bad move IMO, especially given there is no "preview" button. It would force me to write Daniweb posts in the SO markdown editor area and then post them to Daniweb. :/

Any reason it is so difficult to get something like SO preview window for Daniweb? The editor itself seems to be open source given that OSQA (a SO open source clone) uses the same editor. Assuming the current preview window is something you designed from scratch, there is no reason why you folks (James and you) can't take inspiration from that code. :)

Also Sanjay, since both your requests are in line with SO

Ooooh, I swear I didn't have SO in mind. ;) But seriously, confirming before exiting page is a real lifesaver feature. Not compulsory but really good to have to reduce frustrations.

[Dani]

That would be a bad move IMO, especially given there is no "preview" button.

I would create a preview button instead. IMO, it's a big problem in that we use one parser on the backend and a different (Javascript) parser on the front end. I would get rid of the Javascript parser in exchange for having a preview button that updates using AJAX using the same backend parser, so the preview would look exactly like it will end up looking. The difference being that, because it would need to talk to the server in order to fetch the preview, it wouldn't be a realtime preview but would just work off of a button ... but would be an EXACT rendition of what it will ultimately look like.

I'm not sure what you mean by preview window????

[~s.o.s~]

Preview window as in the entire arrangement: the text area + the view showed below. Apart from SO, I also frequent a site which uses OQSA and the markdown editor there just works. My suggestion was that if you can take a peek at that code, you might be able to understand how they end up with a responsive Javascript driven editor.

[Dani]

We use the same Javascript preview script as SO does, although I tweaked ours a bit given our custom featureset. The problem is that every single markdown parser handles edge/corner cases slightly differently.