3 ms·

My objection is this paragraph: You don’t have to support old browsers and terrible setups. But you are not allowed to block them out. It is a simple matter of

My objection is this paragraph: You don’t have to support old browsers and terrible setups. But you are not allowed to block them out. It is a simple matter of giving a usable interface to end users. A button that does nothing when you click it is not a good experience. Test if the functionality is available, then create or show the button. This is as simple as it is. lolwut Giving a usable interface for old browsers is definitely a form of support. You're telling me that my app has to support the Gopher protocol too? At the end of the day, it depends on your Product and its Users. Some have to support many browsers. Some don't. No one expects an American vending machine to accept Euros as payment.

vonklaus 11y ago
And to your point, if you have a site that doen't really rely on JS, sure you can throw some no-js classes in and get the lowest hanging fruit, but what then? I mean, don't you usually check if something succeeded by using javascript? You have to send them the script to see if it fails. Then, sure don't show them the button, obviously your button and the communication with your entire backend is pretty unimportant, just show them the "browse happy your using a strong outdated browser" text. I think it was Brian Chesky, or maybe Steve Jobs, who talked about how the difference between being successful was having a site that didn't work for 3% of users vs. having a site that didn't work for 3% or users but you didn't show them a button.
pdkl95 11y ago
> Gopher Nobody said anything about non-HTML markup. This is a straw-man argument. > form of support The entire point of implementing a proper progressively enhanced design is that you don't need to add extra support for older browsers. Handling missing features is important because "older browsers" isn't the only time errors happen. Progressive enhancement is mostly good error checking. You should handle missing JS features (or missing JS entirely) for the same reason you should be checking calls to fopen(3) for NULL; skipping that check means you simply fail badly on errors. A webpage that sends an empty body tag is similar to a traditional program that crashes without any error message because it tried to use a NULL file handle when opening it's config file. If your tools aren't handling a lot of this for you (Rails has since very early versions), maybe get better tools or maybe bug vendor? > usable interface Nobody expects identical functionality when the JS doesn't load. Obviously, some features won't work, and it may not look as nice. Choosing exactly how to handle an error condition is one of the many design decisions programmers have to make. Skipping optional features like dynamic page rewriting (pjax or even simple remote ajax forms) may be slower, but skipping those features and leaving links/forms as traditional page-reloads is a better way to handle a failed JS download than blocking the entire page with an error message (or worse: leaving the person who visited your site with a blank page). // I suspect that a lot of the "interface" that is apparently so important to get right is advertising.

vonklaus 11y ago

And to your point, if you have a site that doen't really rely on JS, sure you can throw some no-js classes in and get the lowest hanging fruit, but what then? I mean, don't you usually check if something succeeded by using javascript? You have to send them the script to see if it fails. Then, sure don't show them the button, obviously your button and the communication with your entire backend is pretty unimportant, just show them the "browse happy your using a strong outdated browser" text. I think it was Brian Chesky, or maybe Steve Jobs, who talked about how the difference between being successful was having a site that didn't work for 3% of users vs. having a site that didn't work for 3% or users but you didn't show them a button.

pdkl95 11y ago

> Gopher Nobody said anything about non-HTML markup. This is a straw-man argument. > form of support The entire point of implementing a proper progressively enhanced design is that you don't need to add extra support for older browsers. Handling missing features is important because "older browsers" isn't the only time errors happen. Progressive enhancement is mostly good error checking. You should handle missing JS features (or missing JS entirely) for the same reason you should be checking calls to fopen(3) for NULL; skipping that check means you simply fail badly on errors. A webpage that sends an empty body tag is similar to a traditional program that crashes without any error message because it tried to use a NULL file handle when opening it's config file. If your tools aren't handling a lot of this for you (Rails has since very early versions), maybe get better tools or maybe bug vendor? > usable interface Nobody expects identical functionality when the JS doesn't load. Obviously, some features won't work, and it may not look as nice. Choosing exactly how to handle an error condition is one of the many design decisions programmers have to make. Skipping optional features like dynamic page rewriting (pjax or even simple remote ajax forms) may be slower, but skipping those features and leaving links/forms as traditional page-reloads is a better way to handle a failed JS download than blocking the entire page with an error message (or worse: leaving the person who visited your site with a blank page). // I suspect that a lot of the "interface" that is apparently so important to get right is advertising.