Something like this definitely needed. The std- prefix and shipping this as a built-in module was an interesting choice rather than making this a Custom Element and shopping it around in userland and gaining some public interest first. Were you planning for this to be shipped as part of the proposed standard library?

Hey @mkay581 thanks for taking a look at this.

The intention here is to create a new HTML element, going through the usual process that requires, and using a std- prefix to preserve faithful polyfillability. Instead of creating a Custom Element and adding to the variety of toast implementations out there, we think it's more valuable to bake the popular toast pattern right into the language, allowing those libraries to decrease their bundle sizes by building their toasts right on top of ours.

@domenic's latest comment in this thread on the std-switch Intent to Implement might provide some helpful context.

Problems with this approach (also applicable to std-switch):

• I think we need to find a way to avoid most/all future HTML elements having a std- prefix. It will make HTML quite unpleasant to read if we project out a decade or so.

• Having to do an import per-element doesn't seem like it scales well.

It's worth thinking about these problems and trying to solve them before creating too many elements with this pattern.

A bunch of the discussion in #384 likely applies here as well.

(Not actually sure if this repo is meant for general public commenting, sorry...)

HTML elements are meant to be single words with no - aren't they? Toast is also an esoteric cutsie name that probably doesn't belong in the spec. Surely something more meaningful can be found? Not an easy task for sure, it's an overloaded space :/

"Toast" seems like the standard term for expiring non-modal notification windows on Android and Windows. On iOS and MacOS they are called "banners", or if you want to be really specific, "temporary notification banners".

I guess the intention here is to provide an in-page version of this functionality, which is why it's new stuff instead of additions to Notifications API.

I do think "toast" is a an odd jargon term that will be really clear in some communities and really confusing in others.

Another thought: why isn't this instead an addition to <dialog>, a showTemporary() (or showToast() or showBanner()) method in addition to show() and showModal()? It seems like that could be implemented on top of show(), close() and a timer, so still polyfillable, and wouldn't be semantically wrong IMO.

As a non-English speaker, I don't find banner any more clear. Especially banner (I think flag like thing) is often used as a loanword with very specific meaning (toast as well which is normally a heated sandwich and just that). As a non-English speaker, words like tooltip are just as bad, but you learn exactly when they represent quickly, so I don't think the name is a big blocker.

I think something like infobox (or infobanner for that matter) might be more understandable to most people - it is just info, so not super important and thus, it might go away after a short while

Thanks for requesting feedback @jackbsteinberg.

I really appreciate the intention behind this proposal: to pave web developer cow paths 🐄, and to make more accessible defaults🤗. At the same time, I was surprised to see this API being developed separately from the notifications API and <dialogue>. Would it be worth exploring extending one or both of those interfaces first? We probably want to avoid web authors needing to learn three different interfaces for giving user advice or feedback. I also understand that we don't want to make web authors contort themselves to give so called "toast" with a modified dialogue or notifications interface. There must be a happy middle ground. I recognize that what I'm suggesting here is a lot more work for you/us, but I think it will make for an easier-to-reason-about feedback/advice interface. What do you think?

Separately, I also agree with previous commenters that "toast" feels too platform specific for the web, and that the std prefix won't age well.

Thanks again for working on improving the web platform! I think there is a ton of potential here to make the web a stronger and more accessible platform. I am extra appreciative of your time working on toast, reviewing feedback, and building consensus with TAG, web developers and multiple implementers.

<std-toast> seems to not be so well-received (example), as if Google is somehow skipping standardization and forcing their solution on everyone.

Consider following the "problem-statement-first" WHATWG process. This builds consensus through public discussion of the problem prior to proposing a solution.

according to this page:

https://developer.mozilla.org/Web/HTML/Element

i am counting at least 200 HTML elements currently (forgive if my selector is bad):

$$('td [href^="/en-US/docs/Web/HTML/Element/"]').length;
223

are we really saying that none of the current elements can fill this role? I agree with @zcorpan, this seems like a vanity project and should go through the normal process. not be rushed through "because google".

