Intent to Implement: Toast UI element
1,002 views
Skip to first unread message
Jack Steinberg
Jun 12, 2019, 11:46:07 AM6/12/19
to blink-dev
Contact emails
jackst...@chromium.org,dom...@chromium.org,fer...@chromium.org
Explainer
https://github.com/jackbsteinberg/std-toast
(No spec yet)
TAG review
https://github.com/w3ctag/design-reviews/issues/385Summary
Introduces a standard, customizable toast notification HTML element, and a JavaScript API to provide easy use for common cases.
Motivation
Modern web applications have grown in the scale of what actions they can offer, to the point where clear feedback is an essential part of a complete, accessible web experience. Toast UI elements are a common way to provide this feedback, and a variety of libraries exist to provide toasts. Creating a built in toast would allow those libraries to layer their implementations on top, and allow web developers to use a simple, unopinionated toast without having to bring a new library into their project.
Risks
Interoperability and Compatibility
The interoperability risk comes from the potential that other browser vendors don't see the benefit of building this into the web platform. We hope that by implementing and iterating with web developer partners, we will be able to determine the value of this effort and make the benefit clearer.
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: Positive (previously expressed privately; we've encouraged them to make their interest public on the WICG thread)
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes
Tentative tests are being added in the /std-toast folder of Web Platform tests, and will land alongside toast CLs in Chromium. (None have landed yet, but watch https://wpt.fyi/results/std-toast.)
Link to entry on the Chrome Platform Status
Chris Harrelson
Jun 12, 2019, 11:57:39 AM6/12/19
to Jack Steinberg, blink-dev
Hi Jack,
What paint order do you think should apply to a toast? Same question goes for containing block. I see that you have thought about how to indicate stacking order of the toasts, but what about other content?
Chris
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEYN2j4Ps3F%2B_SxjiP%2BE1SFUaSVO_aG8nBbOcPvsSSxaMdgo3g%40mail.gmail.com.
Domenic Denicola
Jun 12, 2019, 12:36:21 PM6/12/19
to Chris Harrelson, Jack Steinberg, blink-dev
From: Chris Harrelson <chri...@chromium.org>
> Hi Jack,
(Jack is on a plane and asked me to reply in his stead.)
> What paint order do you think should apply to a toast? Same question goes for containing block. I see that you have thought about how to indicate stacking order of the toasts, but what about other content?
We're unsure on the best path forward here, and definitely looking for feedback from implementers and web developers.
One strategy is minimal: the toast has a UA default style of z-index: 1, and then developers are given guidance to generally place it as the last element of their <body>---plus the showToast() API which guides them down this path by default. This will mean that most of the time, it will be above most things, but developers can explicitly be on top of the toast using higher z-index values or placing things after it in the DOM order. Additionally, this allows developers to keep the toast constrained to a stacking context, by placing it in a different element instead of at the end of <body>. (This is a feature that several existing libraries support, per https://github.com/jackbsteinberg/std-toast/tree/master/study-group "display in container".)
Another strategy is to put the toast in the top layer (https://fullscreen.spec.whatwg.org/#top-layer), which is currently used for only <dialog> (Chrome-only) and fullscreen. It's kind of under-explored territory. The next step if we wanted to go this route would be to flesh out the top layer concept further (https://github.com/whatwg/html/issues/4633).
I posted https://github.com/jackbsteinberg/std-toast/issues/23 to capture this on the issue tracker.
> Hi Jack,
(Jack is on a plane and asked me to reply in his stead.)
> What paint order do you think should apply to a toast? Same question goes for containing block. I see that you have thought about how to indicate stacking order of the toasts, but what about other content?
One strategy is minimal: the toast has a UA default style of z-index: 1, and then developers are given guidance to generally place it as the last element of their <body>---plus the showToast() API which guides them down this path by default. This will mean that most of the time, it will be above most things, but developers can explicitly be on top of the toast using higher z-index values or placing things after it in the DOM order. Additionally, this allows developers to keep the toast constrained to a stacking context, by placing it in a different element instead of at the end of <body>. (This is a feature that several existing libraries support, per https://github.com/jackbsteinberg/std-toast/tree/master/study-group "display in container".)
Another strategy is to put the toast in the top layer (https://fullscreen.spec.whatwg.org/#top-layer), which is currently used for only <dialog> (Chrome-only) and fullscreen. It's kind of under-explored territory. The next step if we wanted to go this route would be to flesh out the top layer concept further (https://github.com/whatwg/html/issues/4633).
I posted https://github.com/jackbsteinberg/std-toast/issues/23 to capture this on the issue tracker.
Naina Raisinghani
Jun 12, 2019, 4:03:55 PM6/12/19
to blink-dev
We’re excited about this on the AMP Project.
The two main use cases we were seeing are both in e-commerce:
- Confirmation of action
- Prompt user to correct an action that they have taken.
We currently have an example of how to create a snackbar on amp.dev. This will allow us to ship a more encapsulated component without having to add to our bundlesize.
The research as shown in the GitHub project is thorough and covers the use cases we need which we communicated to the team working on this.
On Wednesday, June 12, 2019 at 8:46:07 AM UTC-7, Jack Steinberg wrote:
Contact emails
jackst...@chromium.org,domen...@chromium.org,fer...@chromium.org
Chris Harrelson
Jun 12, 2019, 4:36:33 PM6/12/19
to Domenic Denicola, Jack Steinberg, blink-dev
Cool, thanks for this data. I commented on the issue you filed.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BN6PR13MB16511313CC0650F6E0A0BCE6DFEC0%40BN6PR13MB1651.namprd13.prod.outlook.com.
Changwan Ryu
Jun 12, 2019, 4:42:47 PM6/12/19
to Chris Harrelson, Domenic Denicola, Jack Steinberg, blink-dev
How can we support this on Android WebView?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8aY%3D1PV%2BWjpXjp_DPni854YMYDnomiG%2BQyZ_0Fcw%2BhTA%40mail.gmail.com.
Domenic Denicola
Jun 12, 2019, 5:17:28 PM6/12/19
to Changwan Ryu, Chris Harrelson, Jack Steinberg, blink-dev
From: Changwan Ryu <chan...@chromium.org>
> How can we support this on Android WebView?
Can you expand on why you think this might be difficult to support on Android WebView?
> How can we support this on Android WebView?
Changwan Ryu
Jun 12, 2019, 7:52:50 PM6/12/19
to Domenic Denicola, Changwan Ryu, Chris Harrelson, Jack Steinberg, blink-dev
I couldn't find any UI mock. How is it going to be implemented for each platform?
https://github.com/jackbsteinberg/std-toast says that this is similar to alert(), but not sure if it would require platform-specific UIs.
For alert(),
apps need to implement a callback to implement UI dialog for alert():
There was no discussion about this in the intent, so I wasn't sure if I understand it correctly. Sorry if I wasn't clear about what I'm asking about.
Joe Medley
Jun 13, 2019, 10:54:32 AM6/13/19
to Jack Steinberg, blink-dev
Jack,
I can't find your status entry for some reason.
Joe
If an API's not documented it doesn't exist.
On Wed, Jun 12, 2019 at 8:46 AM Jack Steinberg <jackst...@chromium.org> wrote:
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEYN2j4Ps3F%2B_SxjiP%2BE1SFUaSVO_aG8nBbOcPvsSSxaMdgo3g%40mail.gmail.com.
ko...@kooslooijesteijn.net
Jun 13, 2019, 11:43:21 AM6/13/19
to blink-dev
Please, don't use Chrome's market dominance to force a standard on others.
I have some objections to the proposal itself too:
1. The proposed <toast> is not just a semantic element; it prescribes styling (placement at the bottom of the viewport, presumably with position: fixed;, overlaying other elements. This goes against the separation of concerns.
2. Semantically, it would be too close to <aside>.
3. I wouldn't know the semantic difference between <toast> and other similar proposals, like <popup>, <modal>, <message> and <notification>.
4. The proposed name is derived from an Android UI pattern and may be difficult to understand for those who don't develop for Android.
5. Toast isn't a universal food; it's known only in some of todays cultures. Avocado & toast jokes are stale in 2019 already, imagine what it feels like to code with them in 5 years, or if you've never had toast.
Op woensdag 12 juni 2019 17:46:07 UTC+2 schreef Jack Steinberg:
Zachary Yaro
Jun 13, 2019, 11:58:43 AM6/13/19
to ko...@kooslooijesteijn.net, blink-dev
I think the use case of this element is distinct from an aside or a modal dialog. I do, however, strongly agree with points 4 & 5—I would prefer to see a more universally understood name.
Zachary Yaro
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0a2d6214-2526-4aff-ba76-6237cc0414bf%40chromium.org.
Domenic Denicola
Jun 13, 2019, 1:10:51 PM6/13/19
to ko...@kooslooijesteijn.net, blink-dev
Hi koos,
The Intent to Implement is the beginning of a discussion with standards forums. There’s no “forcing” involved. See https://twitter.com/yoavweiss/status/1139014302151536640 for more background.
As for your specification suggestions, could you file them as issues (or comment on existing issues) on the proposal repository?
--
Joe Medley
Jun 13, 2019, 2:06:16 PM6/13/19
to blink-dev, ko...@kooslooijesteijn.net
1. The proposed <toast> is not just a semantic element; it prescribes styling (placement at the bottom of the viewport, presumably with position: fixed;, overlaying other elements. This goes against the separation of concerns.
I'm not sure if this is valid. <pre>, <code>, <em>, and <strong> all at least imply styling even if they don't prescribe it. The <header> and <footer> tags prescribe placement. What is the requirement that any of these be styled a particular way.
2. Semantically, it would be too close to <aside>.
Completely disagree. An aside is tangential to a page's purpose. Toasts are attempting to be part of the user's/reader's course of action in every case.
3. I wouldn't know the semantic difference between <toast> and other similar proposals, like <popup>, <modal>, <message> and <notification>.
This is a fair point; however those elements seem less semantic to me than <toast> does. The <popup> and <modal> elements in particular are named after a method of display rather than what type of content they might display. It would certainly be worth clarifying what the differences is between a <message>, and <notification>, and a <toast>. Two or more of them might collapse into a common set of use cases.
4. The proposed name is derived from an Android UI pattern and may be difficult to understand for those who don't develop for Android.
This seems like a temporary problem. I could have made a similar argument about not using 'mac UI names' on Windows. Today those names--text box, drop-down list, etc.--are used no matter what system we find them on.
5. Toast isn't a universal food; it's known only in some of todays cultures. Avocado & toast jokes are stale in 2019 already, imagine what it feels like to code with them in 5 years, or if you've never had toast.
I think the intended meaning of 'toast' in this instance is that of raising a glass. Regardless, words are always able to take on new meanings. For example the earlier recorded use of the word 'Broadcast' is from 1767. It referred to distributing seeds by hand. Pretend it's 1910. Imagine what it feels like to be in radio transmission when you've never heard of distributing seeds hand. Another example: 'wiki' comes from the Hawaiian term 'wiki wiki' which means very quick. This knowledge contributes nothing to my ability to use the word or the software.
Domenic Denicola
Jun 13, 2019, 5:22:30 PM6/13/19
to Changwan Ryu, Chris Harrelson, Jack Steinberg, blink-dev
From: Changwan Ryu <chan...@chromium.org>
> I couldn't find any UI mock. How is it going to be implemented for each platform?
> https://github.com/jackbsteinberg/std-toast says that this is similar to alert(), but not sure if it would require platform-specific UIs.
Thanks, this is definitely not as clear as it should be. A Firefox dev filed https://github.com/jackbsteinberg/std-toast/issues/27 on a similar issue. The intent is for this to be a fully in-page UI, not to use platform-specific APIs.
The analogy with alert() was more "developers often want to show toasts from JavaScript, so there will be a function to call", not "we will implement this like browsers used to implement alert()" (using native platform alert boxes). We can try to make this clearer as well.
> There was no discussion about this in the intent, so I wasn't sure if I understand it correctly. Sorry if I wasn't clear about what I'm asking about.
No worries, these kinds of discussions and clarifications are what the I2I is for!
> I couldn't find any UI mock. How is it going to be implemented for each platform?
> https://github.com/jackbsteinberg/std-toast says that this is similar to alert(), but not sure if it would require platform-specific UIs.
The analogy with alert() was more "developers often want to show toasts from JavaScript, so there will be a function to call", not "we will implement this like browsers used to implement alert()" (using native platform alert boxes). We can try to make this clearer as well.
> There was no discussion about this in the intent, so I wasn't sure if I understand it correctly. Sorry if I wasn't clear about what I'm asking about.
Changwan Ryu
Jun 13, 2019, 5:24:52 PM6/13/19
to Domenic Denicola, Changwan Ryu, Chris Harrelson, Jack Steinberg, blink-dev
Thanks for the clarification. No concern on the Android Webview side, then.
paulm...@gmail.com
Jun 19, 2019, 8:38:28 PM6/19/19
to blink-dev
It's not just an Android UI pattern. It has to do with videogames history: https://en.m.wikipedia.org/wiki/Dan_Forden and has been baked in the web through several UI libraries (like jQuery plugins in the old days...)
Not saying I agree with this proposal per se.
Not saying I agree with this proposal per se.
Reply all
Reply to author
Forward
0 new messages