Contradiction of Advice?

They say not to use JavaScript for important things, but doesn't that
mean relegating JavaScript usage to frivolous effects?

It's said to consider whether it's truly necessary to use JavaScript,
whether some non-script way is available for achieving the same
result. On the one hand, good practice dictates that a site degrade
gracefully where JavaScript is concerned...but on the other, that
means that JavaScript will be used only for non-critical effects.

And speaking of effects, isn't that what JavaScript is all about --
behavior, which means actions that produce certain effects??

Prisoner at War escribió:

They say not to use JavaScript for important things, but doesn't that
mean relegating JavaScript usage to frivolous effects?

I'd say the advice is: don't risk breaking basic functionality by using
superfluous JavaScript.

Example: I'm tired of sites that replace regular links with stuff like
<a href="javascript:makeLink('/pages/products.php?id=666')"></a> and
manage to break:

- Search engines
- Open link in new tab
- Save target as
- Copy link location
- Bookmark link

.... while providing no new functionality at all. Not to mention forms
you can't submit because they have no submit button or URL and there's a
JavaScript error on the page.



--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://bits.demogracia.com
-- Mi web de humor al baño María: http://www.demogracia.com
--

On Wed, 14 May 2008 19:21:01 -0700, Prisoner at War wrote:

[...]
On the one hand, good practice dictates that a site degrade
gracefully where JavaScript is concerned...but on the other, that
means that JavaScript will be used only for non-critical effects.

Exactly. At least if you care for your users (including screenreaders,
braille keyboards, firewalled browsers with filtered JS, and all those
people who intentionally disable JS for security reasons) you'll want
to use JS (if at all) only to _enhance_ the usuablity of your page(s).

And speaking of effects, isn't that what JavaScript is all about --
behavior, which means actions that produce certain effects??

Sure. But that's an "addon" not a replacement for something that works
very well w/o JS (like links or forms). And a nice behaviour (e.g.
for supporting form input and validating it) is definitely no ersatz
(replacement) for server side validation. Only too often the behaviour
is more like infantilizing than helpful.


--
Matthias
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST Microsoft ATTACHMENTS
/ \

On 05/15/08 01:06 am, Álvaro G. Vicario wrote:

Prisoner at War escribió:
They say not to use JavaScript for important things, but doesn't that
mean relegating JavaScript usage to frivolous effects?

I'd say the advice is: don't risk breaking basic functionality by using
superfluous JavaScript.

Example: I'm tired of sites that replace regular links with stuff like
a href="javascript:makeLink('/pages/products.php?id=666')"></a> and
manage to break:

- Search engines
- Open link in new tab
- Save target as
- Copy link location
- Bookmark link

... while providing no new functionality at all. Not to mention forms
you can't submit because they have no submit button or URL and there's a
JavaScript error on the page.

An example of such a problem is <www.instantssl.com>. Using Seamonkey

v1.1.9 I cannot log onto the site because the *required* Javascript
functions crash. I reported this a week ago; it is not fixed yet.
Think about how your visitors feel about your site with all the whizbang
JS effects that prevent them from doing anything useful. Like following
links, or logging in.

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

On May 15, 5:36 am, Matthias Watermann <li... (AT) mwat (DOT) de> wrote:

Exactly. At least if you care for your users (including screenreaders,
braille keyboards, firewalled browsers with filtered JS, and all those
people who intentionally disable JS for security reasons) you'll want
to use JS (if at all) only to _enhance_ the usuablity of your page(s).

So would this be an example of "enhanced usability"...a site that
sells bras...it can have a good old-fashioned size-chart, and it can
provide a JavaScript bra-size calculator for those whose JavaScript is
enabled...is that it? Is that what the role of JavaScript is: a
fancier way of doing something that's already possible and perfectly
fine??

Seems to me that there is a necessary tension between the "promise" of
a technology like JavaScript and the dictum to, practically speaking,
not use it too much too extensively....

Sure. But that's an "addon" not a replacement for something that works
very well w/o JS (like links or forms). And a nice behaviour (e.g.
for supporting form input and validating it) is definitely no ersatz
(replacement) for server side validation. Only too often the behaviour
is more like infantilizing than helpful.

Infantilizing?? I wonder what you mean. I'm not sure that I've ever
come across a site that used JavaScript to replace good old-fashioned
HTML links and forms....

--
Matthias
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST Microsoft ATTACHMENTS
/ \

On Fri, 16 May 2008 14:05:29 -0700, Prisoner at War wrote:

On May 15, 5:36 am, Matthias Watermann <li... (AT) mwat (DOT) de> wrote:

Exactly. At least if you care for your users (including screenreaders,
braille keyboards, firewalled browsers with filtered JS, and all those
people who intentionally disable JS for security reasons) you'll want
to use JS (if at all) only to _enhance_ the usuablity of your page(s).

So would this be an example of "enhanced usability"...a site that
sells bras...it can have a good old-fashioned size-chart, and it can
provide a JavaScript bra-size calculator for those whose JavaScript is
enabled...is that it?

Yes.

Is that what the role of JavaScript is: a
fancier way of doing something that's already possible and perfectly
fine??

Yes and no. For Yes: see above. For No: You can always _add_ any
functionality you like using client-side scripting. But you should
never expect that it's executed by everyone.

So to take you example: While the javascript code might very well
remove the size-chart from the page and replace it with a button
to activate your calculator, the chart's markup should always be
there in the first place. Otherwise the boys & girls without javascript
won't be able to place their orders.

Seems to me that there is a necessary tension between the "promise" of
a technology like JavaScript and the dictum to, practically speaking,
not use it too much too extensively....

Sounds good.

Another point to keep in mind: If you happen to be in control of all
possible readers (i.e. you can enforce the browser's brand and
settings) like when writing an intranet application for a limited
and well known audience you may script to your hearts desire.

Sure. But that's an "addon" not a replacement for something that works
very well w/o JS (like links or forms). And a nice behaviour (e.g.
for supporting form input and validating it) is definitely no ersatz
(replacement) for server side validation. Only too often the behaviour
is more like infantilizing than helpful.

Infantilizing?? I wonder what you mean.

