> In general, I'm in favour of not autoplaying at all on mobile devices. I think I was just trying to address the spec's statement of overriding when not desired. I don't want to punish sites that are reading that and trying to be good citizens. For instance, <video> elements are actually a good solution if you want an animated background on a site, and provide good fallbacks when they're disabled. I want to at least discuss making a good faith effort to only disable it when necessary. But I won't argue that we can have a perfect heuristic for that either (I'm not sure how we know if you're in a library). Maybe "phone" is the best we can do for users. Maybe we need to discuss disabling audio (from audio or video elements) and video separately?
> Is the concern that disabling autoplay too widely will lead to widespread > scripted-autoplay, reducing user control yet further? My concern is that this may break sites without providing much feedback to them about why. I'd like to minimize bustage/confusion for developers, as well as doing our best to respect their requests. > Can you be explicit about the three states of this proposed tri-state pref? I was thinking something like: Enabled - Always works Disabled - Never works Dynamic - Up to UA. Technically, I'd be fine putting this behind Enabled, but if we want the dynamic behaviour behind a pref, it seemed simpler to add it here than to start dealing with combinatorials of different prefs. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
