This post seems to assume (just from how I read it):
You and I know better than engineers who deal with the project's code directly, who have lots of knowledge from user interviews and other research on how users behave, etc.
That these engineers have malicious intent or don't want what's best for the web.
That what alert() is being used for today is a valid use of the feature.
That what is best for developers is best for the entire web.
You're assuming that alert() is a good feature for the rest of the web. Ultimately, browser vendors have access to a lot more data and a lot more user research than we do, and they seem to have concluded that that's not the case, that it's not a good feature.
What is good for developers is not necessarily what is good for all users on the web. We accept that this is the case with accessibility: developers often have to write more code and rethink their UIs, but that makes the UIs a better experience for everyone. It's not appropriate to apply that approach with accessibility and to not apply that approach everywhere else. If alert() is not a good user experience (which seems to be the case), then you using it for debugging is a hack; it's not being used for its intended use. If debugger; or other statements aren't sufficient for what you're debugging, then we should absolutely discuss how to improve them, but we shouldn't program based on hacks.
Programming tutorials break all the time, not just JS tutorials. Library versions go out of date. Unapproved JavaScript syntax (like decorators) breaks. Behavior of certain features changes and causes breaks. Best practices change, which could be seen as breakage. Breakage on the web has happened many times before: with Flash, with different CSS properties, with old JS behavior, etc. We are not special. If that breakage was okay (which I don't know your position on), then we can't say that this breakage is not okay.
You're taking browser vendors' statements about what is best for users — and that they are making decisions in users' interests rather than their own — on faith. Even if browsers' and users' interests do coincide, and even if their data (which they admitted last week was woefully inadequate) could be trusted, there is nothing forcing that alignment. It's naïve to believe otherwise.
Whether alert is good-for-developers-but-bad-for-users is a valid question, but that's not the only consideration here. Are broken websites good for users?
Breakage on the web has happened many times before
You seem to be talking about JS syntax that hasn't yet made it to stage 4 and vendor-prefixed CSS. Sorry, but that's a nonsensical comparison.
No, based on their track record, which is extremely good. Browser vendors have a reliable track record of implementing changes that are good for the average user and that improve user experience. No group of developers puts more effort into researching how users interact with browser and understanding how they think. It's just logical to assume that they aren't making these decisions for bad reasons and that they are much more likely than us to understand what users want.
there is nothing forcing that alignment.
The browser market literally enforces this????? If Chrome implements a change that decreases user experience enough, users switch browsers. That's just how the browser market works lol. Browser vendors are highly incentivized not to add features that impact users' experience in a negative way.
Are broken websites good for users?
Again, you're assuming that the developers who made the decision don't know what they're doing. The data they had indicated that the vast majority of websites that users visit don't rely on this feature. The sites that broke were programming tutorials which, as we've already established, we expect to break at some point. And again, if a large number of websites break, users switch browsers. The entire reason why people use Chrome is because websites just work in it, whereas in other browsers, they don't.
Developers are not the majority of users on the internet; we're an incredibly small portion of the users on the web. It's objectively false to say that this impacted the majority of users in a negative way.
You seem to be talking about JS syntax that hasn't yet made it to stage 4 and vendor-prefixed CSS. Sorry, but that's a nonsensical comparison.
Market forces cease to be meaningful as you approach monopoly conditions. Regardless, users have no meaningful choice when browsers act in concert. If browsers' and users' interests truly were aligned, the W3C wouldn't regard them as separate constituencies in its famous conflict resolution clause.
Even if you accept the premise that page loads is a suitable metric (read the article; I don't), even Chrome have acknowledged that the data is inadequate.
And to respond to your dismissive point about 'programming tutorials', the article already provided an example of someone being unable to cancel a recurring payment because of this change. I heard plenty of examples of equivalent severity. If top-level dialogs were removed, the breakage would be orders of magnitude worse.
@samwightt You speak on behalf of the 'average user' quite often in your replies here, but you maybe shouldn't, since you make assertions like 'and again, if a large number of websites break, users switch browsers.' I'd love to see evidence to back this up, because, anecdotally, this is absolutely not true. Do you actually think the 'average user' is aware different browsers use different rendering engines?
That said, catering to the 'average user', or the majority of browser users is also just an insane idea.
Also: I'm honestly a little surprised at how much credit you give the Chrome team in general. As Rich mentioned elsewhere, Chrome is a product developed by an advertising company, and acting like they are the benevolent steward and saviours of the web is a little far-fetched.
Ultimately, this situation reflects very poorly on the Chrome team for several reasons:
1) The complete lack of meaningful communication
2) Largely ignoring the feedback provided by the few developers who were aware of this in advance (or more likely, saw websites break), and merely delaying the change.
3) Failure to consider other solutions to a completely valid problem.* Phishing/scamming efforts online are absolutely a problem, but why is this the fix?
*: you may argue that, internally, they have weighed alternative solutions, but without public communication and discourse, we don't know that.
I'd recommend reading through this awesome document from the Blink team that describes how they don't take breaking changes lightly, and gives tons of examples of breaking changes that have been made before.
Have you read through this document? Has anyone at Google read through this document?
I have.
First, and foremost, "gives tons of examples of breaking changes that have been made before." is not an excuse to have more and more breaking changes. Moreover, there are great examples that show exactly why breaking changes have to be handled with care.
So let's look into that document, shall we?
As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial... So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!
0.006% of page loads using alert()
0.003% of page loads using confirm()
So. "Small but not trivial" and significantly heavier than "even 0.0001%"
Immediately after that we have:
Relevant example cases:
...
Remove SVGPathSeg interfaces
Usage was around 0.001% but generated quite a lot of complaints (and hasn’t been removed in other browsers).
So, no. 0.001% doesn't mean you can just remove it.
Let's skip ahead to an example directly relevant to this issue:
Minimizing web developer impact
Ease of adaptation
Relevant example cases:
Remove showModalDialog Usage reported at <0.006% of PageViews but there was no great work-around (especially for sites depending on the blocking nature) and ultimately caused a LOT of user and developer pain, particularly within enterprises (exacerbated by the lack of visibility into enterprise use cases).
Look. The exact same issue as with alert.
Do you know what one of the suggestions for that was? "To announce these changes at least 6 months beforehand, and to provide developers with a clear upgrade path, alternatives, workarounds and polyfills".
Where's all that?
Oh, look. Some of it is right there in the document:
Outreach
We have more tolerance for riskier breaking changes when some outreach has been done for impacted sites / libraries. For example, if a blog post has been published which shows up as one of the first few search results when searching for the console error message generated as a result of the break. Ultimately we want to minimize the cost to web developers of understanding and dealing with breaking changes.
Have they done any of that? Of course not.
And here's the best quote of all:
It’s important for browser engineers to resist the temptation to treat breaking changes in a paternalistic fashion. It’s common to think we know better than web developers, only to find out that we were wrong and didn’t know as much about the real world as we thought we did. Providing at least a temporary developer opt-out is an act of humility and respect for developers which acknowledges that we’ll only succeed in really improving the web for users long-term via healthy collaborations between browser engineers and web developers.
Instead, we've seen high-visibility Chrome people be consistently dismissive, condescending, ignorant and so on.
Oh. And don't forget: they are removing this functionality, and there's literally nothing in the pipeline to replace it.
Oh. And don't forget: they are removing this functionality, and there's literally nothing in the pipeline to replace it.
As a developer there is never a reason to use these antiquated (nonsensical and legacy) application flow functions. As developers we can easily implement the required functionality ourselves, ensuring our own application flow.
Let's put this into things/perspective users and developers can/should understand. (Noting; It actually currently only entails cross-origin iframe usage and a possible future complete removal from the spec).
As a user I do not want 3rd party scripts possibly pretending they are the site I am visiting; i.e. alert/confirm with clicks to some nefarious site => cross-origin-removal (what it is all about)
As a user I do not want a site/app possibly pretending they are the browser/os; i.e. alert/confirm with clicks to some nefarious site => complete-removal (what it will become)
As a developer I do not want to rely on "a" browser for my application flow. => complete-removal (what it will become)
I wholeheartedly agree with @samwight comments. The argument against his comments are mostly making elephants from ants (or is that ... from ...).
As developers we should not accept that "old" is better, above "safer" is better. We live in a world wherein we know that the web is abused. As true developers we should all be behind this proposed change (spec from day1/not break the web arguments are superfluous as the current real world usage is mostly only nefarious cross origin scripts).
Are there really any real world examples of the usage? No; only tutorials. Tutorials are what they are; mostly always need to change to be applicable; given the weather. This is the weather.
p.s.
A lot of people are stating nuclear silos confirm etc. The only real world apps which use these functions are already probably running on isolated browsers that are fixed (i.e. app built for IE 5.5). These apps are not nuclear silo apps; those run with VBasic ;-) Apart from tutorials there are no real world examples that merit the usage of these methods.
p.p.s. I wrote this fast on a mobile so I apologize for typ0s etc
As a developer there is never a reason to use these antiquated (nonsensical and legacy) application flow functions.
The article clearly stated the reasons. You decided to dismiss them out of hand
As developers we can easily implement the required functionality ourselves
That's the thing though: you can't easily implement this functionality. Saying that you can easily implement this functionality betrays the fact that you know very little of what goes into implementing into a proper accessible dialog.
On top of that the "replacement" that browsers have (<dialog>) is so bad that Chrome devs themselves argued for its removal. But you'd know that if you read the article.
As a user I do not want...
So instead of solving these issues browser implementors decided to remove a feature without providing a proper replacement.
spec from day1/not break the web arguments are superfluous as the current real world usage is mostly only nefarious cross origin scripts
And you know this how? From numbers that Chrome provided from public usage data that they themselves admitted was incomplete and incorrect?
Apart from tutorials there are no real world examples that merit the usage of these methods.
The article that you didn't read provides real world usage examples.
But its also telling how you dismiss tutorial sites out of hand because in your mind they are entirely unimportant. What else is unimportant to you?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This post seems to assume (just from how I read it):
alert()is being used for today is a valid use of the feature.You're assuming that
alert()is a good feature for the rest of the web. Ultimately, browser vendors have access to a lot more data and a lot more user research than we do, and they seem to have concluded that that's not the case, that it's not a good feature.What is good for developers is not necessarily what is good for all users on the web. We accept that this is the case with accessibility: developers often have to write more code and rethink their UIs, but that makes the UIs a better experience for everyone. It's not appropriate to apply that approach with accessibility and to not apply that approach everywhere else. If
alert()is not a good user experience (which seems to be the case), then you using it for debugging is a hack; it's not being used for its intended use. Ifdebugger;or other statements aren't sufficient for what you're debugging, then we should absolutely discuss how to improve them, but we shouldn't program based on hacks.Programming tutorials break all the time, not just JS tutorials. Library versions go out of date. Unapproved JavaScript syntax (like decorators) breaks. Behavior of certain features changes and causes breaks. Best practices change, which could be seen as breakage. Breakage on the web has happened many times before: with Flash, with different CSS properties, with old JS behavior, etc. We are not special. If that breakage was okay (which I don't know your position on), then we can't say that this breakage is not okay.
You're missing the point.
You're taking browser vendors' statements about what is best for users — and that they are making decisions in users' interests rather than their own — on faith. Even if browsers' and users' interests do coincide, and even if their data (which they admitted last week was woefully inadequate) could be trusted, there is nothing forcing that alignment. It's naïve to believe otherwise.
Whether
alertis good-for-developers-but-bad-for-users is a valid question, but that's not the only consideration here. Are broken websites good for users?You seem to be talking about JS syntax that hasn't yet made it to stage 4 and vendor-prefixed CSS. Sorry, but that's a nonsensical comparison.
No, based on their track record, which is extremely good. Browser vendors have a reliable track record of implementing changes that are good for the average user and that improve user experience. No group of developers puts more effort into researching how users interact with browser and understanding how they think. It's just logical to assume that they aren't making these decisions for bad reasons and that they are much more likely than us to understand what users want.
The browser market literally enforces this????? If Chrome implements a change that decreases user experience enough, users switch browsers. That's just how the browser market works lol. Browser vendors are highly incentivized not to add features that impact users' experience in a negative way.
Again, you're assuming that the developers who made the decision don't know what they're doing. The data they had indicated that the vast majority of websites that users visit don't rely on this feature. The sites that broke were programming tutorials which, as we've already established, we expect to break at some point. And again, if a large number of websites break, users switch browsers. The entire reason why people use Chrome is because websites just work in it, whereas in other browsers, they don't.
Developers are not the majority of users on the internet; we're an incredibly small portion of the users on the web. It's objectively false to say that this impacted the majority of users in a negative way.
I'm not. I'd recommend reading through this awesome document from the Blink team that describes how they don't take breaking changes lightly, and gives tons of examples of breaking changes that have been made before.
Here's a link to the initial proposal to remove cross-origin alert, prompt, and confirm, along with the data about how it would affect site breakage.
This would affect:
Market forces cease to be meaningful as you approach monopoly conditions. Regardless, users have no meaningful choice when browsers act in concert. If browsers' and users' interests truly were aligned, the W3C wouldn't regard them as separate constituencies in its famous conflict resolution clause.
Even if you accept the premise that page loads is a suitable metric (read the article; I don't), even Chrome have acknowledged that the data is inadequate.
And to respond to your dismissive point about 'programming tutorials', the article already provided an example of someone being unable to cancel a recurring payment because of this change. I heard plenty of examples of equivalent severity. If top-level dialogs were removed, the breakage would be orders of magnitude worse.
@samwightt You speak on behalf of the 'average user' quite often in your replies here, but you maybe shouldn't, since you make assertions like 'and again, if a large number of websites break, users switch browsers.' I'd love to see evidence to back this up, because, anecdotally, this is absolutely not true. Do you actually think the 'average user' is aware different browsers use different rendering engines?
That said, catering to the 'average user', or the majority of browser users is also just an insane idea.
Also: I'm honestly a little surprised at how much credit you give the Chrome team in general. As Rich mentioned elsewhere, Chrome is a product developed by an advertising company, and acting like they are the benevolent steward and saviours of the web is a little far-fetched.
Ultimately, this situation reflects very poorly on the Chrome team for several reasons:
1) The complete lack of meaningful communication
2) Largely ignoring the feedback provided by the few developers who were aware of this in advance (or more likely, saw websites break), and merely delaying the change.
3) Failure to consider other solutions to a completely valid problem.* Phishing/scamming efforts online are absolutely a problem, but why is this the fix?
*: you may argue that, internally, they have weighed alternative solutions, but without public communication and discourse, we don't know that.
Have you read through this document? Has anyone at Google read through this document?
I have.
First, and foremost, "gives tons of examples of breaking changes that have been made before." is not an excuse to have more and more breaking changes. Moreover, there are great examples that show exactly why breaking changes have to be handled with care.
So let's look into that document, shall we?
According to your own breakdown:
This would affect:
0.006% of page loads using alert()
0.003% of page loads using confirm()
So. "Small but not trivial" and significantly heavier than "even 0.0001%"
Immediately after that we have:
So, no. 0.001% doesn't mean you can just remove it.
Let's skip ahead to an example directly relevant to this issue:
Look. The exact same issue as with alert.
Do you know what one of the suggestions for that was? "To announce these changes at least 6 months beforehand, and to provide developers with a clear upgrade path, alternatives, workarounds and polyfills".
Where's all that?
Oh, look. Some of it is right there in the document:
Have they done any of that? Of course not.
And here's the best quote of all:
Instead, we've seen high-visibility Chrome people be consistently dismissive, condescending, ignorant and so on.
Oh. And don't forget: they are removing this functionality, and there's literally nothing in the pipeline to replace it.
As a developer there is never a reason to use these antiquated (nonsensical and legacy) application flow functions. As developers we can easily implement the required functionality ourselves, ensuring our own application flow.
Let's put this into things/perspective users and developers can/should understand. (Noting; It actually currently only entails cross-origin iframe usage and a possible future complete removal from the spec).
As a user I do not want 3rd party scripts possibly pretending they are the site I am visiting; i.e. alert/confirm with clicks to some nefarious site => cross-origin-removal (what it is all about)
As a user I do not want a site/app possibly pretending they are the browser/os; i.e. alert/confirm with clicks to some nefarious site => complete-removal (what it will become)
As a developer I do not want to rely on "a" browser for my application flow. => complete-removal (what it will become)
I wholeheartedly agree with @samwight comments. The argument against his comments are mostly making elephants from ants (or is that ... from ...).
As developers we should not accept that "old" is better, above "safer" is better. We live in a world wherein we know that the web is abused. As true developers we should all be behind this proposed change (spec from day1/not break the web arguments are superfluous as the current real world usage is mostly only nefarious cross origin scripts).
Are there really any real world examples of the usage? No; only tutorials. Tutorials are what they are; mostly always need to change to be applicable; given the weather. This is the weather.
p.s.
A lot of people are stating nuclear silos confirm etc. The only real world apps which use these functions are already probably running on isolated browsers that are fixed (i.e. app built for IE 5.5). These apps are not nuclear silo apps; those run with VBasic ;-) Apart from tutorials there are no real world examples that merit the usage of these methods.
p.p.s. I wrote this fast on a mobile so I apologize for typ0s etc
The article clearly stated the reasons. You decided to dismiss them out of hand
That's the thing though: you can't easily implement this functionality. Saying that you can easily implement this functionality betrays the fact that you know very little of what goes into implementing into a proper accessible dialog.
On top of that the "replacement" that browsers have (
<dialog>) is so bad that Chrome devs themselves argued for its removal. But you'd know that if you read the article.So instead of solving these issues browser implementors decided to remove a feature without providing a proper replacement.
And you know this how? From numbers that Chrome provided from public usage data that they themselves admitted was incomplete and incorrect?
The article that you didn't read provides real world usage examples.
But its also telling how you dismiss tutorial sites out of hand because in your mind they are entirely unimportant. What else is unimportant to you?