-
Notifications
You must be signed in to change notification settings - Fork 8
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
Set target Baseline level for the component #33
Comments
Thanks for calling that out James. I'm of two minds here. On the one hand, since we can't look at analytics, and don't know the consumers for the widget, we should be more conservative and stick to widely available features. On the other hand, the widget really only makes sense for a web developer audience and it's reasonable to expect that audience to be on an up to date browser. Still, unless we are using it as a progressive enhancement, I'd suggest sticking to widely available, but what do others think? |
Because we distribute this component as something other web authors can embed, we have a responsibility to make sure it works in as many cases as possible, and with as few side effects (see #16) as possible. Sticking to Widely Available features only seems in order. |
Agree that the widget should stick to only using Baseline Widely Available features. |
In #21 we started using
light-dark
, and #22 uses it in additional places.light-dark
is baseline "newly available"- do we want to make sure we are only using Widely Available features in this component?I think at minimum we would want to document baseline target in the README. We could potentially add a browserslist and potentially tooling to enforce it.
The text was updated successfully, but these errors were encountered: