◀ Merged tasks: T4702.

Had same complains and I think this feature will be reasonably useful.
Hopefully will be implemented any time soon.

This is my number one feature request for Phabricator. A long Wiki page is really hard to edit with the preview at the bottom of the screen. I've often used the Chrome inspector to 'munge' the CSS so I can see the preview on the right, which helps a little.

same here, this option would be quite useful.
Two independent scrollable views. one to write and one for preview.
This can be placed side by side in the white space when you comment task, create it or in Phriction pages.

Can i bump and add a thing ?

• this mode should be visible in a new button full screen + preview because if we go in the full screen edit it's for long edit

also how i can help ?

My attempt(s) yesterday focused around trying to stick the existing preview in the pertinent area via CSS.

My next attempt will instead create a new preview area in the DOM and have the preview behavior set the pertinent HTML for the existing preview and the preview I am building (2x). This struck me as dirty before, but after more than a few hours wrestling CSS I'm pretty sure this will be cleaner and less buggy.

Implementation wrinkle is differential, maniphest, conpherence (and possibly more) need implementation detail slightly different than the generic transaction technology. Nothing too major here but its not going to be as uber clean as one might like.

If the design is missing anything, let me know, though I think this is straightforward interaction-wise.

The only piece there is the "Document Preview" label is either going to be just "Preview" or something per object type, like "Comment Preview" or "Message Preview", etc. I figure that's NBD but I do plan to deviate there.

After thinking about this for a bit, I sort of question whether this is actually a very good solution. I think there are three root problems:

1. Poor preview behavior on mobile, mostly resulting from network performance (T1895).
2. You need to do a lot of scrolling when composing large documents, like Phriction pages (T7271).
3. No message preview in Conpherence (T8088).

This doesn't directly affect mobile and presumably isn't a usable view on mobile, so I think it doesn't solve (1). I think the fix there almost certainly needs to be a click-to-preview workflow, like the one described in T8088.

This is probably the right general way forward for T7271, but I think doesn't completely fix it. It will improve it a lot if the document is about a page long. If the document is more than a page long, I worry you'll need to independently scroll the preview and text input a lot to line them up. Making the preview scroll correctly automatically seems very hard (although maybe I'm overestimating the difficulty of getting this to feel "good enough"). I worry this approach may feel pretty bad for 3+ page documents without a lot more work to get the scrolling to line up. If we did that work, it seems like it would be better in all cases for editing large documents like Phriction pages and Legalpad, and that we'd be better off replacing the main editing UI with a 2-up UI rather than burying this UI so deeply.

This sort of works around (3), but it's fairly heavyweight, buried, and won't work on mobile.

If the fix to (1) is click-to-preview, building that (like T8088) and just defaulting to it in Conpherence seems cleaner than pursuing this?

Pursuing a 2-up view generally seems very hard to get right in the 3+ page document case.

I think you're right on 1), that we may need to pursue a click to preview for alternative cases like mobile. In regards to a 2-up view only being useful in Phriction/Legalpad, I'd probably disagree. Mostly, I don't know when or where I might want to spend an hour typing something out (comment, new task, Pholio, etc) so having something available everywhere would be my preference. In the basic sense, even if I have to manually scroll each window, it's still seems like improvement over the current situation. Or at least, I'd like to feel it out before deciding it was really bad.

Thought maybe this is also a lot more work that I thought to even test out, up to @btrahan.

I do think we can get the scrolling to work well, even if it feels pretty bad with the naive approach, but would have to do something like this:

• Add a trace/marker mode to the Remarkup engine.
• In this mode, each block element generates invisible start/end markers in the document based on which lines it generated from.
• In JS, we can then look at the scroll position / cursor position of the textarea, use the markers to figure out the corresponding pixel positions in the preview, and scroll appropriately.
• Some block-level elements could support cursor positioning within the element, too, although this would probably need to be element-by-element and I'm not sure how useful it would be.
• This could possibly extend into "Edit this paragraph" for Phriction, if the output could generate with line markers.
• But this is probably a huge amount of work.

Taking a step back here...

• I think users actually want a WYSIWYG editor. That said, I don't think its as actually valuable as the wants indicate and people wouldn't be particularly more effective or efficient with it after they learn remarkup; definitely very useful for new users. Mainly because I don't think people create content and format that content at the exact same time, and the overhead of scrolling to see the preview, clicking preview, etc really isn't that bad. Just to really hammer on this, I think people use their whole brain to think about the words they are writing, then switch to caring about how the words look and back again. Upfront, this switch may happen a bunch, but overtime the formatting bit is more mechanical. As an example, imagine building a table in Remarkup. I think people would check out the preview a bunch at the start, then get into a mechanical rhythm / trust the Remarkup directly and focus back on the content.
• Similarly, I think something like getting scrolling in the preview area is something we can punt on, despite users wanting it. The overhead of having to scroll that second area really isn't that bad, and as they keep on writing they won't be checking it out that often in the common case.
• I do like the fullscreen side by side thing conceptually; my kind-of-working-version feels good too.
• I think T1895 is an important problem out of scope of this task. To me, its most important to start queuing the drafting / preview requests, as I am pretty sure the phone gets overwhelmed with the per keystroke requests and slow internet.

I am sorry to have deleted the "B"....

• Because epriestley had to change it back?

Dear epriestley,

Is that an automatic error correction?

Kindly,
Brandon

No, I fixed it manually.

OK, I love you. Much love!