Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A toast UI element #385

Open
jackbsteinberg opened this issue Jun 12, 2019 · 27 comments

Comments

@jackbsteinberg
Copy link

commented Jun 12, 2019

こんにちはTAG!

I'm requesting a TAG review of:

  • Name: A toast UI element
  • Specification URL: N/A
  • Explainer (containing user needs and example code)¹: https://github.com/jackbsteinberg/std-toast
  • GitHub issues (if you prefer feedback filed there): N/A
  • Tests: N/A
  • Primary contacts (and their relationship to the specification): @jackbsteinberg

Further details:

We'd prefer the TAG provide feedback as (please select one):

  • open issues in our GitHub repo for each point of feedback
  • open a single issue in our GitHub repo for the entire review
  • leave review feedback as a comment in this issue and @-notify [github usernames]
@mkay581

This comment has been minimized.

Copy link

commented Jun 12, 2019

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?

@jackbsteinberg

This comment has been minimized.

Copy link
Author

commented Jun 12, 2019

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.

@othermaciej

This comment has been minimized.

Copy link

commented Jun 13, 2019

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.

@othermaciej othermaciej referenced this issue Jun 13, 2019

Open

A toggle switch control element #384

3 of 5 tasks complete
@dbaron

This comment has been minimized.

Copy link
Member

commented Jun 13, 2019

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

@philiprenich

This comment has been minimized.

Copy link

commented Jun 13, 2019

(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 :/

@othermaciej

This comment has been minimized.

Copy link

commented Jun 13, 2019

"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.

@kenchris

This comment has been minimized.

Copy link

commented Jun 13, 2019

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

@boazsender

This comment has been minimized.

Copy link

commented Jun 13, 2019

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.

@zcorpan

This comment has been minimized.

Copy link

commented Jun 13, 2019

<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.

@cup

This comment has been minimized.

Copy link

commented Jun 13, 2019

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".

@crertel

This comment has been minimized.

Copy link

commented Jun 13, 2019

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!

@kenchris

This comment has been minimized.

Copy link

commented Jun 13, 2019

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

@domenic

This comment has been minimized.

Copy link
Member

commented Jun 13, 2019

I've posted whatwg/html#4696 and whatwg/html#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!

@torgo

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019

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

@torgo

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019

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

@torgo torgo added this to the 2019-06-19-telecon milestone Jun 14, 2019

@kenchris

This comment has been minimized.

Copy link

commented Jun 14, 2019

@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

@garygreen

This comment has been minimized.

Copy link

commented Jun 14, 2019

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)

@garygreen

This comment has been minimized.

Copy link

commented Jun 14, 2019

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:

image

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

@FezVrasta

This comment has been minimized.

Copy link

commented Jun 14, 2019

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

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

@garygreen

This comment has been minimized.

Copy link

commented Jun 14, 2019

@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.

@FezVrasta

This comment has been minimized.

Copy link

commented Jun 14, 2019

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

@domenic

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019

@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.

@crertel

This comment has been minimized.

Copy link

commented Jun 15, 2019

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.

@OwenEdwards

This comment has been minimized.

Copy link

commented Jun 17, 2019

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.

@hober hober self-assigned this Jun 18, 2019

@kenchris

This comment has been minimized.

Copy link

commented Jun 19, 2019

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.

@torgo

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

@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.

@garygreen

This comment has been minimized.

Copy link

commented Jun 19, 2019

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.

@alice alice self-assigned this Jul 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.