3 ms·

I have a completely different viewpoint on this topic that probably won't be very popular – but, if we're talking about writing experiences for those with JS tu

by tomkin 15y ago

I have a completely different viewpoint on this topic that probably won't be very popular – but, if we're talking about writing experiences for those with JS turned off, isn't that the same as having to write code for an IE6 experience? I imagine the percentage of people having JS turned off is roughly in the ballpark of how many IE6 users we have left to deal with. Why has this been turned into a purist argument when it really should be about practicality and quality of one's work? Though, I do get the gripe about not even seeing what the site is about before enabling JS. Even the weakest IE6 experiences seem to have some semblance of the subject matter.

EvilTerran 15y ago
Well... dealing with IE6 involves a lot of working around quirks in its treatment of plain ol' HTML and CSS, even if the site's completely static. Dealing with the no-JS crowd wouldn't entail that at all, so at least it should be an easier sliver of the market to cater to than the IE6 crowd.
masklinn 15y ago
> if we're talking about writing experiences for those with JS turned off, isn't that the same as having to write code for an IE6 experience? Not quite: the major issue with IE6 is that it fucks things up by providing partial implementations. A no-scripted browser "just" provides no scripting, static content and styling are perfectly handled just not additional behaviors. These are very, very different situations.
- tomkin 15y ago
  I agree with that, that they are very different. What I'm saying is, if you're going to start coding for minor audiences – where do you draw the line? And how would you explain to your client/employer that you will take extra care to make sure people with no JS get love but IE6 users get Chrome Frame/redirect?
  - EvilTerran 15y ago
    Where you draw the line isn't just about fractions of the market, though -- it's about market fraction ÷ effort to implement. If there's twice as many IE6 users as no-JS users, but it takes ten times as much work to get your site functioning on IE6 than on a modern browser with no JS, you're better off courting the no-JS segment.
ef4 15y ago
The difference I see is that this author isn't asking for anything more than a little bit of useful static text. No meaningful code changes, just a tiny snippet of plain old HTML will do the trick. That's dramatically easier than trying to make a complex app work in IE6.
- benmccann 15y ago
  Every site would have the same exact text. "Please enable JavaScript because we don't want to develop a second version of our site for an extremely small constituency".
- tomkin 15y ago
  I agree. The article itself is correct, but if you read through the comments here, you'll find it often gets to be about purity and how entire applications should be written to degrade gracefully. When you start talking about that kind of work – I have to ask what the difference is between coding an entire app for no JS and IE6. You can chalk it up to good for humanity, but really it comes down to is time. Am I going to count of JS being on? Am I going to count on the user not using IE6? For a full-featured web application: Yes.
eps 15y ago
Unlike NoScript users Ppople running IE6 can't right-click and disable it at will.

by tomkin 15y ago

EvilTerran 15y ago

Well... dealing with IE6 involves a lot of working around quirks in its treatment of plain ol' HTML and CSS, even if the site's completely static. Dealing with the no-JS crowd wouldn't entail that at all, so at least it should be an easier sliver of the market to cater to than the IE6 crowd.

masklinn 15y ago

> if we're talking about writing experiences for those with JS turned off, isn't that the same as having to write code for an IE6 experience? Not quite: the major issue with IE6 is that it fucks things up by providing partial implementations. A no-scripted browser "just" provides no scripting, static content and styling are perfectly handled just not additional behaviors. These are very, very different situations.

tomkin 15y ago
I agree with that, that they are very different. What I'm saying is, if you're going to start coding for minor audiences – where do you draw the line? And how would you explain to your client/employer that you will take extra care to make sure people with no JS get love but IE6 users get Chrome Frame/redirect?
- EvilTerran 15y ago
  Where you draw the line isn't just about fractions of the market, though -- it's about market fraction ÷ effort to implement. If there's twice as many IE6 users as no-JS users, but it takes ten times as much work to get your site functioning on IE6 than on a modern browser with no JS, you're better off courting the no-JS segment.

ef4 15y ago

The difference I see is that this author isn't asking for anything more than a little bit of useful static text. No meaningful code changes, just a tiny snippet of plain old HTML will do the trick. That's dramatically easier than trying to make a complex app work in IE6.

benmccann 15y ago
Every site would have the same exact text. "Please enable JavaScript because we don't want to develop a second version of our site for an extremely small constituency".
tomkin 15y ago
I agree. The article itself is correct, but if you read through the comments here, you'll find it often gets to be about purity and how entire applications should be written to degrade gracefully. When you start talking about that kind of work – I have to ask what the difference is between coding an entire app for no JS and IE6. You can chalk it up to good for humanity, but really it comes down to is time. Am I going to count of JS being on? Am I going to count on the user not using IE6? For a full-featured web application: Yes.

eps 15y ago

Unlike NoScript users Ppople running IE6 can't right-click and disable it at will.