On 9/5/13 09:10, Henri Sivonen wrote:
Why should we surface this class of authoring error to the UI in a way that asks the user to make a decision considering how rare this class of authoring error is?
It's not a matter of the user judging the rarity of the condition; it's the user being able to, by casual observation, look at a web page and tell that something is messed up in a way that makes it unusable for them.
Are there other classes of authoring errors that you think should have UI for the user to second-guess the author? If yes, why? If not, why not?
In theory, yes. In practice, I can't immediately think of any instances that fit the class other than this one and certain Content-Encoding issues.
If you want to reduce it to principle, I would say that we should consider it for any authoring error that is (a) relatively common in the wild; (b) trivially detectable by a lay user; (c) trivially detectable by the browser; (d) mechanically reparable by the browser; and (e) has the potential to make a page completely useless.
I would argue that we do, to some degree, already do this for things like Content-Encoding. For example, if a website attempts to send gzip-encoded bodies without a Content-Encoding header, we don't simply display the compressed body as if it were encoded according to the indicated type; we pop up a dialog box to ask the user what to do with the body.
I'm proposing nothing more radical than this existing behavior, except in a more user-friendly form.
As to the "why," it comes down to balancing the need to let the publisher know that they've done something wrong against punishing the user for the publisher's sins.
-- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