Relevant time constraints or deadlines: Great if the review is done by the end of August 2019

This wouldn't happen to be motivated by, say, a return to class for the fall semester?

Anyways, some questions.

<std-toast id="sample-toast" theme="info">
    Hello World!
</std-toast>

• What is the purpose of the theme attribute?
• What are the valid values of the theme attribute? Are custom themes supported?
• What markup is allowed inside <std-toast> elements? The docs suggest that toasts contain an image, some text, and maybe some interaction, but does the markup allow for more interesting things? Text styling? ARIA markup?
• How does accessibility work for toasts, anyways?

import { showToast } from 'std:elements/toast';

const toast = showToast("Hello World!", {
    theme: "info",
    duration: 3000
});

• What markup is allowed in the first param to showToast? Can we pass a DOM element instead?
• Is there any provision to prevent malicious scripts from filling a user's screen with obnoxious amounts of toast?
• What happens to toast created in iframe elements?

Thanks for starting a discussion, anyways!

Hi @crertel can you please file these issues on the project/spec repo, so they get properly tracked.

This wouldn't happen to be motivated by, say, a return to class for the fall semester?

Please avoid sarcasm and/or ironi in this repo, and keep the discussion focused

I've posted https://github.com/whatwg/html/issues/4696 and https://github.com/whatwg/html/issues/4697 to centralize discussion around polyfillable element names and pay-for-what-you-use HTML elements. A lot of the other things folks have mentioned in this issue are already being discussed in the std-toast repo, which is great; that's why we file for feedback early!

@jackbsteinberg I'd like to see @boazsender's question addressed : why is this separate from the notifications API?

Also regarding venue, what is the roadmap to bring this to WICG or similar?

@torgo the difference is that this is a temporary notification / infobar, like you see for PWAs ("new version available, press reload to refresh") or like in GMail ("Chat is currently unavailable") etc. These are not things you want an actual system notification for... They really depend on the surrounding content/situation unlike regular notifications

import { showToast } from 'std:elements/toast';

const toast = showToast("Hello World!", {
    theme: "info",
    duration: 3000
});

Does this format not completely deviate from API currently in browsers? It looks to me Google is proposing to overload imports and stub in their own. This would make it difficult to polyfill in older/non supported browsers, too?

I also echo the comments from others that it feels like an existing element e.g <dialog> could be used to house the toast-like functionality and keep to standards already defined rather than create a new concept of tags prefixed with "std" e.g. <std-toast>

Having a way to define and position popups/toasts around other elements is long overdue. Maybe cc/ @FezVrasta can also share his thoughts on this proposal (author of Popper.js)

Ok I think I've totally misunderstood the point of this new toast proposal. The name is very confusing. I was thinking it was to do with adding tooltip positioning-like functionality in the browsers, like Popper but it looks like this is more to do with dialogs e.g. Sweet Alert ?

I was hoping for some kind of positoning engine native to browers so you can position things like the way it's described in the proposal:

Meh. This whole thing doesn't seem as useful now as it seem so specific and opinionated, plus the functionality does overlap with <dialog>.

I think OP refers to the elements known as "Snackbars" in Google Material Design?

https://material.io/design/components/snackbars.html

@FezVrasta

I think OP refers to the elements known as "Snackbars" in Google Material Design?

Yes I think so, and also an alert with icons, close buttons, theme, etc. It all seems pretty opinionated to me. Sorry for including you in on this I thought it was something to do with tooltips and positioning elements in the browser, that got me a bit excited but seeems this is for something totally different.

Having a browser provided API to position elements would be great 🙂 I'll keep dreaming

@torgo we have an issue filed to clarify about the notifications API, and will do that in the explainer ASAP. But in the meantime, @kenchris is right on. This is an established UI pattern that is about transient things, not things you want in your system notifications tray.

Regarding venue, we are hoping to bring to WICG ASAP as well. It seems like there's some positive support in the Discourse thread, so I think the prerequisites are met there, so we can move as soon as the relevant people with admin rights are able to do the switch.

