Perhaps they are new to web development. This is the nature of developing for the web: you have to perform cross-browser testing and you have no control over media. The only thing you can do is test upcoming browser versions and respond appropriately. They do release future versions as canaries. Developing for the web has always been this way.
If the dev doesn't have time to be a commercial web developer then they should hire an assistant.
> If the dev doesn't have time to be a commercial web developer then they should hire an assistant.
Some companies that do web development (commercially, internally, or whatever) have tighter release schedules than the cool DevOps style Continuous Deployment that we see the unicorn startups like Basecamp, GitHub, Slack, etc. doing where code can get pushed to production a dozen times a day. The place I work at has governmental regulations and SLAs we have to comply with when we deploy, which puts us on a cadence with something akin to Chrome's release schedule (e.g., Dev is CI/CD, QA is CD, UAT is kept to about once a week, Prod is every 4 weeks with capabilities at a 2 week hot fix window). Additionally, we just don't have the resources or budget available to keep one developer twiddling his or her thumbs all day waiting for new buttons to show up on a browser control that we have to hide or mitigate the impact of.
I completely understand what your argument is, and it's valid. We have QA run integration, regression, validation and smoke tests any time code is promoted up the environment chain that tries to catch issues like this, and we do our best to keep on top of it all. This issue isn't something that effects us, but it shows a reactionary approach to dealing with these issues. Teams that do spend their time reacting to changes like a new button, or an underlying OS update breaking some compatibility or what-have-you have always been a thorn in my side. It's no way to deliver value to their customers since their time is consistently being hijacked from new features to put out fires, which is stressful and leads to burn out very quickly.
This is the nature of developing for the web: you have to perform cross-browser testing and you have no control over media.
It used to be that we had standards for this kind of thing precisely so that huge amounts of effort on ongoing browser testing wasn't necessary.
And you have plenty of control over the way this sort of content is presented. Unfortunately all this sort of change and the supportive attitude widely seen in this discussion will do is push sites towards the less flexible and user-friendly options, particularly the sites that didn't previously go for things like DRM.
Developing for the web has always been this way.
No, it hasn't. "Evergreen" browsers that move the goalposts every few weeks are a relatively recent development, and particularly in the area of media elements and the related controls their approach has been a nightmare from day one.
If the dev doesn't have time to be a commercial web developer then they should hire an assistant.
How is that attitude going to get more new and useful content onto the web?
If the dev doesn't have time to be a commercial web developer then they should hire an assistant.