Visible URLs are a UX thing. This is much worse than that. If they actually removed alert, confirm, and prompt from same origin pages, it would cause massive breakage basically just so they can optimize their JS pipelines. It’s a really bad idea. It makes much more sense to say it doesn’t work in JS modules or something like that instead of planning for a full on breakage.
I’ve been using JS since the late 90s and I haven’t even seen alert/confirm/prompt outside of toy tutorials or horrendous code since roughly 2005. I don’t find the arguments in this blog very convincing.
It’s also incredibly clickbait/alarmist, which is an immediate eye roll.
I use confirm for actions that cannot be undone and are potentially dangerous. Why wouldn’t I? The alternative is to write a lot of code to throw up a modal div that does the same thing. Might as well do it natively.
Half the argument of the blog post though is that “toy tutorials” are important and valuable in a way that isn’t captured by how often the feature is used in production. And most of the rest is about how actually, it’s valuable that code from 2005 still works. I think you are missing the forest for the trees.
The article considerably overstates what the Chrome team is actually intending to ship: it’s disabling cross-origin alert inside iframes, not alert entirely. Most of the article seems to be an extremely uncharitable reading of Dominic hoping that “one day”, “in the far future”, “maybe” (literally these are direct quotes!) they can remove blocking APIs like alert — not that they have any plans to do so now or any time soon.
I don’t think the GP is missing the forest for the trees; I think the author is making a mountain out of a molehill.
“Some day” tends to come a lot sooner than we’d expect.
This is the sort of thing people use to justify further encroachment down the line (“Well we already disable it for iframe stuff…”).
This directly reduces the utility of using iframes–and some folks still use those on occasion, and it is exceedingly tacky to unilaterally decide to break their workflows.
If you’re making a codepad-like site, you can also inject a polyfill for alert() etc in the user-controlled iframe to keep things working. Until you’re done locking down the codepad for arbitrary user scripts to run without problems, this is probably one of the smaller tasks.
I use alert() and confirm(). It’s easy, simple, works, and doesn’t even look so bad since Firefox 89. I don’t think my code is “horrendous”; it’s just the obvious solution without throwing a bunch of JS at it.
I agree this blog post isn’t especially great though.
Sorry, I read your reply in the context of the blog post (i.e. your code is going to break).
My line about horrendous code is hyperbolic, but the fact is that alert/confirm/prompt don’t offer customizability to make for a consistent, well-made UX. Maybe it’s not a problem for certain audiences (usually things like internal tools for devs end up having them), but most customer-facing solutions require more to their experience.
I’m not saying they should remove them right now, but a day in the future where they go away (presumably deprecated due to a better option) is not something we should be dreading. Who knows if that day will even come.
At $JOB we have used prompt for some simple scenarios where it solves the problem of getting user input in a scenario in some sync-y code, and was no fuss.
We integrate with Salesforce through an iframe. This change caused us to have to like redo a whole tiny thing to get stuff working again (using a much heavier modal thing instead of, well, a call to prompt). It wasn’t the end of the world, but it was annoying and a real unforced error.
We would love a scenario where browsers offered more rich input in a clean way (modals have been in basically every native GUI since the beginning of time!). I’m sure people would be way less frustrated if Chrome offered easy alternatives that don’t rely (for example) on z-index-overlays (that can break for a billion reasons) or stuff like that.
Sometimes you just want input from somebody in a prompt-y way
That is still no reason to remove a perfectly functional feature that has worked reliability for decades and requir a orders of magnitude less resources than the alternative. Both human and computational resources.
I use it all the time on simple UIs I write for my own usage or for restricted groups of users.
The amount of resources that could be saved if we favoured well known, tried and true technology rather than the new aesthetically shiny thing, is astonishing.
No, Linux has suffered precisely because it does not offer a native GUI, or UI at all, forcing everyone to reinvent basic functionality like on the web.
Quoting the W3C prioritization guidelines is both entirely on the nose, and missing the point: the W3C no longer is in the driver’s seat, because it insisted on ignoring browser vendors. So the vendors made WHATWG, and W3C is mostly a rubber stamp operator now. If W3C disagrees with WHATWG, guess what ships: it’s what the vendors in WHATWG want, not what the W3C demands.
I generally appreciate “don’t break the web,” but I also don’t think it’s useful to be dogmatic about it. There are plenty of counterexamples of ecosystems that work just fine — or are even improved by — breaking changes. The iOS ecosystem immediately comes to mind, for example. I like that old websites mostly still work and that the web is more stable than iOS, but I also don’t think every minute detail needs to be frozen in time to be true to a philosophical vision of the web. If something is generally bad for the ecosystem, and rarely used, removing it doesn’t seem like a sin. In my experience 99% of the time an old website is broken, it’s broken from link rot; cross-origin iframe alert being disabled hardly seems to rate in comparison to that.
And cross-origin alert inside an iframe frankly doesn’t seem that useful. The majority of the use cases the author brings up won’t break at all: if you’re working on your own website and using it as a printf-debug, it seems very unlikely you’d be using it cross-origin. The same is true for students: cross-origin iframe anything is a pain; most students are not starting from there and teachers are doing them a disservice if they are. Codepen will likely have to do something special to handle the fact that alert won’t work when embedded in other sites, but TBH a polyfill, or just popping up a modal explaining why it doesn’t work, doesn’t seem unreasonably difficult.
The author makes a very strong claim to broaden this essay by claiming that Chrome is intending to deprecate alert and other blocking APIs entirely, without any replacements or considering any of their use cases. This is a fairly uncharitable reading of a comment Dominic made in the thread about removing cross-origin alert inside an iframe, which I’ll reproduce here:
One day (far in the future), maybe we can remove alert/confirm/prompt/beforeunload entirely. Incremental steps like this one are exciting.
This is not a comment that warrants outrage, in my opinion. “Far in the future” and “maybe” are pretty important parts of the sentence. Yes, Chrome would like them to be eventually gone, but assuming the worst and that there will be no consideration of usage or reasonable migration paths or replacements, way in advance, seems a little unreasonable.
The users.
Hence if someone found that a given standard risks the users beyond reasonable the right thing to do is change it. Even if it creates discomfort for developers (With real empathy).
The real question here isn’t if it is hard for developers of fair to them. The question is how high is the risk leaving things as they are.
The users should own the web, but in the current ecosystem (ad supported, walled gardens, etc), the people paying for the a large portion of web are the browser vendor(s) and major sites that can impact them (facebook, amazon, etc)
Wouldn’t it make more sense to display iframe alerts inside of their iframes? Render them as though they’re a <dialog> inside of that iframe’s <body>, and that will prevent embedded ads from displaying scam popups, while leaving some use cases (CodePen) unchanged.
It would still break code that’s using invisible iframes to display alerts, but I’d imagine that’s a much smaller proportion of legitimate web apps.
This is coming from the same brilliant team who stupidly tried to hide urls for our own good.
Visible URLs are a UX thing. This is much worse than that. If they actually removed alert, confirm, and prompt from same origin pages, it would cause massive breakage basically just so they can optimize their JS pipelines. It’s a really bad idea. It makes much more sense to say it doesn’t work in JS modules or something like that instead of planning for a full on breakage.
Disabling alert and confirm in JS modules wouldn’t fix the concerns about scams.
Who knew that promo packets would be the downfall of the World Wide Web?
I’ve been using JS since the late 90s and I haven’t even seen alert/confirm/prompt outside of toy tutorials or horrendous code since roughly 2005. I don’t find the arguments in this blog very convincing.
It’s also incredibly clickbait/alarmist, which is an immediate eye roll.
I use confirm for actions that cannot be undone and are potentially dangerous. Why wouldn’t I? The alternative is to write a lot of code to throw up a modal div that does the same thing. Might as well do it natively.
Wait until you meet enterprise software!
In the relevant bug tracker discussion someone says this broke ERP software with hundreds of thousands of users.
Half the argument of the blog post though is that “toy tutorials” are important and valuable in a way that isn’t captured by how often the feature is used in production. And most of the rest is about how actually, it’s valuable that code from 2005 still works. I think you are missing the forest for the trees.
The article considerably overstates what the Chrome team is actually intending to ship: it’s disabling cross-origin
alertinside iframes, notalertentirely. Most of the article seems to be an extremely uncharitable reading of Dominic hoping that “one day”, “in the far future”, “maybe” (literally these are direct quotes!) they can remove blocking APIs likealert— not that they have any plans to do so now or any time soon.I don’t think the GP is missing the forest for the trees; I think the author is making a mountain out of a molehill.
Few things:
You can still do your little toy tutorials with alert/confirm/prompt, just don’t do them in an iframe?
If you’re making a codepad-like site, you kind of have to put all the user-submitted JS in an alert so it’s not on your own domain.
If you’re making a codepad-like site, you can also inject a polyfill for alert() etc in the user-controlled iframe to keep things working. Until you’re done locking down the codepad for arbitrary user scripts to run without problems, this is probably one of the smaller tasks.
Can you make the polyfill block?
I use
alert()andconfirm(). It’s easy, simple, works, and doesn’t even look so bad since Firefox 89. I don’t think my code is “horrendous”; it’s just the obvious solution without throwing a bunch of JS at it.I agree this blog post isn’t especially great though.
Do you use it in a cross-origin iframe?
No, but your comment made no mention of that:
Sorry, I read your reply in the context of the blog post (i.e. your code is going to break).
My line about horrendous code is hyperbolic, but the fact is that alert/confirm/prompt don’t offer customizability to make for a consistent, well-made UX. Maybe it’s not a problem for certain audiences (usually things like internal tools for devs end up having them), but most customer-facing solutions require more to their experience.
I’m not saying they should remove them right now, but a day in the future where they go away (presumably deprecated due to a better option) is not something we should be dreading. Who knows if that day will even come.
At $JOB we have used prompt for some simple scenarios where it solves the problem of getting user input in a scenario in some sync-y code, and was no fuss.
We integrate with Salesforce through an iframe. This change caused us to have to like redo a whole tiny thing to get stuff working again (using a much heavier modal thing instead of, well, a call to
prompt). It wasn’t the end of the world, but it was annoying and a real unforced error.We would love a scenario where browsers offered more rich input in a clean way (modals have been in basically every native GUI since the beginning of time!). I’m sure people would be way less frustrated if Chrome offered easy alternatives that don’t rely (for example) on z-index-overlays (that can break for a billion reasons) or stuff like that.
Sometimes you just want input from somebody in a prompt-y way
You haven’t seen a lot of business to business software then.
That is still no reason to remove a perfectly functional feature that has worked reliability for decades and requir a orders of magnitude less resources than the alternative. Both human and computational resources.
I use it all the time on simple UIs I write for my own usage or for restricted groups of users.
The amount of resources that could be saved if we favoured well known, tried and true technology rather than the new aesthetically shiny thing, is astonishing.
It’s not about “shiny things” but about use experience. Linux has suffered for decades due to the approach you’re talking about.
No, Linux has suffered precisely because it does not offer a native GUI, or UI at all, forcing everyone to reinvent basic functionality like on the web.
Quoting the W3C prioritization guidelines is both entirely on the nose, and missing the point: the W3C no longer is in the driver’s seat, because it insisted on ignoring browser vendors. So the vendors made WHATWG, and W3C is mostly a rubber stamp operator now. If W3C disagrees with WHATWG, guess what ships: it’s what the vendors in WHATWG want, not what the W3C demands.
I generally appreciate “don’t break the web,” but I also don’t think it’s useful to be dogmatic about it. There are plenty of counterexamples of ecosystems that work just fine — or are even improved by — breaking changes. The iOS ecosystem immediately comes to mind, for example. I like that old websites mostly still work and that the web is more stable than iOS, but I also don’t think every minute detail needs to be frozen in time to be true to a philosophical vision of the web. If something is generally bad for the ecosystem, and rarely used, removing it doesn’t seem like a sin. In my experience 99% of the time an old website is broken, it’s broken from link rot; cross-origin iframe
alertbeing disabled hardly seems to rate in comparison to that.And cross-origin
alertinside an iframe frankly doesn’t seem that useful. The majority of the use cases the author brings up won’t break at all: if you’re working on your own website and using it as a printf-debug, it seems very unlikely you’d be using it cross-origin. The same is true for students: cross-origin iframe anything is a pain; most students are not starting from there and teachers are doing them a disservice if they are. Codepen will likely have to do something special to handle the fact thatalertwon’t work when embedded in other sites, but TBH a polyfill, or just popping up a modal explaining why it doesn’t work, doesn’t seem unreasonably difficult.The author makes a very strong claim to broaden this essay by claiming that Chrome is intending to deprecate alert and other blocking APIs entirely, without any replacements or considering any of their use cases. This is a fairly uncharitable reading of a comment Dominic made in the thread about removing cross-origin
alertinside an iframe, which I’ll reproduce here:This is not a comment that warrants outrage, in my opinion. “Far in the future” and “maybe” are pretty important parts of the sentence. Yes, Chrome would like them to be eventually gone, but assuming the worst and that there will be no consideration of usage or reasonable migration paths or replacements, way in advance, seems a little unreasonable.
The users.
Hence if someone found that a given standard risks the users beyond reasonable the right thing to do is change it. Even if it creates discomfort for developers (With real empathy).
The real question here isn’t if it is hard for developers of fair to them. The question is how high is the risk leaving things as they are.
The users should own the web, but in the current ecosystem (ad supported, walled gardens, etc), the people paying for the a large portion of web are the browser vendor(s) and major sites that can impact them (facebook, amazon, etc)
Wouldn’t it make more sense to display iframe alerts inside of their iframes? Render them as though they’re a
<dialog>inside of that iframe’s<body>, and that will prevent embedded ads from displaying scam popups, while leaving some use cases (CodePen) unchanged.It would still break code that’s using invisible iframes to display alerts, but I’d imagine that’s a much smaller proportion of legitimate web apps.
Good. They should have been killed years ago.
Edit: Google does a lot of bad things these days, but this ain’t one of them.