Edgewall Software
Modify

Opened 10 years ago

Last modified 21 months ago

#9619 reopened defect

Side-by-side editing fails if Preview significantly longer than source; needs smart, vertical locking!

Reported by: klein@… Owned by: Christian Boos
Priority: low Milestone: 1.0
Component: wiki system Version: 0.12-stable
Severity: major Keywords: side-by-side
Cc: Branch:
Release Notes:

Improved side-by-side Wiki page editing by making the editor side or the preview side scrollable (whichever is taller)

API Changes:
Internal Changes:

Description

The side-by-side editing is rendered useless, if the Preview is significantly longer (due to large text, tables and inline images) than the source code. You might end up in a situation where the related source code to what you currently see in the Preview is 1 or 2 pages up the screen and it is currently impossible to see source code and related Preview together at once. This is a serious issue in my opinion.

You can make a simple test by positioning a few large images using [[Image(XYZ.jpg)]] underneath each other: The source code only takes a few lines, whereas the last image might by two screens down the window scroll bar.

A solution should look like this: The preview get dynamically positioned in such a way, that it (optionally) aligns vertically with the cursor position in the source code window, so that one really sees what one's editing.

Attachments (0)

Change History (11)

comment:1 by Christian Boos, 10 years ago

Component: generalwiki system
Milestone: next-major-0.1X
Priority: highlow

Sure, that would be a nice improvement. But to say this defect makes the side-by-side editing useless is a bit exaggerated: by the same measure, it would mean that the "normal" preview (vertically stacked edit on top of preview) is useless, as you also can't see both what you type and the preview in that mode, except for very small texts.

Implementation idea: send the cursor offset; (WikiDom) have a function to retrieve the node corresponding to that offset, find the closest previous node with an id, send back the preview + that id; in the browser, update the anchor to that id.

comment:2 by Christian Boos, 10 years ago

(and btw., the workaround I use in this situation is to disable the macros while doing the bulk of editing i.e. [[xxxImage(...)]]; not optimal but works well most of the time)

in reply to:  1 comment:3 by klein@…, 10 years ago

Replying to cboos:

Sure, that would be a nice improvement. But to say this defect makes the side-by-side editing useless is a bit exaggerated: by the same measure, it would mean that the "normal" preview (vertically stacked edit on top of preview) is useless, as you also can't see both what you type and the preview in that mode, except for very small texts.

Well, side-by-side is definitely an improvement over the normal vertically arranged preview, but still: I soon as you begin embedding pictures or a formatted structure with headlines etc. you are entering the scroll-wheel hell and as longer the page becomes, as more difficult it becomes to find what you want to edit (it also would be nice if we'd see paragraph-limited editing similar to Wikipedia).

comment:4 by anonymous, 10 years ago

It would be great if the preview automatically aligned to what you are editing, but, simply, adding scroll bar to the preview area may work so that user can operate independently the source and the preview.

comment:5 by anonymous, 9 years ago

Solving this issue would be a very useful and time preserving enhancement!

comment:6 by Christian Boos, 9 years ago

Milestone: next-major-releases1.0
Resolution: fixed
Status: newclosed

As this was also a feature request from coworkers, I had a try, and as I was quite pleased with the results, I committed the fix in r11109.

Either the textarea or the wikipage preview expands to its natural height (whichever is shorter) and the other adapts accordingly and gets a scrollbar.

Tested with all browsers at my disposal IE9, Chrome 21, FF 13, Opera 12 and Safari 5.1.7 (Windows).

comment:7 by Christian Boos, 9 years ago

Owner: set to Christian Boos

comment:8 by Christian Boos, 8 years ago

Release Notes: modified (diff)

Note that this still doesn't work correctly in the presence of images (or other kind of delayed content)…

in reply to:  8 comment:9 by Christian Boos, 8 years ago

Resolution: fixed
Status: closedreopened

Replying to cboos:

Note that this still doesn't work correctly in the presence of images (or other kind of delayed content)…

SO:910727http://api.jquery.com/load-event/ (the Caveat about img) and https://github.com/desandro/imagesloaded or https://github.com/alexanderdickson/waitForImages. Need to experiment a bit…

comment:10 by Christian Boos, 8 years ago

And even with no images, you can still have a "jump", moving your cursor out of sight. For example, when editing at the bottom of the text area and you delete some content.

comment:11 by figaro, 5 years ago

Severity: criticalmajor

Modify Ticket

Change Properties
Set your email in Preferences
Action
as reopened The owner will remain Christian Boos.
The ticket will be disowned. Next status will be 'new'.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from Christian Boos to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.