It's hard to tell but I think you've completely missed the point. I just want to very quickly speak to your security complaint. The issue comes in two flavors - user-submitted javascript can do nasty, evil things to you. You know that, I know that. Lots of people don't know it and we agree it's the application's responsibility to accept only good data. The other part of this concern is where new programmers try to use JavaScript to validate data prior to submitting something to the web server. It's that sort of usage that promotes a false sense of security since for many reasons you absolutely, 100% cannot count on JavaScript validation to be sure your data is sane. This is a task that must occur in a trusted context - usually in your serverside program prior to committing the value somewhere. There are many ways a not-particularly competent advesary can bypass your JavaScript validation. So... perhaps we're speaking at cross-issues but it's a valid point you didn't raise and one that is higher profile, IMHO.

As for CSS, decent browsers and JavaScript - I'll be honest and say I've never been particularly interested in people who turn off their JS and then complain that stuff doesn't work. What does get my goat is web site designers who put things up that my lynx client can't handle. There are two reasons you need to support text based browsers - accessibility and convenience. I'll just mention that for me it's really convenient to use lynx over ssh in some circumstances but that's really a corner case and probably only of interest to geeks who would actually do that. The primary issue is that of making your web site and it's data innaccessible to people with various handicaps. You could compare designing a inaccessible web site as being similar to parking in the handicap spot. It's not only evidence of poor taste (if you're aware of the issue and are just ignoring it) if you're doing something commercial in the US then it also has legal implications. I'm very inexpert on the legal bits (and I speak only about the US here) but I understand they run from the Americans with Disabilities Act (ADA), Section 508 of some part of federal law (I've just seen it called Section 508) and then there's the various state and local laws in addition to the client company's employment policies. Obviously this will vary between companies but where I work the Business Conduct Policy requires that Imation and it's employees not descriminate on the basis of ability (among a host of other things as well including race, religion, gender, sexual orientation etc). For me, designing something that is inaccessible can put me at risk of termination. That'd be highly unlikely seeing as how most of the people I work with aren't even aware of what our policy requires but that doesn't mean that we aren't legally liable for our compliance with all the various laws and internal policies.

I guess when it comes down to it, I do use JavaScript but I make sure the application doesn't require it in order to operate. Yes, that's also known as coding twice but oh well, there really isn't any other sane choice (unless you really just leave it all up to the server side application).

__SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;

[download]

In reply to Re: The Case for Javascript by diotalevi
in thread The Case for Javascript by BUU

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.