Change Details

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. === Requirements //TBD by {{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)

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. === 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)

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. === Requirements //TBD by {{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)