Well, I looked that up (I'm not a native English speaker). Other terms
are: paternalism, dictation, tutelage, bullying. Pick your choice.

Never seen those alters like "You must not use the X character in
this field Y"?

I'm not sure that I've ever
come across a site that used JavaScript to replace good old-fashioned
HTML links and forms....

Happy you.

The other minute I saw this:

<iframe src="javascript:''" id='__gwt_historyFrame' style='width:0;height:0;border:0'></iframe>

Even if you've configured your browser to accept IFRAME at all you'd
just get an error "The address type is unknown or unsupported" unless
you enable JavaScript as well.

Markup like <a href="#" onclick="xyz()"> or <a href="javascript:xyz()">
can be found quite too often as well. I always wonder why the respective
page writers try so hard to make their contents unreachable.


--
Matthias
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST Microsoft ATTACHMENTS
/ \

On May 18, 4:26 pm, Matthias Watermann <li... (AT) mwat (DOT) de> wrote:

You can always _add_ any
functionality you like using client-side scripting. But you should
never expect that it's executed by everyone.

Such broad generalization is way too broad for being correct. On
fading out Web 1.0 services it is indeed still an option to have
Javascript disabled or not.

For Web 2.0 generation of services Javascript is an assumed integral
part of the client - just like its ability to render HTML code.
Respectively the only fallback for "the boys & girls" who decided for
some reason to experiment with their browser settings - such fallback
is a nice message suggesting how to bring the spoiled settings back to
normal.
Just a few samples of well known Web 2.0 services that came first to
my mind and visited with Javascript disabled:
http://www.geocities.com/schools_ring/tmp/facebook.png
http://www.geocities.com/schools_ring/tmp/gmail.png
http://www.geocities.com/schools_ring/tmp/google_docs.png
http://www.geocities.com/schools_ring/tmp/youtube.png

This way it is not a question of "how much Javascript to use and what
fallback to provide?".

It is the question of the type of service one wants to implement.

On Sun, 18 May 2008 06:56:31 -0700, VK wrote:

On May 18, 4:26 pm, Matthias Watermann <li... (AT) mwat (DOT) de> wrote:
You can always _add_ any
functionality you like using client-side scripting. But you should
never expect that it's executed by everyone.

Such broad generalization is way too broad for being correct. On
fading out Web 1.0 services it is indeed still an option to have
Javascript disabled or not.

There is no such thing as "Web 1.0" - unless you're just talking
marketing gibberish. And as long as there are still browsers around
that are unsafe by design and therefor target of various script based
attacks the option to safely surf with javascript disabled is simply
indispensable.

For Web 2.0 generation of services Javascript is an assumed integral
part of the client - just like its ability to render HTML code.

"Assumed" by who? The socalled "Web 2.0" is nothing but a marketing
word. A hype to allow for some smart guys make money. For the user's
side it usually makes the things more dangerous, more expensive (in
terms of bandwidth, processing time, memory usage). And the funny thing
is, when all the gimmicks are run and all the fancy buttons are clicked,
the data must get transfered to the server nevertheless.

Respectively the only fallback for "the boys & girls" who decided for
some reason to experiment with their browser settings - such fallback
is a nice message suggesting how to bring the spoiled settings back to
normal.

Of course you're free to feel that way. I prefer to browse the web
w/o any scripting enabled until I find a presentation that's interesting
and the benefit of enabling scripting outweights the prossible problems.
Then, and only then, _I_ decide to let the browser load/execute the
javascript. And if FireBug or the ErrorConsole (depending on the
browser I'm using at that time) pops up to complain about the code
I switch the scripting off again. I emphasize that because it appears
that quite a lot of web-page builders forget that it's not them but
the readers who decide whether to use a graphical browser at all or
to dis-/enable scripting or IFRAMEs or sound or ...

Just a few samples of well known Web 2.0 services that came first to
my mind and visited with Javascript disabled:

Thank you so much! Indeed wonderful examples for how to build barriers
to keep potential users outside and annoyed. Honestly, I don't care for
such braindead sites. I'm interested in information when using the web.
And sites that hide information are just worthless - whatever the newest
hype may suggest.

[...]
It is the question of the type of service one wants to implement.

No, it's the same question as - say - fifteen years ago. How many
readers do you want? How many do you dare to reject? And of course
the answers will vary. A hype driven site won't care for cautious
people while a little shop or craftsman should try to impress the
readers without any artificial barriers. - And the "type of service"
has to be implemented in a way to satisfy the intended auditorium
not the other way around.


--
Matthias
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST Microsoft ATTACHMENTS
/ \

You can always _add_ any
functionality you like using client-side scripting. But you should
never expect that it's executed by everyone.

Such broad generalization is way too broad for being correct. On
fading out Web 1.0 services it is indeed still an option to have
Javascript disabled or not.

There is no such thing as "Web 1.0" - unless you're just talking
marketing gibberish. And as long as there are still browsers around
that are unsafe by design and therefor target of various script based
attacks the option to safely surf with javascript disabled is simply
indispensable.

For Web 2.0 generation of services Javascript is an assumed integral
part of the client - just like its ability to render HTML code.

"Assumed" by who? The socalled "Web 2.0" is nothing but a marketing
word. A hype to allow for some smart guys make money. For the user's
side it usually makes the things more dangerous, more expensive (in
terms of bandwidth, processing time, memory usage). And the funny thing
is, when all the gimmicks are run and all the fancy buttons are clicked,
the data must get transfered to the server nevertheless.

OK, you are ready for one of these Java / ASP / .NET conferences of
type "Save our traditional Web values and our as*es!" The same words,
the same arguments over years - just names are changing. I don't want
to listen it anymore - not without a good per hour payment at least.

Respectively the only fallback for "the boys & girls" who decided for
some reason to experiment with their browser settings - such fallback
is a nice message suggesting how to bring the spoiled settings back to
normal.

Of course you're free to feel that way. I prefer to browse the web
w/o any scripting enabled until I find a presentation that's interesting
and the benefit of enabling scripting outweights the prossible problems.
Then, and only then, _I_ decide to let the browser load/execute the
javascript. And if FireBug or the ErrorConsole (depending on the
browser I'm using at that time) pops up to complain about the code
I switch the scripting off again. I emphasize that because it appears
that quite a lot of web-page builders forget that it's not them but
the readers who decide whether to use a graphical browser at all or
to dis-/enable scripting or IFRAMEs or sound or ...

That is the common mistake remained from the Internet bubble and
"everything for free just visit us" promo projects. Commercial site is
not an information you can take in any way you want. It is a _service_
provided to you for free of charge or for money - but still a service,
a goody. You holly right as a customer is either take the goody on
conditions spelled by the merchant or do not take it. You also have
right to be protected from the monopoly situation when you either have
to deal with this particular merchant or no goody at all. You have
right for the quality guarantee, money back, secure use etc. - but you
have no right to take a goody on your own conditions you just made up.
It is another remainder of the Web young age when the common social
behavior habits were regarded as non-applicable for some reason to the
Web. No one tears out bonus shampoo bottle from the big one and
requiring to let him go "because this comes for free". No one
requiring for "buy one - get one free" his free one only, so leaving
the one for money in the store. Yet in the Web it is considered by
some as a fully accepted social norm. Why? Just because it takes a few
of clicks instead of real life efforts?
You don't like the conditions the service is provided on, you don't
agree with some paragraphs? Just don't use it, find another merchant -
but don't paint the walls of his store into green with blue spots
"because it is needed for my most pleasurable shopping experience".

Just a few samples of well known Web 2.0 services that came first to
my mind and visited with Javascript disabled:
http://www.geocities.com/schools_ring/tmp/facebook.png
http://www.geocities.com/schools_ring/tmp/gmail.png
http://www.geocities.com/schools_ring/tmp/google_docs.png
http://www.geocities.com/schools_ring/tmp/youtube.png

Thank you so much! Indeed wonderful examples for how to build barriers
to keep potential users outside and annoyed.

? Did you check the current capitalization of say Facebook or their
capitalization growth ober the last say 12 months? I provided not just
some Web 2.0 projects: I mentioned the ones with millions of dollars
success. Yes, most probably they missed their two pennies from Mr.
Watermann and certain amount of other users. This was carefully
accounted before the roll up, believe me - and considered as too small
to care about.

VK <schools_ring (AT) yahoo (DOT) com> writes:

Just a few samples of well known Web 2.0 services that came first to

Please explain what "Web 2.0" means
It's marketing speech for "newer and better than the rest, but we
can't say how".

If Web 2.0 has any meaning, it's about user generated content.
Scripting is not necessary for that.

my mind and visited with Javascript disabled:
http://www.geocities.com/schools_ring/tmp/facebook.png
http://www.geocities.com/schools_ring/tmp/gmail.png
http://www.geocities.com/schools_ring/tmp/google_docs.png
http://www.geocities.com/schools_ring/tmp/youtube.png

Google Docs is an application more than it is a web-page.
It does need scripting to work, because it performs client-side
calculations. It would be incredibly awkward without scripting.

GMail uses scripting to immitate an application, but doesn't really
need it for anything but extra bells and whistles. It has a fallback
for script-disabled browsers, and works adequatly with Javascript
disabled (better than most other web-mails I have seen).

Youtube shouldn't need scripting at all for what it does (but it does
apparently use it to start the flash player). I wish it did use AJAX,
so I could page through comments without interrupting the movie.

I don't know what facebook does, but I guess most of its essential
features would work fine without scripting.

Of these, only YouTube and Facebook are what I would consider Web 2.0
applications (as much as it makes sense at all).

/L
--
Lasse Reichstein Nielsen - lrn (AT) hotpop (DOT) com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'