Please avoid sarcasm and/or ironi in this repo, and keep the discussion focused

No sarcasm or irony intended--it's useful to know the provenance of a proposal so as to have an idea how "serious" it is, and also how likely it is to be maintained.

How does accessibility work for toasts, anyways?

I second that concern. For example, how long is an appropriate timeout for accessibility, and what other features of this proposed element affect its accessibility? Should it have an implicit ARIA role (something like "alert")? These are just a few points that immediately come to mind.

We talked a bit about this in the TAG today. The feature seems to be an accessibility anti-pattern, according to the accessibility folks on the team, but that of course won't stop people from using the "toasts/banners" on their sites, so if a standardized toast can improve the accessibility story that is a net win.

That said, we are very interested in hearing now the std-toast will handle accessibility, as it is presumable out of the accessibility tree and might even interrupt and confuse the user. For instance the screen reader might be reading a particular section, and interrupting that could be quite confusing.

Nitpicking on the name, we do agree that the name is not perfect, but neither is snackbar as used on Android. Maybe something like infobar might be better.

@jackbsteinberg one thing to note: I wanted to mention that the readme on this proposal (the explainer) is really good. I especially like the use of an animated gif to illustrate the concept, and the time you've taken to explain the concept.

I think the main issues developers will have with the proposal of a <toast> component:

1. It's very opinionated in terms of how it's presented, styles, etc and some will feel this should really live in userland / libraries.

2. Compared to other tools in the browser like IntersectionObserver which are low level tools, this on the face of it seems pretty high level and more of a vanity project to scratch a certain itch.

Rather than having a whole new component, would it be better to instead have a low-level tool where you can position toast-like elements, or tooltips, and leave any opinionated styling or implementation details to developers? The easiest part of building toast-like elements is the UI however the tricky bits are:

1. Accessibility
2. Stacking multiple elements
3. Positioning of elements easily based on text-based descriptor e.g. "bottom-right" "top-left" or around other elements so they remain visible on screen, regardless of scroll position, resizing etc.

Each of these could be solved by low-level tools which would serve multiple purposes not only for toasts but other UI and components, such as tooltips etc. I'm thinking something like:

const position = new StickyElement(document.querySelector('#tooltip'), {
    // Calculate best possible position so element is visible on screen
    // First try top-center, then bottom-center, etc.
    position: ['top-center', 'bottom-center'],

    // Calculate relative to the root element, if not supplied will default to document root.
    root: document.querySelector('#tooltip-container')
});
position.translate(); // translates / moves the actual element to the best calculated position (one time)
position.track(); // Automatically translate / track whenever browser is resized / scrolled.
position.getRect(); // Returns the `Rect` object for the current best calculated position.

Along with maybe a way of stacking elements?

const stack = new ElementStack({
	root: document.querySelector('#scroller')
});
stack.append(positionedElement1);
stack.append(positionedElement2);
stack.prepend(positionedElement3);

Maybe this is already kind of possible with tools that Rect provides - but I think having a well defined api for this would help with not only toasts but also tooltips, dropdowns / other UI patterns found on the web.

We've identified a number of meta-issues here. We discussed in the TAG call today. We agreed to put some time on the agenda for our next face-to-face to discuss these meta-issues and try to come to some actions.

How is the import mechanism here related to HTML Modules? (HTML Modules is covered by our #334.) Is it the HTML modules import mechanism that's being used here, or not? (If not, then what is, and what defines it?) The examples here don't seem to match the examples there.

They aren't very related, except that they are both types of modules. What's being used here is Web IDL modules.

What is the future of this proposal given that Web IDL modules don't seem to be moving forward (heycam/webidl#675)?

Similar to issue #384, let's close this review request for now. Thanks for your feedback and comments.

Closing in response to https://github.com/w3ctag/design-reviews/issues/385#issuecomment-561489329 Thanks for flying TAG.