Contradiction of Advice?
Prisoner at War
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??
David Dorward
> They say not to use JavaScript for important things, but doesn't that
> mean relegating JavaScript usage to frivolous effects?
It would be better to say "Don't depend on JavaScript for essential things".
Create something that works without JavaScript (even if it is slow and
clumky), and then layer scripting on top to improve the usability (removing
the clunkyness for users who's client support the the JS).
--
David Dorward
http://dorward.me.uk/
http://blog.dorward.me.uk/
"Álvaro G. Vicario"
> 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
--
Matthias Watermann
> [...]
> 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 M$ ATTACHMENTS
/ \
Jim Moe
> 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.
>
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)
Dr J R Stockton
, Thu, 15 May 2008 07:44:24, David Dorward <dor...@yahoo.com> posted:
>Prisoner at War wrote:
>> They say not to use JavaScript for important things, but doesn't that
>> mean relegating JavaScript usage to frivolous effects?
>
>It would be better to say "Don't depend on JavaScript for essential things".
>
>Create something that works without JavaScript (even if it is slow and
>clumky), and then layer scripting on top to improve the usability (removing
>the clunkyness for users who's client support the the JS).
Rather simplistic; perhaps your experience is limited to the commercial
world. & YGCIB.
A business wishing to attract as much trade as possible by the use of
the Web ought to ensure that the Web experience that they offer to those
who do not run JavaScript is good enough for their purpose, and free of
visible deficiency caused to script not running. If it is felt that
customers may be impressed by "decorative" features, then JavaScript is
one way of adding such; and it might also be used to add real value to
the web site. And that is, of course, the most common case.
But a business that wants some more trade but is limited in what it can
handle may not need to ensure that all visitors to the site receive the
full marketing blast.
Outside (and inside) commerce, JavaScript can also be used to provide
sandboxed computational facilities, and for the public derivation and
demonstration of algorithms.
There is no justification for limiting what is done with JavaScript
merely because some people, some of the time, do not run it.
If a site is significantly better with JavaScript, those without it
should be politely informed that they could do better by enabling it or
by going to a system which does have it.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Prisoner at War
>
>
> It would be better to say "Don't depend on JavaScript for essential things".
Yes, which suggests that JavaScript is relegated for non-essential
things...which seems a high cost-benefit ratio...said "cost" being the
time it takes to learn JavaScript...I mean, learning "programming
lite" to do non-essential things??
> Create something that works without JavaScript (even if it is slow and
> clumky), and then layer scripting on top to improve the usability (removing
> the clunkyness for users who's client support the the JS).
Sorry, but to what "clunkiness" are you referring?? How does
JavaScript improve webpage clunkiness, whatever that is???
> --
> David Dorwardhttp://dorward.me.uk/http://blog.dorward.me.uk/
Prisoner at War
>
>
> 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....
David Dorward
For example.
A form allows the user to enter a number. The user enters a letter by
mistake, submits the form, the server side script catches the error, and
returns a page containing a prepopulated form to the user along with an
error message.
This takes some time.
Add JavaScript...
If the browser doesn't support the JS, then the above scenario still plays
out. If the browser does support it, the data is tested on the browser, and
the user is alerted to the problem without the round trip to the server.
Matthias Watermann
> On May 15, 5:36 am, Matthias Watermann <li...@mwat.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.
VK
> 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.
Matthias Watermann
> On May 18, 4:26 pm, Matthias Watermann <li...@mwat.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.
VK
> >> 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.
Lasse Reichstein Nielsen
> 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 - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Matthias Watermann
>> [...]
>> > 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.
Hmm, kind of paradox, isn't it? So why are you arguing if you don't
want to listen anyway? - And as far as the "traditional Web values" are
concerned: Yes, I've been building networks for longer than the web even
exists. To bring people in touch, to make information available, to
build way of communication. And although personally I am only a small
part of that movement in the eighties of the last century I'm still
proud of it. That's why I feel so sorry whenever I see how the net's
potentials are wasted for gimmicks.
>> > 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.
Hu? Who was talking about "free"? I've been writing about accessibility.
Whether it's "free" or not is a completely different question.
> 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.
Sure. But it's your "service" provider who is in charge to make his
"service" accessible or not. And it's the user who decides to accept
a "service" or not.
> 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.
But of course I have that right. If a plumber would place a sign in his
window saying "Our services provided only for customers with red hair
and green shoes" I could either colour my hair and buy the requested
shoes or - just walk along to another plumber who doesn't care about
my hair or shoes but just wants to make business. The same with the
web. It's always me who decides whether I enable images, javascript,
flash and alike or not.
> 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.
Again you're going astray. We're not talking about "free" here.
> [...]
> 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 -
Exactly! Just what I said.
> but don't paint the walls of his store into green with blue spots
> "because it is needed for my most pleasurable shopping experience".
Interesting idea, indeed.
>> > 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.
>
> ? Did you check the current capitalization of say Facebook or their
> capitalization growth ober the last say 12 months?
If I would take that as a serious argument I would have to buy a WinDOS
machine at once to allow for the zombie nets to grow. After all, that's
a big business, isn't it? Well, not for me, but someone at least. But ...
But why should _I_ care for someone else's money? Apart from that:
Those hype "services" could actually increase their customer base if
they would lessen their barriers.
> I provided not just
> some Web 2.0 projects: I mentioned the ones with millions of dollars
> success.
Well, what you call "success" is nothing more than some stock values.
It's not real money at all. And we've all seen what such "success" is
worth just ten years ago. But that's quite another story which has
nothing to do with the question we're discussing here.
> 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.
Well, that's fine with me. If you'd cared to read what I said in my
other postings you'd have seen that I wrote, that the ones building a
web-site should consider (i.e. think about) where to use scripting and
where it's just a barrier. So if someone _decides_ to keep out part of
the possible audience, that's clearly his/her choice. The problem I
mentioned is that obviously a lot of people just cut&paste some script
snippets into their pages because "it's cool" without even thinking and
gauging the benefits and problems.
Rich Grise
> If a site is significantly better with JavaScript, those without it
> should be politely informed that they could do better by enabling it or
> by going to a system which does have it.
Absolutely NOT!
One of the most annoying things anyone can see on a website is "You have
to upgrade your browser to see this site."
The vast majority will say, "Well, fuck'em if they don't want my business"
and surf somewhere else.
The smart thing to do is to design a page where "NOSCRIPT" gives a
functional presentation - your customers are looking for products and
services, not necessarily glitz.
Of course, if you have a customer who wants glitz, then bill them
appropriately. ;-)
Cheers!
Rich
Good Luck!
Rich
Rich Grise
...
> Only too often the behaviour
> is more like infantilizing than helpful.
You're talking about Vista, right? ;-)
Cheers!
Rich
Matthias Watermann
Well, I'm unable to confirm or deny that as I abandoned that family of
socalled operating systems about fifteen years ago. The real problem
with those software products is that meanwhile a lot of people grew up
under the impression that what they see and are forced to do with
WinDOS boxes is the true or natural thing to do. Just a tiny example:
Does anybody think about the TAB character nowadays? It's a character,
in fact, but over the years it became a navigational key instead (like
the arrow keys). - Hmm, that may be off-topic, but at least it's one
incarnation of the problem we were discussing in this thread: That
people should _think_ about what they're doing instead of just barking
with the pack.
Lasse Reichstein Nielsen
> Just a tiny example:
> Does anybody think about the TAB character nowadays? It's a character,
> in fact, but over the years it became a navigational key instead (like
> the arrow keys).
I really, really wish they would do away with the TAB "character"
completely. It never causes anything but problems anyway.
Langauges with significant whitespace, which I approve of on the
theoretical level, are darn near unusable in a generic editor
that might, or might not, use both tabs and spaces.
TAB isn't a character as such, it's a "control character", aka. a
control *code*, not really a character. A byte value sent to a line
printer that represented an action (like carrige return and line
feed).
We still have both carrige return and linefeed (although we only
really need one in practice: newline), and we still have tab,
which we don't need at all for text.
Dr J R Stockton
net>, Wed, 21 May 2008 18:43:13, Rich Grise <ri...@example.net> posted:
You are naive in assuming that users of a site are necessarily
customers. Perhaps you have never heard of sites like Wikipedia or
Wikicodia (the latter, happily, seems now dead); or those provided by
Universities and other public or quasi-public bodies.
Your are also assuming that customers necessarily can go elsewhere.
Customers of Microsoft, for example, whether willing or unwilling, are
obliged to go to the MS site for authoritative "manuals" for MS
products, however uncongenial the site is.
And you have not understood the words that you have quoted above. A
polite statement that, with their present system, they are not obtaining
all that the site can provide is quite different from the uncouth
wording that you suggest.
Therefore, your "contribution" is devoid of value.
--
(c) John Stockton, nr London UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Matthias Watermann
> [...]
> We still have both carrige return and linefeed (although we only
> really need one in practice: newline),
Whenever you're going to print something you'll need both: LF only
moves down (but not to the line start) and CR moves to the line start
(but not down).
> and we still have tab, which we don't need at all for text.
Hmm, of course I don't know about your texts, but I use TAB quite
often, in source code (of whatever language) as well as in text
documents (both plain ASCII or ISO-xxx and e.g. ODF). - But I think
we should drop the subject since we're off-topic by now.
Rich Grise
> Therefore, your "contribution" is devoid of value.
So, do you have a worthwhile replacement, or is bitching the best
that you can come up with?
And I still maintain that telling your customers "You have to change YOUR
equipment to see our site" is a really, really stupid thing to do, if your
intent is to attract customers.
Thanks,
Rich
Dr J R Stockton
et>, Thu, 22 May 2008 19:45:01, Rich Grise <ri...@example.net> posted:
>On Thu, 22 May 2008 11:46:47 +0100, Dr J R Stockton wrote:
>
>> Therefore, your "contribution" is devoid of value.
>
>So, do you have a worthwhile replacement, or is bitching the best
>that you can come up with?
It seems to be the appropriate response for the foolish article that you
wrote. If you don't like to have your articles criticised, the minimum
requirement is to write sensible ones.
>And I still maintain that telling your customers "You have to change YOUR
>equipment to see our site" is a really, really stupid thing to do, if your
>intent is to attract customers.
That is, of course, not what I wrote.
As it happens, I was just reading the source of a NASA News Release. It
contains "Your browser or your browser's settings are not supported. To
get the best experience possible, please download a compatible browser.
If you know your browser is up to date, you should check to ensure that
javascript is enabled."
The page is <http://www.nasa.gov/home/hqnews/2008/may/HQ_08133_Shuttle_t
arget_dates.html>; it's amusing to read its code to see just what it
contains. It has 'CONTENT="2008-05-22"' indicating that even a USG
Agency sometimes used a sensible numeric date format. It uses
navigator.appName, navigator.appVersion, navigator.userAgent.
It's a good idea to read the newsgroup c.l.j and its FAQ. See below.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE7 FF2 Op9 Sf3
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Chaddy2222
Matthias Watermann wrote:
I agree with this.
Another thing to think about is that sites like Facebook are perhaps
in a lot of ways breaking the law in many countries by not makeing
information accessible.
--
Regards Chad. http://freewebdesignonline.org
Joseph Brenner
Prisoner at War <prisone...@yahoo.com> writes:
> They say not to use JavaScript for important things, but doesn't that
> mean relegating JavaScript usage to frivolous effects?
If you look at google maps -- the main reason we're stuck with all this
AJAX stuff these days -- you'll see that it does whizzy things
with Javascript on (pre-caching map data so you can scroll around on it
by dragging), but if you shut it off it still hands you a map, it's just
a static one without the spiffy interactive scrolling.
So there you have it: the feature critical for google maps success is
implemented via Javascript, but it degrades to something useful without
it.