-
Couldn't load subscription status.
- Fork 5
[image-animation-property] Expand on why the controlled value is desirable #3
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
base: main
Are you sure you want to change the base?
Conversation
|
|
||
| However, in the general case, authors have no way of knowing which images are static and which are animatable. | ||
| Without this knowledge, the choice is either to provide no controls at all, | ||
| or controls even on static images that don't need it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO the solution to this is to expose that distinction. You're assuming that's not possible and building on it, but I don't think that's the case.
| <dd> | ||
| There is precedent for CSS properties affecting the presence of UI controls on elements: | ||
| [`resise`](https://www.w3.org/TR/css-ui-3/#resize), | ||
| [`overflow: scroll` or `overflow: auto `](https://www.w3.org/TR/css-overflow-3/#overflow-control). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no precedent for CSS and HTML affecting UI in the same way though, I think. Right now we don't have <img controls>, but do we want to rule it out forever?
| The example below shows what a typical browser-provided UI can be expected to look like, | ||
| and replicating that manually, | ||
| with good accessibility, | ||
| would not be easy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- But this is often needed for
<video>as well, which this doesn't apply to - Yes, we should make simple things easy, but after we've made complex things possible unless we have very high confidence that they cover the vast majority of use cases. Specifically when it comes to UI, features where UAs add UI that is not customizable are typically the source of user pain. We've seen this in both the features you listed above: we had to add a ton of stuff to make scrollbars customizable and CSS resizers are also rarely used for anything other than textareas. Instead people prefer customizable components for resizing e.g. panels or other containers.
| users need to be able to chose to turn such animations off | ||
| while keeping the ability to opt into viewing them individually. | ||
| `image-animation: controlled` can be applied to existing markup and user-generated content | ||
| in a way that changing markup cannot. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a much more general issue though and applies to a lot more than this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've replied to individual points, but as a general point, this mainly argues that controlled is desirable, not why it needs to be in the MVP.
Is the feature not useful without it?
IMO only if custom UIs cannot be built at all. That's only the case if we cannot distinguish static from animated images. So perhaps we can frame it as a tension between these two: either we need controlled, or we need a way to tell them apart.
No description provided.