Closed domenic closed 5 years ago
One issue that came through when exploring the implementation of this API update is that, without an easy way to fallback to a type="info"
value, the pattern doesn't make sense. I propose we update the spec language to represent four toast types, success
, warning
, error
, and a default type, the last of which is not explicit and is by definition the absence of type.
The explicit types would could be styled using [type=____ i]
selectors, and the default type would be styled directly onto the toast. This way, the default is more of a fallback, absence of type itself, instead of its own distinct type, which would be technically confusing to implement.
That makes sense. In particular, having <std-toast></std-toast>
behave mostly the same as <std-toast type="info"></std-toast>
, except that only the latter works with std-toast[type=info i] { ... }
styling, is kind of bad. I'll update to remove the explicit info value for the type="" attribute.
This is one take on the discussions in #18, that makes the existing text more concrete. The issue will remain open to discuss these details as well as alternatives.