The OP (ShrimpChip80) is already on the right track by considering the options. Possibly more users (who may == more customers) will be able to visit and use the site.
And if s/he ultimately decides to use scripting-only anyway, I assume that would still be after a good weighing of options and not carelessly tossed into the wastebasket. Which to me is one of the traits of a good (or going to be good) web developer.
ShrimpChip? Is that like kroepoek?
[ot]
You don’t seem to have heard of accessibility. There are many people who have poor eyesight, or limited motor skills etc, perhaps forced to use assistive technologies that couldn’t make use of JS if they wanted to.
To make sure that everyone can access a site, no matter what circumstances they face, is not old fashioned. It’s cutting-edge.[/ot]
It’s also called “doing the job properly” and “getting the point of HTML”
Instead of just “sleazing it out any old way” and practicing little more than lame excuses for not being a web professional.
[ot]
I’m thinking “cutting edge” in the sense that still no one (so far as I know) has worked out how to make a drop down list truly accessible (or has Yahoo! nailed it?), although people are getting closer. (Of course, this begs the question of why you’d use those rotten things anyway …)[/ot]
[ot]If Yahoo has made an “accessible” dropdown menu, then they did it with 3 times the code necessary and probably a 300kb JS library to assist. Lawlz.
Closest I could get to was Motorrijschool EMO and what’s still quite inaccessible with that one is from the design… how small the dropdown options are. But I could only code it, not change how it was supposed to look.
And, I’m pretty sure EarlyOut has heard of accessibility, and cares. Every developer asks themselves how far they should go.
As a developer, do I really need to develop a page that will provide you with a reasonably complete experience even if you turn off everything?
Those who turn things off are perhaps a different category than those who must have it off or do not have it in the first place (such as the low-bandwidth users Crusty mentioned… usually mobile phone users are the ones who turn off images for example (but not Javascript since more and more web apps for phones use it, esp for “Touch Events”… yet Javascript is the quickest way even today to drain the battery and make high use of the CPU)).[/ot]
[ot]
Nice work, poes. It works well with VoiceOver, although I wasn’t able to tab through it via the keyboard. Does it work in Opera? (Must learn how to do it with that browser. FF tabbing didn’t really work, unless I’m missing something.)[/ot]
[ot]Works in my browsers tabbing. With or without JS. It’s just CSS.
For Opera need to Shift+arrow[/ot]
We all accept that, if a user turns off all stylesheets and scripts, they won’t get an optimal experience. It won’t look so fancy, there may be some enhancement features that don’t work. That’s fine. All we want is for the essential base content to be there and accessible.
Think of another aspect to it. The fastest growing areas of internet usage are (a) developing countries, which typically have neither the infrastructure nor the equipment to support high-bandwidth sites using the latest technology, and (b) mobile phones – which are not limited to top-end smartphones. Many phone browsers don’t fully support Javascript, so if you’re relying on it for essential functionality such as navigation, you’re cutting out a large section of mobile phone users.
Should I use only bright colors in case you set the brightness on your monitor down to almost zero? Should I never use an accented character in case you’re restricted to ASCII? Do I have to provide a graceful degredation path if you’re using an LA120 with a 1200-baud modem to access the site?
If I have my monitor set up in a significantly non-typical way, the chances are that I will also be using a custom stylesheet, which means that every site will meet whatever contrast and colour requirements I have – as long as it’s been designed correctly.
If I’m using a browser that won’t display anything other than ASCII then it should degrade unsupported characters to the nearest equivalent or a suitable combination. So á would come out as a, → would come out as -> and so on. That’s been the case since I was using Lynx in the last millennium.
If I’m using a 1200 baud modem then I should take whatever steps I want to improve the loading speed. That’s likely to involve turning off images and plug-ins, and possibly stylesheets and scripts. Sure, I understand I won’t be able to watch videos – that’s never going to be possible with that transfer rate – but I still expect the basic text content to be available.
Furthermore HTML 4.01 was designed to be semantic and had another advantage over *.txt in that it allowed the use of hyperlinks. JS is not a W3C technology, client-side scripts can move and alter the browser dimensions and so forth, normative Strict HTML 4.01 and CSS cannot resize the browser, etc.
Regarding the support of characters - that is up to the user agent vendor not the web author. All good browsers support the Unicode repertoire anyway. HTML 4.01 Strict does not convey colour either (because not all browsers are visual) and provides fallbacks for ‘alternative’ content or objects, like images.