#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

2023-10-16

Minutes

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>
2023-12-18

Minutes

Ready to be worked on.

2024-01-london

Minutes

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>
2024-03-18

Minutes

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>