Provide the ability to wrap the entire page with a border when opening off-canvas in the top position

In windows high-contrast mode, the 40px border would look very drastic. I'm wondering whether something like an extra page wrapper with a dark grey background, with a mixure of 38px padding and/or margin, plus a 2px dark-grey bordern would be better. It would look just the same in a the full colour space, but in windows high contrast mode you'd have some empty space, and a less drastic border.

In general this is a good idea, for the reason mentioned: to make it clear that what you are doing impacts the whole site.

re #4 I get you, about the CSS properties used. I'm trying to understand what the UI is supposed to be telling you, so I can think about how to convey that inclusively.

Even if the thick border was just padding/margin, you'd still have the background-color difference. In the full colour space, the "website" part would be a different colour to the empty grey "border" surrounding it. But when a Windows high-contrast theme is being used, it would just look like the content got shrunk. There would be no background colour difference. If the thick border was intended to convey information, then it's a failure of WCAG "use of color".

I think the problem/motivation needs work - what does the thick grey border convey, and what does that have to do with workspaces?

"Site-wide impact" doesn't sound like it's specific to Workspace UI. Let's say I don't have any workflow/workspace modules installed at all, but I do have Settings Tray. If I use the Contextual links to edit a block title in the sidebar, that affects the whole site, but it's nothing to do with workspaces.

So what's different about workspaces that can be conveyed by a thick grey border? How would we convey that to a blind person, using a screen reader, or a sighted person using Windows high-contrast mode?

Edit: Sorry, this was a bit of a rant. My concern is that whitespace can't convey anything specific, it's just a vague separator.

I think the border does help convey the meaning to sighted users. I also believe the content and behavior of the tray itself (as read out) should convey that too. It says you are making a workspace live, etc. The border "just" underscores that, it should not be the only way where this is conveyed and I don't believe it is the only way.

As to where to put it. I think if we want to have common interaction patterns then off-canvas trays opening from the top should have distinctly different roles than trays opening from the side. Looks like we already made the decision that stuff typically used to touch up on things will open from the side and stuff doing more major things will open from the top. I think its fine to encode that assumption in the default styling of the top tray. (People can still undo it if they really want). Given how this affects the reusability of an API item, this could use framework manager feedback as well.

fwiw, I don’t think this should be part of the off-canvas library. This looks like an implementation detail that is specific to workspaces, and it should be implemented there.

What if we added another data attribute data-dialog-mode or data-dialog-consumer.

Then when an off-canvas dialog is open this would be automatically passed on to the data-off-canvas-main-canvas element.

So then if workspaces wanted to provide visual border it could just use CSS to target.

[data-off-canvas-main-canvas][data-dialog-consumer='workspaces']

This would have actually been use in Settings Tray because we could have controlled edit mode in the same manner.

On the other hand if we want all uses of the top try to have the "site-wide impact" effect then would just pass on the data-dialog-render and data-dialog-renderer on to the data-off-canvas-main-canvas element.

Then you could simply target [data-off-canvas-main-canvas][data-open-dailog='dialog.off_canvas_top'].

Of course maybe we should be setting these as CSS classes.

@drpal: what is different between a top off-canvas library and a side off-canvas library then? should we not be opinionated about what each are for, so its not "randomly picked" based on module developer preference? :)

like, for example, a classic dialog as used in views for example is quite opinionated about graying out the background and disabling controls there, its not just "some markup displayed above the page (that could have just as been side of page)", it has certain styling and behavior to guide its use

@tedbow - I'm not sure I fully follow what you're saying, but I like the idea of this being an opt-in feature

@timmillwood sorry for not responding sooner.

I think as far as "the ability to wrap the entire page with a border" you could do this right now.

One way

1. add an option to data-dialog-options like drupalIsWorkpace: true.
2. In the JS dialog:beforecreate event check for this option and Drupal.offCanvas.isOffCanvas($element) and add a class to [data-off-canvas-main-canvas] element that provides the border. You also want remove the class here if drupalIsWorkpace: true is not set set because dialog:beforeclose is not guaranteed to be called.
3. In dialog:beforeclose remove the class from [data-off-canvas-main-canvas] element.

That would be Workspace specific way. I do think though that this is probably something that should be provided by the off-canvas library if we are going to do it because we don't contrib modules trying to do something similar but it looking slightly different.

So it seems like the 2 options are:

1. Always add the border when using off_canvas_top.
2. Add the border on a boolean option like drupalSiteShrink in data-dialog-options.

If we want to do 1) I think we need to do it before 8.6.0 because #2916781: Allow off-canvas dialog to be rendered at the top of the page was not committed to 8.5.x. So no sites should be using the top dialog yet. Once they do I think automatically adding the border when using the top dialog would be BC break I think because sites would using it without the behavior.

UPDATE: I guess 3rd option I just thought of would be to do

Always add the border when using off_canvas_top.

but with a boolean option like drupalNoBorder in data-dialog-options to not do the border. This would mean that we are encouraging it but if they have a dialog that don't want it on they could remove it.

I like that because really they could remove it anyways either through CSS that overrides ours or by removing the class in their own dialog:aftercreate event listener. Giving the option to remove would hopefully ensure that we don't have multiple contrib modules removing it different possibly conflicting ways.

I like this 3rd option best

Adding reference to Windows High Contrast Mode.