#903: Side Panel

Visit on Github.

Opened Sep 26, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of Side Panel.

Modern browsers have a side panel that can be used to display additional information about the current page or provides a way to browse side-by-side. This proposal aims to standardize the side panel and its API. The new side panel API will allow developers to declare support for the side panel and to control their web content in the side panel.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future):
  • The group where standardization of this work is intended to be done: webapps
  • Existing major pieces of multi-stakeholder review or discussion of this design: N/A
  • Major unresolved issues with or opposition to this design: N/A
  • This work is being funded by: Microsoft Edge

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

Discussions

Discussed Oct 16, 2023 (See Github)

Peter: i've seen it...

Yves: is it related to document picture-in-picture?

Rossen: I think it's fairly different - intent is to allow you to have context between different apps...

Dan: this seems like a browser feature...

Peter: being able to detect you're in a side panel.. maybe makes sense... Not sure how you would get into a side panel...

Rossen: any pwa that wants to do this... how do you do it? this is the propoosal they have to achive that capability in a pwa...

Peter: if I put in my manifest that yes I can go into a side panel - how would I then be put into a side panel? how would i request to be put into a side panel? I don't see that in the explainer...

Dan: they say in Non-goals that it's not from different origins- but the example they have shown appear to show 2 different origins...

Peter: the intention .. e.g. you click on an email link and email app appears in a side panel - those are 2 different origins... I can see a need to target a side panel but I don't see that in the proposal...

<blockquote> Hi! Thank you for sending this our way. We're not sure exactly about the use cases? You've listed a non-goal of displaying content from different origins but the example seems to show content from different origins. Also there's no specified way to target content to a side panel or to trigger content coming up in a side panel. Basically can you elaborate on the use cases a bit? </blockquote>
Comment by @plinss Oct 16, 2023 (See Github)

Hi! Thank you for sending this our way. We're not sure exactly about the use cases? You've listed a non-goal of displaying content from different origins but the example seems to show content from different origins. Also there's no specified way to target content to a side panel or to trigger content coming up in a side panel. Basically can you elaborate on the use cases a bit?

Comment by @benjycui Oct 20, 2023 (See Github)

I created a PR to update the explainer https://github.com/MicrosoftEdge/MSEdgeExplainers/pull/700/files

The confusing non-goal had been updated to:

Allowing a site to declare a side panel app of a different origin (e.g. contoso.com cannot declare a side panel app for fabrikam.com).

Side panel API is designed to be used by web developers when they want their web application can be promoted and detect being rendered in side panel.

If developers want to access left-side web content from a side panel app, they should use Extension.

If developers want to install a web application to side panel, they should use Web Install API.

Discussed Dec 18, 2023 (See Github)

Ready to be worked on.

Discussed Jan 1, 2024 (See Github)

Lea & Tess: we already have window.open so why are we re-inventing something new

Tess: Why isn't this a target?

Matthew: it's something that's separate to the other site... This is for a seperate web app which isn't related to the site... Goals are to app promoted as a side-by-side web app... other goal: whether they're rendered in a side panel. Wouldn't that be a media query? Why would they want it to behave differently because it's in a side panel?

Tess: If we need anything at all it should be in the manifest... ok optimise appearance & behaviour -

Matthew: the behaviour - if a side panel app is designed to allow you to perform some specific flow .. it could be useful to go to that flow?

Lea: this is an API so developers can expose things in the Edge feature... This actually reminds me of a more general issue... There should be a way for people to agree on what an API should look like ... platforms that do want to implement...

Tess: anyone can write a spec.... They're adding a display override field... that doesn't feel right. That looks weird to me. The name side panel feels very specific to Edge's proprietary feature. We need a generic name.

Lea: agree to that.

Matthew: one is discoverability - marketed to the user as being suitable for a side panel...

Tess: feels wrong... this is just another web view that happens to be a different width... we have responsive design.

Matthew: varying the behaviour -- app running in the side panel doesn't have back-and-forth... Seems like another thing you could have done a different way.

