5 ms·

1. Blog posts on a real big corporate blog, not on some mailing list no one reads. 2. A few months later: Warnings in the dev tools. 3. A few months after 2,

by gpm 5y ago

1. Blog posts on a real big corporate blog, not on some mailing list no one reads. 2. A few months later: Warnings in the dev tools. 3. A few months after 2, at least a year after 1: Warnings on websites using the feature, for this feature it would probably have made sense to make a yellow or red ex through the padlock. 4. A year after 3, at least 2 years after 1, maybe actually consider actually removing it. It's folly to think that all important websites are actually maintained, it's certainly not the case that they can all roll out updates within months (think internal websites from vendored software that is rarely updated), and there's no reason to rush. I'd consider what I outlined here to be a very aggressive rollout schedule. Better than removing it entirely, would be to permanently put in a version of the feature that is still functional but avoids the issues with it. E.g. change the alert dialog to something hideous that clearly explains "this might not be from where it claims it is", but don't entirely break backwards compatibility.

gpm 5y ago
The more general version of this is 1. Tell people who read the news (blog) 2. Tell people who make the thing you're breaking (devtools) 3. Tell users, but without breaking it since it's not something they can solve (padlock) 4. Maybe finally break it
Orphis 5y ago
I've removed some feature from the web in Chrome after a long deprecation phase with warnings in devtools, proper announcements in ALL the relevant mailing lists and release notes. Still, many major websites broke as they failed to implement the very simple required changes in their products. Did they break in Chrome? No, we landed the change at a later date than announced. But Firefox did the same removal and it landed to stable a few weeks before Chrome. They also advertised for the removal extensively and were hit by all the "Major site X and Y are broken" bugs unfortunately. A couple days later, everything was fixed though, when Chrome's side of thing reached stable, no sites were really impacted. The replacement API had been available for many years before, people used the old non-standard and deprecated way still. So no, websites owner will not be proactive and fix their products no matter what you do unless they break. We do our best to be upfront with the changes, but both sides have to be willing to communicate for it to happen.
- danShumway 5y ago
  > We do our best to be upfront with the changes, but both sides have to be willing to communicate for it to happen. What processes did Chrome follow in this case to identify sites that might break, and did it reach out directly to any of the people who would be affected? I'm seeing comments from people like Chris Coyier that they were caught off guard with this change: https://twitr.gq/chriscoyier/status/1420027533005836298#m https://twitr.gq/chriscoyier/status/1420027533005836298#m If the creator of CodePen didn't realize this was coming, and if it didn't register to anyone in charge of this change that he should be contacted about it and included in the discussion before late July, then to me it really doesn't seem like the communication breakdown here is happening because of website developers.
  - Orphis 5y ago
    There are archives you can sample to measure the impact of a change to some degree. We can use them to have an estimation of how common some patterns are. It's tricky to query so it may not work for advanced use cases or identify cross origin issues. And it's not possible to reach out directly to those people. We can't just send deprecation notices to random contact emails (if there's any) on websites. We can't just open a "support request" to L1 customer support of websites telling them their site might not work soon. We're not going to send dead-tree mail to addresses listed on websites either. If you want to support specific browsers, as part of your ongoing maintenance, you should test your site with canary and beta versions of browsers to catch issues before they go live at a minimum. You can also read the relevant mailing lists or blog posts for the major browsers to have an idea of the direction they're taking. Chrome 91 went stable July 15. But the first beta was April 22. The change was probably in Canary before that as well. Quite a long time to catch issues with the right automation. Personally, I wouldn't want to have to read the mailing lists and other articles. I would want a dashboard that tells me everything is tested and working fine automatically. And when it doesn't, I know I have many months to fix the issue before it hits stable and find the relevant documentation about the changes that might be causing the issues. Or just open an issue to the browsers, sometimes people are using APIs in very unexpected ways, or you know, a bug sneaked in despite the testing we have in place.

by gpm 5y ago

gpm 5y ago

The more general version of this is 1. Tell people who read the news (blog) 2. Tell people who make the thing you're breaking (devtools) 3. Tell users, but without breaking it since it's not something they can solve (padlock) 4. Maybe finally break it

Orphis 5y ago

I've removed some feature from the web in Chrome after a long deprecation phase with warnings in devtools, proper announcements in ALL the relevant mailing lists and release notes. Still, many major websites broke as they failed to implement the very simple required changes in their products. Did they break in Chrome? No, we landed the change at a later date than announced. But Firefox did the same removal and it landed to stable a few weeks before Chrome. They also advertised for the removal extensively and were hit by all the "Major site X and Y are broken" bugs unfortunately. A couple days later, everything was fixed though, when Chrome's side of thing reached stable, no sites were really impacted. The replacement API had been available for many years before, people used the old non-standard and deprecated way still. So no, websites owner will not be proactive and fix their products no matter what you do unless they break. We do our best to be upfront with the changes, but both sides have to be willing to communicate for it to happen.

danShumway 5y ago
> We do our best to be upfront with the changes, but both sides have to be willing to communicate for it to happen. What processes did Chrome follow in this case to identify sites that might break, and did it reach out directly to any of the people who would be affected? I'm seeing comments from people like Chris Coyier that they were caught off guard with this change: https://twitr.gq/chriscoyier/status/1420027533005836298#m https://twitr.gq/chriscoyier/status/1420027533005836298#m If the creator of CodePen didn't realize this was coming, and if it didn't register to anyone in charge of this change that he should be contacted about it and included in the discussion before late July, then to me it really doesn't seem like the communication breakdown here is happening because of website developers.
- Orphis 5y ago
  There are archives you can sample to measure the impact of a change to some degree. We can use them to have an estimation of how common some patterns are. It's tricky to query so it may not work for advanced use cases or identify cross origin issues. And it's not possible to reach out directly to those people. We can't just send deprecation notices to random contact emails (if there's any) on websites. We can't just open a "support request" to L1 customer support of websites telling them their site might not work soon. We're not going to send dead-tree mail to addresses listed on websites either. If you want to support specific browsers, as part of your ongoing maintenance, you should test your site with canary and beta versions of browsers to catch issues before they go live at a minimum. You can also read the relevant mailing lists or blog posts for the major browsers to have an idea of the direction they're taking. Chrome 91 went stable July 15. But the first beta was April 22. The change was probably in Canary before that as well. Quite a long time to catch issues with the right automation. Personally, I wouldn't want to have to read the mailing lists and other articles. I would want a dashboard that tells me everything is tested and working fine automatically. And when it doesn't, I know I have many months to fix the issue before it hits stable and find the relevant documentation about the changes that might be causing the issues. Or just open an issue to the browsers, sometimes people are using APIs in very unexpected ways, or you know, a bug sneaked in despite the testing we have in place.