Change Details

NOTE: After deployment, Editing will conduct impact analysis to assess impact (T378775). Once analysis is completed, Editing and Web Team meet to align on next steps NOTE: E.g. might we broaden the scope of this change to include everyone editing in ve (T380336) and in doing so, prioritize work on building the API needed to do so in a reliable way that aligns with both teams' longer-term plans (T379444)? This task involves the work of introducing an externally-facing API or providing an opt in state (e.g. configurable conditional) to let extensions disable the sidebar. As requirements are refined we may need to allow consumers to know when the space the `Tools` and `Appearance` menus exist within (when shown) is occupied or not. This might look like an API would, among other things, enable the Editing Team to hide these menus ( T379443) and use the space they would otherwise occupy to present Edit Checks. It however could be as simple as defining and detecting a state where the sidebar should be disabled and allowing this state to be tweaked via configuration or hooks. === Story As someone who is a) opening the VisualEditor with [Suggestion Mode](https://www.mediawiki.org/wiki/VisualEditor/Suggestion_Mode) enabled using the Vector 2022 skin and b) who has the "Tools" and/or "Appearance" menu pinned/moved to the "sidebar", I want to be able to continue to access "Appearance" menu while I'm editing so that I can see how the changes I'm making might appear to people using the different font sizes available. === Requirements //TBD T379443// * when VisualEditor is opened the "end rail" (right in LTR) should be collapsed * when this state is entered it is impossible to pin items to the sidebar * when you leave editor mode the previous state will be restored. == open questions * when we say "use the space" do we mean render things in the area which the menus occupy (or do we mean within the content area that hiding the menus occupy * the request asks for a way to identify current state, could we expand this with use cases. Would a method that cleared out the sidebar in the event it is occupied be sufficient? * is restoring the sidebar state the responsiblity of the caller or the new method (e.g. perhaps it is based on a condition e.g. edit mode) * do we always want to collapse the sidebar or are there situations where we dont want to do this? * while the sidebar is collapsed is it possible to pin anything there via user interaction (my assumption is no)

NOTE: After deployment, Editing will conduct impact analysis to assess impact (T378775). Once analysis is completed, Editing and Web Team meet to align on next steps NOTE: E.g. might we broaden the scope of this change to include everyone editing in ve (T380336) and in doing so, prioritize work on building the API needed to do so in a reliable way that aligns with both teams' longer-term plans (T379444)? This task involves the work of introducing an externally-facing API or providing an opt in state (e.g. configurable conditional) to let extensions disable the sidebar. As requirements are refined we may need to allow consumers to know when the space the `Tools` and `Appearance` menus exist within (when shown) is occupied or not. This might look like an API would, among other things, enable the Editing Team to hide these menus ( T379443) and use the space they would otherwise occupy to present Edit Checks. It however could be as simple as defining and detecting a state where the sidebar should be disabled and allowing this state to be tweaked via configuration or hooks. === Story As someone who is a) opening the VisualEditor with [Suggestion Mode](https://www.mediawiki.org/wiki/VisualEditor/Suggestion_Mode) enabled using the Vector 2022 skin and b) who has the "Tools" and/or "Appearance" menu pinned/moved to the "sidebar", I want to be able to continue to access "Appearance" menu while I'm editing so that I can see how the changes I'm making might appear to people using the different font sizes available. === Requirements //TBD T379443// * when VisualEditor is opened the "end rail" (right in LTR) should be collapsed * when this state is entered it is impossible to pin items to the sidebar * when you leave editor mode the previous state will be restored. == open questions * when we say "use the space" do we mean render things in the area which the menus occupy (or do we mean within the content area that hiding the menus occupy * the request asks for a way to identify current state, could we expand this with use cases. Would a method that cleared out the sidebar in the event it is occupied be sufficient? * is restoring the sidebar state the responsiblity of the caller or the new method (e.g. perhaps it is based on a condition e.g. edit mode) * do we always want to collapse the sidebar or are there situations where we dont want to do this? * while the sidebar is collapsed is it possible to pin anything there via user interaction (my assumption is no) //Also see: T379444#10490697.//

NOTE: After deployment, Editing will conduct impact analysis to assess impact (T378775). Once analysis is completed, Editing and Web Team meet to align on next steps NOTE: E.g. might we broaden the scope of this change to include everyone editing in ve (T380336) and in doing so, prioritize work on building the API needed to do so in a reliable way that aligns with both teams' longer-term plans (T379444)? This task involves the work of introducing an externally-facing API or providing an opt in state (e.g. configurable conditional) to let extensions disable the sidebar. As requirements are refined we may need to allow consumers to know when the space the `Tools` and `Appearance` menus exist within (when shown) is occupied or not. This might look like an API would, among other things, enable the Editing Team to hide these menus ( T379443) and use the space they would otherwise occupy to present Edit Checks. It however could be as simple as defining and detecting a state where the sidebar should be disabled and allowing this state to be tweaked via configuration or hooks. === Story As someone who is a) opening the VisualEditor with [Suggestion Mode](https://www.mediawiki.org/wiki/VisualEditor/Suggestion_Mode) enabled using the Vector 2022 skin and b) who has the "Tools" and/or "Appearance" menu pinned/moved to the "sidebar", I want to be able to continue to access "Appearance" menu while I'm editing so that I can see how the changes I'm making might appear to people using the different font sizes available. === Requirements //TBD T379443// * when VisualEditor is opened the "end rail" (right in LTR) should be collapsed * when this state is entered it is impossible to pin items to the sidebar * when you leave editor mode the previous state will be restored. == open questions * when we say "use the space" do we mean render things in the area which the menus occupy (or do we mean within the content area that hiding the menus occupy * the request asks for a way to identify current state, could we expand this with use cases. Would a method that cleared out the sidebar in the event it is occupied be sufficient? * is restoring the sidebar state the responsiblity of the caller or the new method (e.g. perhaps it is based on a condition e.g. edit mode) * do we always want to collapse the sidebar or are there situations where we dont want to do this? * while the sidebar is collapsed is it possible to pin anything there via user interaction (my assumption is no) //Also see: T379444#10490697.//