A toast UI element

[jackbsteinberg]

こんにちは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:

• Relevant time constraints or deadlines: Great if the review is done by the end of August 2019
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: HTML

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]

[markcellus]

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]

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]

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.

[dbaron]

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

[philiprenich]

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