<blockquote>

Hi there, @hober, @torgo, @matatk, and I looked at this today during a breakout at our London F2F.

We have some concerns that the way this feature is designed overfits to Edge's specific side panel feature. We generally prefer Web platform features to be designed in a more general way to be able to encompass different designs for the same purpose, including designs that may conceivably emerge down the line.

Furthermore, we are not 100% sure that a new feature is needed at all. Adapting the UI design of the app for the smaller viewport can be done with existing web platform primitives. Is there something fundamentally different about this use case that requires a new display mode, and if so, what is the core of it? If we understand what is fundamentally different about this display mode over others (either existing, or potential future extensions) we may be able to give you more actionable design advice.

</blockquote>
Comment by @LeaVerou Jan 23, 2024 (See Github)

Hi there, @hober, @torgo, @matatk, and I looked at this today during a breakout at our London F2F.

We have some concerns that the way this feature is designed overfits to Edge's specific side panel feature. We generally prefer Web platform features to be designed in a more general way to be able to encompass different designs for the same purpose, including designs that may conceivably emerge down the line.

Furthermore, we are not 100% sure that a new feature is needed at all. Adapting the UI design of the app for the smaller viewport can be done with existing web platform primitives. Is there something fundamentally different about this use case that requires a new display mode, and if so, what is the core of it? If we understand what is fundamentally different about this display mode over others (either existing, or potential future extensions) we may be able to give you more actionable design advice.

Comment by @benjycui Jan 26, 2024 (See Github)

Thanks @LeaVerou

Adapting the UI design of the app for the smaller viewport can be done with existing web platform primitives.

There is an existing issue discussing about this https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/692

Is there something fundamentally different about this use case that requires a new display mode, and if so, what is the core of it?

That side panel might not provide UX like a browser tab/window is the reason why web page needs side-panel mode , e.g., side panel might not provide omnibox and back/forward button, so web applications need to provide other way to navigate around.

It is recommended to detect windows' width if styles or behaviors are not side panel only.

Comment by @LeaVerou Jan 27, 2024 (See Github)

That side panel might not provide UX like a browser tab/window is the reason why web page needs side-panel mode , e.g., side panel might not provide omnibox and back/forward button, so web applications need to provide other way to navigate around.

This does not seem specific to side panels, the same thing applies in other contexts, e.g. certain window.open() calls.

Comment by @novac42 Feb 20, 2024 (See Github)

@LeaVerou appreciate the feedback. A main difference is the context: sidebar PWA has a special UA to inform the app that it's being rendered in a sidebar of a main browser window. Therefore, developer could leverage this to dispatch more lightweight content that fits the sidebar, in that case sidebar PWA serves as a minimalist gateway to extensive content. For example, an onboarded developer made a TikTok-style channel consists of short clips of its original movie/TV shows, and if users watched the short clip in sidebar, they could click on the title and start watching full length video in main browser window.

Discussed Mar 18, 2024 (See Github)

Matthew: Sounds like they're saying that Side Panel detection is needed becuase the content is philosophically different (per the stated example).

Peter: This still feels like a UA feature (like split tabs). Let's see which other browsers want to do this (if any) before we figure out how to standardize it.

Matthew: ACK.

Yves: Do they link to positions from other browsers?

Peter: No response from WebKit. There is a WICG proposal; doesn't seem to be active.

<blockquote>

Thanks @benjycui for your request, and to you and @novac42 for your answers to our questions. It looks like there isn't active community engagement with this proposal at the moment (please point us in the right direction if we've missed anything) - so we are closing this for now. However, if the community picks up on this work in future, please feel free to re-open.

</blockquote>
Comment by @matatk Mar 18, 2024 (See Github)

Thanks @benjycui for your request, and to you and @novac42 for your answers to our questions. It looks like there isn't active community engagement with this proposal at the moment (please point us in the right direction if we've missed anything) - so we are closing this for now. However, if the community picks up on this work in future, please feel free to re-open.