Last modified: 2014-10-27 00:17:39 UTC
The recent gerrit change I743ed45e (which fixed bug 25830) reminded me that the "ajaxPreviewScrollTop" option from https://en.wikipedia.org/wiki/User:Js/ajaxPreview is very useful, because using it we can avoid unnecessary scrolling when using the preview button several times during an edit (e.g. while typing a long math formula). Please provide a similar option for the default live preview from MW.
How do you think this should be implemented? As another checkbox in Preferences (which are already overcrowded), as a button around the edit form (which is overcrowded as well), or as a hidden option one can change in common.js? I can't say I like any of these options... :)
This is not the kind of thing that should be an option in usable software. It is either found to be an improvement or not. Also, if I understand correctly I743ed45e implements this as the default behavior. Assuming I misunderstood, what is the request here?
This "ajaxPreviewScrollTop" option of the linked script[1], does: > if (window.ajaxPreviewScrollTop) wkPreview[0].scrollIntoView() Change I743ed45e: > $wikiPreview[0].scrollIntoView(); [1] https://en.wikipedia.org/wiki/User:Js/ajaxPreview https://en.wikipedia.org/wiki/User:Js/ajaxPreview.js
Okay, summary has been improved. The request is to have a way to disable the automatic scroll towards the preview area. Can you provide a use case for that? Why would a user not want to see the preview after clicking the button to generate that very preview?
Maybe writing a long article, and previewing to see if what you just wrote at the end works correctly? I think that scrolling should be the default, though.
That is a per-article (or rather, per-edit attempt) use case. That doesn't make it less valid, it is a perfect use case. But that does mean we should keep in mind that if and when we implement an option for it that it not be in the user preferences. Because I think in most cases it should scroll. Also, there is a usability problem when not scrolling to the top because when altering anything other than the bottom of the article, it appears nothing happens when one clicks "Show preview". The scrolling to the top (and appearance of the spinner and fading also help) indicate that something happened and that it finished happening.
Most of the time the content I'm editing is in the end of the page or section, so it is handy to be able to see both the previewed text and the edit box so that I can see the result of my changes. This is even more useful when I'm editing articles related to math, where I would add LaTeX formulas. Maybe this could be implemented by means of hook (bug 23580?) or the code $wikiPreview[0].scrollIntoView(); could be moved to a function publicly accessible so that users could redefine it to a dummy "function(){}" (instead of copying the whole "window.doLivePreview").
