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.
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?