4 ms·

> The Chrome team has also asked for formal Standards Positions from both vendors, see the Related links section. The <permission> element is an ongoing topic o

> The Chrome team has also asked for formal Standards Positions from both vendors, see the Related links section. The <permission> element is an ongoing topic of discussions with other browsers and we're hoping to standardize it. I don’t understand this proposal enough to have an opinion yet, but that sure is an interesting way to say both Firefox and WebKit oppose it. https://github.com/mozilla/standards-positions/issues/908#issuecomment-2484853981 https://github.com/mozilla/standards-positions/issues/908#is... https://github.com/WebKit/standards-positions/issues/270#issuecomment-2046572759 https://github.com/WebKit/standards-positions/issues/270#iss...

skybrian 1y ago
Maybe they don’t want to update this web page if the other vendors change their minds? They have links instead.
- troupo 1y ago
  They never update web.dev pages, and often present not-even-close-to-being-standard as done deals
username223 1y ago
This bit from the WebKit response hits hard for me: > Security Complexity: Proposed security measures (styling constraints, timing, and position mitigation) add substantial complexity, indicating possible fundamental issues with the approach. "Security complexity" is never something you want to see, because it will become yet another game of whack-a-mole between browser makers and hostile websites (i.e. between Chrome and Google Ads). Does anyone believe that a standard will hold up against the AdTech industry armed with the full power of HTML+CSS+JavaScript? These are the people who brought you the "Enable push notifications? Yes/Pester-me-later" pre-prompt.
- ultiuix 1y ago
  [flagged]
shaky-carrousel 1y ago
Google probably wants to bring the "maybe later" anti-pattern to the browser permission system: https://tildes.net/~tech/1d9u/im_thoroughly_done_with_my_choices_being_only_yes_or_not_now https://tildes.net/~tech/1d9u/im_thoroughly_done_with_my_cho... It's a reminder that Google is not a friend, but an ad-versary, and that you aren't given a free browser to happily navigate the internet, but to be milked by the ad industry.
imtringued 1y ago
Considering that Chrome doesn't support getAutoplayPolicy() even though it's been 7 years since browsers decided to break autoplay for everyone, I'm pretty sure Google doesn't have any good intentions here. If you have a website that relies on autoplay, because it is basically just one giant video element, then there is no way to detect that autoplay is blocked and fall back to a stopped video. You're forced to essentially not use autoplay at all. When autoplay is blocked you don't get an error, the autoplay events are simply disabled. You can't prove the absence of the event even with an invisible silent sound being played in the background. That's what getAutoplayPolicy() is for and guess who didn't implement it.

skybrian 1y ago

Maybe they don’t want to update this web page if the other vendors change their minds? They have links instead.

troupo 1y ago
They never update web.dev pages, and often present not-even-close-to-being-standard as done deals

username223 1y ago

This bit from the WebKit response hits hard for me: > Security Complexity: Proposed security measures (styling constraints, timing, and position mitigation) add substantial complexity, indicating possible fundamental issues with the approach. "Security complexity" is never something you want to see, because it will become yet another game of whack-a-mole between browser makers and hostile websites (i.e. between Chrome and Google Ads). Does anyone believe that a standard will hold up against the AdTech industry armed with the full power of HTML+CSS+JavaScript? These are the people who brought you the "Enable push notifications? Yes/Pester-me-later" pre-prompt.

ultiuix 1y ago
[flagged]

shaky-carrousel 1y ago

Google probably wants to bring the "maybe later" anti-pattern to the browser permission system: https://tildes.net/~tech/1d9u/im_thoroughly_done_with_my_choices_being_only_yes_or_not_now https://tildes.net/~tech/1d9u/im_thoroughly_done_with_my_cho... It's a reminder that Google is not a friend, but an ad-versary, and that you aren't given a free browser to happily navigate the internet, but to be milked by the ad industry.

imtringued 1y ago

Considering that Chrome doesn't support getAutoplayPolicy() even though it's been 7 years since browsers decided to break autoplay for everyone, I'm pretty sure Google doesn't have any good intentions here. If you have a website that relies on autoplay, because it is basically just one giant video element, then there is no way to detect that autoplay is blocked and fall back to a stopped video. You're forced to essentially not use autoplay at all. When autoplay is blocked you don't get an error, the autoplay events are simply disabled. You can't prove the absence of the event even with an invisible silent sound being played in the background. That's what getAutoplayPolicy() is for and guess who didn't implement it.