Explore a replacement for display rather than merely an override list

[mgiuca]

Proposed by @mounirlamouri on the corresponding blink-dev intent-to-prototype thread. I am moving the discussion to GitHub.

The summary is that Mounir wants to treat display as legacy (providing a mechanism to continue supporting it as a fallback for legacy browsers, but gradually fade it out), with a new display fallback list being the new way to specify display. (As opposed to the current proposal, which keeps display as the end of the fallback chain, with display_override being a list of things to try before falling back to display.)

Mounir's plan would make display eventually obsolete, while Daniel's current plan would keep display as part of the algorithm forever.

Details are in the above thread.

[dmurph]

I'm actually ok with this. I think the logic would be the same, except that display would no longer be required to be a webapp.

maybe this could mean a different name for the field? Any suggestions?

[mounirlamouri]

Thanks for filing @mgiuca. To summarise, the gist of my feedback is that the proposed API is a bit odd and is designed this way to improve backward compatibility. My suggestion was too look for the ideal API and walk back how we can make it backward compatible. UA should be able to make the transition smooth. It may mean that for some time (transition period), there will be two properties that authors will have to put on their Manifest but whenever completely dropping support of display will be safe, the end result may be a bit easier for authors to wrap their head around.

With regards to naming, I suggested display_list on blink-dev because it's clear what it is. I agree with @dmurph that a new name would be needed if we go this way because display_override would no longer apply.

[dmurph]

I mentioned this in both the Tag review request & the section here.

[mgiuca]

For starters, some generalities:

the proposed API is a bit odd and is designed this way to improve backward compatibility. My suggestion was too look for the ideal API and walk back how we can make it backward compatible. UA should be able to make the transition smooth. It may mean that for some time (transition period), there will be two properties that authors will have to put on their Manifest but whenever completely dropping support of display will be safe, the end result may be a bit easier for authors to wrap their head around.

That isn't usually how web APIs are designed / evolved. We don't generally look for the ideal API and then have a transition period. We almost always extend existing APIs in ways that are totally backwards compatible, allowing existing sites to continue working exactly as they are, but offering new sites new features. The web platform doesn't generally deprecate and eventually remove old APIs in favour of slightly more ergonomic ones. Long-term stability is considered more important than small ergonomic improvements. (When you do have major ergonomic improvements, such as fetch over XMLHttpRequest, those are generally a totally new API, offered as an alternative, and the old one is unfavoured but usually never removed, and if it is, as in the case of Appcache, on the order of a decade after deprecation.)

Basically, if it's a huge ergonomics win, deprecate-and-replace is OK. But for slight ergonomics improvements, just stick with full backwards compatibility. The churn is not worth it.

Now as to the specifics:

I think the difference between dmurph's proposed API and mounirlamouri's proposal definitely qualifies as "slight ergonomics win", not worthy of a decade-long deprecation plan.

@mounirlamouri (on email):

I think that the opinion to keep using display makes the API shape very odd and even if it makes sense today will seem very confusing soon enough and sound like a weird relic of the past. Keeping display as mandatory for ever will also require it to be set to a value that will have to be backward compatible which on top of an odd API makes the end result not as flexible as it was intended.

I don’t think it’s going to be as odd as you make it out. I anticipate the vast majority of PWAs will want to use one of the existing display modes (typically, standalone). The display_override will be for a) “special” modes that don’t fit into the fallback chain, like tabbed application mode, and b) customizing the fallback chain. So our documentation for a basic PWA will be “display: standalone” and not mention display_override at all. You’ll use display_override if you want something outside of the basic model.

On the other hand, if we introduce a replacement for display, then during the interim period (which, again, should be 5-10 years), there are several points of confusion:

• All PWA "getting started" documentation will have to be updated. Users getting started with PWAs will find out-of-date documentation with conflicting advice.
• Tutorials (at least until all major browsers support the new feature — admittedly that's not a 5-year window but it could well be a 1-year window) will have to tell people to redundantly include both the old and new.
• Developers of existing sites, who already understand display, may not understand what display_list is, or why there are two attributes that do the same thing, and why we are (temporarily) requiring both to be set to the same value.
• When the time comes to remove display, there will be a long tail of old sites that haven't been updated, and will break. It will be easier to never remove it, so it will probably just hang around forever, meaning we're supporting two ways to do the same thing forever.

Therefore, I'm strongly in favour of just explicitly framing this as "basic mode" (display) and "advanced mode" (display_override) and not starting a long deprecation project. I'm not particularly wedded to the name display_override. We could go back to @amandabaker's original display_modifiers name.

To be clear, I don't think this is the ideal API that I would've designed from scratch. But it's a perfectly reasonable design, given that the alternative is deprecation.

The benefit of a new attribute and a deprecated attribute is that when everyone has moved on to the new attribute, all UAs can just stop supporting the other one and no one will ever hear about it. Education via tooling, articles, console warnings can reduce the chances of websites simply dropping display in favour of the new attribute.

I'd rather not commit resources to tooling, articles and console warnings if there's no clear benefit. Again, deprecation is possible on the web, but it's a long road, and best reserved for things that are actively bad for the user (like security or DOS vectors), or extremely complex and un-ergonomic (like Appcache). In the common case, we extend, rather than replacing.

[dmurph]

That's a great explanation @mgiuca, thanks for typing that all out. I didn't think about all of the documentation that we (and others) have out there, as well as example.

I think phrasing this as "basic" vs "advanced" mode for setting the display is a great way of explaining this.

We could still allow a manifest to NOT have a display property if it has a display_override property, but in a way I feel like that makes it more complicated. So I'm in favor of keeping the explainer the way it is.

I agree & think trying to 'deprecate' display is definitely not worth it at all.