Rework resizing of the problem editor.#2954
Open
drgrice1 wants to merge 1 commit intoopenwebwork:WeBWorK-2.21from
Open
Rework resizing of the problem editor.#2954drgrice1 wants to merge 1 commit intoopenwebwork:WeBWorK-2.21from
drgrice1 wants to merge 1 commit intoopenwebwork:WeBWorK-2.21from
Conversation
The code and rendering panels are now not only vertically resizable, but are horizontally resizable when the window with is at or above the large breakpoint (992 pixels). Furthermore, resizing does not work with the native browser resize via the css `resize` property. Instead it is controlled with JavaScript. The resize grips (which are much more visible now) can be also be focused with the keyboard and when focused the arrow keys can be used to resize the code and render panels. Note that if `Ctrl` is pressed with an arrow key a 1 pixel resize occurs, and if `Alt` is pressed with an arrow key a 50 pixel resize occurs. Without a modifier key the arrow keys perform a 20 pixel resize. In addition, the dimensions are saved to local storage and persist when the page reloads. Unfortunately there will be some flickering of content as the resize occurs after the page loads. Note that the css `resize` property is actually not supported in all browsers, so this actually makes resizing work for those browsers as well. The browsers that do not support the css `resize` property include Firefox for Android, and Safari on IOS. Yeah, those are for mobile devices, and who edits problems on a mobile device? In any case, this makes the resize grips more evident. The native resize grip is rather small in the lower right corner of the CodeMirror editor panel, and many probably don't even know it is there. Note that the code panel has a minmimum width of 400 pixels, and the rendering panel a minimum width of 300 pixels. This works out so that when the window size is 992 pixels the two panels can't really be resized much or at all (when the site navigation menu width of 250 pixels is taken into account) depending on the browser. But at larger window widths resizing can be done. I thought about making it so that the resizing could go all the way to the right and the rendering panel be resized to a width of 0, but decided against it. If that were done, then the rendering would still be occuring even though you can't see it, and that doesn't seem good. I think that this should at least alleviate the request(s) to hide the rendering panel (which I don't think is really a good idea).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The code and rendering panels are now not only vertically resizable, but are horizontally resizable when the window with is at or above the large breakpoint (992 pixels).
Furthermore, resizing does not work with the native browser resize via the css
resizeproperty. Instead it is controlled with JavaScript. The resize grips (which are much more visible now) can be also be focused with the keyboard and when focused the arrow keys can be used to resize the code and render panels. Note that ifCtrlis pressed with an arrow key a 1 pixel resize occurs, and ifAltis pressed with an arrow key a 50 pixel resize occurs. Without a modifier key the arrow keys perform a 20 pixel resize.In addition, the dimensions are saved to local storage and persist when the page reloads. Unfortunately there will be some flickering of content as the resize occurs after the page loads.
Note that the css
resizeproperty is actually not supported in all browsers, so this actually makes resizing work for those browsers as well. The browsers that do not support the cssresizeproperty include Firefox for Android, and Safari on IOS. Yeah, those are for mobile devices, and who edits problems on a mobile device? In any case, this makes the resize grips more evident. The native resize grip is rather small in the lower right corner of the CodeMirror editor panel, and many probably don't even know it is there.Note that the code panel has a minmimum width of 400 pixels, and the rendering panel a minimum width of 300 pixels. This works out so that when the window size is 992 pixels the two panels can't really be resized much or at all (when the site navigation menu width of 250 pixels is taken into account) depending on the browser. But at larger window widths resizing can be done.
I thought about making it so that the resizing could go all the way to the right and the rendering panel be resized to a width of 0, but decided against it. If that were done, then the rendering would still be occuring even though you can't see it, and that doesn't seem good. I think that this should at least alleviate the request(s) to hide the rendering panel (which I don't think is really a good idea).