How many browsers JS enabled?

After expressing my interest in expanding my new knowledge of HTML and CSS
into the wild realm of JavaScript, I was advised that it is wiser to avoid
it, since not all browsers are use it or are enabled to read it. After
searching for other opinions on the web, I found that some estimate that the
frequency of browsers that can read JS currently is better than 90% -- that
is certainly workable for me!

Do you good people have any thoughts or references on the issue?

----------
confused . . .

"confused" <nowhere@hotmail.com> writes:
[color=blue]
> After expressing my interest in expanding my new knowledge of HTML and CSS
> into the wild realm of JavaScript, I was advised that it is wiser to avoid
> it, since not all browsers are use it or are enabled to read it.[/color]

That's (obviously) not a sentiment that is generally shared by this group.
It is wiser to use it wisely :)
[color=blue]
> After searching for other opinions on the web, I found that some
> estimate that the frequency of browsers that can read JS currently
> is better than 90% -- that is certainly workable for me![/color]

The statistics usually put the number of browsers without Javascript
(either lacking capability or permission) at, or just above, 10%.

These can be current browsers with Javascript disabled by the user, or
restricted browsers with no Javascript capability. I know of no
statistics that couples the lack of Javascript with browser type.
[color=blue]
> Do you good people have any thoughts or references on the issue?[/color]

10% is quite a lot of people. The conclusion must be that if the page
*can* work without Javascript, a good web designer will make sure that
it does work, thereby not artificially reducing the possible users by
10%. For a commercial web site, depending on Javascript can possibly
be directly translated into a 10% drop in earnings from the web site.
That would be ... unwise.

However, it is important to remember that the cure to the problem is
not to omit Javascript completely. It can still be used to make a
functioning page work better. Typical non-essential usages are
graphical effects (e.g., change graphics of buttons when the mouse
hoovers above them), validation of user input (to save a roundtrip to
the server in case of errors, not to replace server side validation),
and generally to make changes to the page that can otherwise be
achieved by fetcing a new page.

Bad desings include:
- using javascript: links. These only work with javascript enabled.
- use non-link elements with javascript instead of links.
- make navigational aids that only work with Javascript (e.g., drop down
menus with no default action)
- replace nativ form controls with javascript based implementations
(e.g., a "prettier" drop down boxes instead of select elements).
- ditto for scroll bars.

The answers in the FAQ (<URL:http://jibbering.com/faq/>) are based on
this approach: make Javascript using pages degrade gracefully on non-
Javascript enabled browsers.

What I have said is meant for internet pages. If you know what browser
and configuration your users are using, then you can make assumptions.
This generally only holds for corporate networks.

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

>After expressing my interest in expanding my new knowledge[color=blue]
>of HTML and CSS into the wild realm of JavaScript, I was
>advised that it is wiser to avoid it, since not all browsers are
>use it or are enabled to read it. After searching for other
>opinions on the web, I found that some estimate that the
>frequency of browsers that can read JS currently is better
>than 90% -- that is certainly workable for me!
>
>Do you good people have any thoughts or references on the
>issue?[/color]

Aside from /L's informative reply, here is another issue which you should
consider when deciding to incorporate Javascript into your web page. Many
"professional" web sites have plenty of eye catching DHTML and Javascript
tricks in their site. For those with disabilites, this is not necessarily a
good thing. While the number of users with significant disabilities which may
prevent them from using a site may be small, those few people can have major
consequences.

I'll refer to you a discussion in several newsgroups which took place in 1997.

http://groups.google.com
Search term :
Australian web designers group:comp.lang.javascript

It's a rather lengthy thread concerning Australia's Disability Discrimination
Act and how the internet is affected by it. While this Act is particular to
Australia, there have been cases in the United States where companies have been
sued by those with disabilities claiming their company's websites were not
accessible under the ADA. I'm not aware of any successful lawsuits, however
the time and money spent defending their case could have been better spent on
learning how to design accessible web pages; avoiding the whole problem in the
first place.

http://www.hreoc.gov.au/disability_r...w_3/www_3.html

This link points to the Act mentioned in the above thread.

Peace, Vm
Yaz

Providing complicated solutions to simple problems since 1997.

confused wrote:[color=blue]
> After expressing my interest in expanding my new knowledge of HTML
> and CSS into the wild realm of JavaScript, I was advised that it is
> wiser to avoid it, since not all browsers are use it or are enabled
> to read it.[/color]

Many people who encounter web pages where the inappropriate or
ill-considered use of javascript has had disastrous consequences for the
page (a blank page being the most obvious and extreme consequence)
conclude that javascript is all bad and recommend that it is never used
by anyone.

Obviously that is not an attitude that you will find promoted here.
However, presenting a web site user with a blank screen, or a web page
that is unusable for any other reason, is not an practice that is
considered acceptable here either (except maybe by a few, who are not
capable of doing any better).

The question we struggle with is: can javascript be designed,
implemented and deployed to enhance a web site wen it is available and
functional without detracting from the 100% reliable HTML over HTTP that
is the basis for any web site.
[color=blue]
> After searching for other opinions on the web, I found
> that some estimate that the frequency of browsers that can read JS
> currently is better than 90% --[/color]
<snip>

The availability of javascript is not the only issue. In addition you
have to consider the viability of the things that you intend to do with
javascript.

Opening new browser windows is an obvious example. Because of pop-up
advertising people run various flavours of pop-up blocker. These people
ate not using pop-up blockers with javascript disabled/incapable
browsers, there would be no point as those browsers could not open
pop-ups anyway. So to your supposed 10% failure of any script that
attempts to open a new window as a result of javascript being disabled
you also have to add a percentage resulting from the accumulated effect
of the various forms of pop-up blockers.

Then there is the question of how dynamic the browser is. Modern desktop
browsers are very dynamic, small embedded browsers and older browsers
are less so. So a script that wants to actively insert content into a
web page will fail on javascript enabled and capable browsers that are
not dynamic in addition to javascript incapable browsers.

Even something as trivial as using IE's ability to write to the
clipboard is not guaranteed to be available as IE's configurations allow
that to be independently disable. And ActiveX is even less reliable.

Javascript cannot be written with an attitude that javascript is either
available on the client or not. The availability of javascript does not
guarantee that any given script will execute successfully, that will
depend entirely on what it is going to be attempting to do, and how it
attempts to do it. So, even if you are gullible enough to believe that
accurate and representative statistics can be gathered about a global
HTTP network, any statistic for javascript availability only represents
one end of a very blurred boundary region between successful script
execution and script failure.
[color=blue]
> that is certainly workable for me![/color]

If you went to the business people behind a web site (assuming it is a
commercial project) and tell them that an arbitrary and unnecessary
design decision was going to cost them 10% of their turnover, would you
expect that decision to be endorsed?

The starting point for a web site is HTML over HTTP (often in
combination with server-side scripting), which is 100% reliable and will
"work" on every web browser for all users (or at least as near to that
as can be achieved). Everything that detracts form that underlying 100%
reliability is the direct result of a design decision made by a human
(it is not inherent in the system).

How and why humans introduce unreliabilities varies a great deal; it
could be ignorance, or an unwillingness to recognise the significance of
a cause of action, or it could be an informed decision resulting from an
analysis of conditions and an assessment that the introduced
unreliability is an acceptable trade-off for some other advantage. (Of
course you cannot make an informed assessment of the relative merits of
introducing unreliability into an otherwise reliable system until you
understand how to avoid doing so, and what that would involve.)

Javascript design is probably the point where the most can be detracted
from the underlying reliability of the system. That makes the design of
javascript probably more important than its specific implementation
(though that is not an excuse for bad coding). So can browser scripts be
designed so that they add to a web page when they work, but do not
detract from it when they fail?

When designing javascript is important to realise that it will always
fail somewhere. On whatever percentage of browsers do not support
javascript at all for sure, and then additionally on all of those
browsers that do not support the required features (or are operated in
an environment that impacts of their use (such as, along side pop-up
blockers)). How a script fails (preferably under its own control)
becomes as important as what it will do when it works, and for this the
criteria is "clean degradation". Clean degradation means that the user
is not shown error reports, the user is not badgered (about their
browsers and its capabilities) and after the degradation the resulting
web page is completely useable in terms of what it presents to that
user.

The easiest way to achieve clean degradation is to start with 100%
reliable HTML and use javascript to go up from there. That allows the
degraded state to be that underlying HTML. The script is then designed
so that it enhances that underlying HTML through its manipulation (and
possibly adding dynamically generated controls and the like), but
cautiously, feature detecting the browser's support for what it is
required of it and withdrawing gracefully whenever the browser does not
appear to be supportive. And so, cleanly degrading back to the original
underlying HTML.

That is all fine and good as a design principle, but can it be realised?
Can a javascript manipulated UI still make sense without javascript?

There are things that cannot be implemented to cleanly degrade, but not
that many (and they may be the aspects of javascript best avoided). The
vast majority of the things that are commonly implemented in a way that
introduces a javascript dependency are completely amenable to being
implemented without that dependency.

With the modern desktop browsers capable of considerable manipulation of
HTML anything paced within that HTML can be transformed by scripts to be
(and do) just about anything imaginable, while the fact that the most
dynamic (and common) browsers can be manipulating existing content means
that there is always a path of clean degradation available to any (and
all) less capable browsers.

I have recently been playing with a script that illustrates an extreme
of the manipulation of underlying HTML with javascript. It started life
as a response to a question asked on this group, but I have considerably
elaborated it in the mean while:-

<URL: http://www.litotes.demon.co.uk/js_info/pop_ups.html >

- Visit it with a javascript capable/enabled modern desktop browser to
see how it manipulates its contents. And then use the first link on the
page to re-load with the script disabled (or disable javascript and
re-load the page, or re-visit with a less capable browser) to see it in
its degraded state. It isn't yet perfect but it does demonstrate that
much can be done with javascript without introducing any dependence upon
javascript, and once that is achieved it stops being important that some
browsers may not support javascript.

Richard.

Richard Cornford wrote:[color=blue]
> The starting point for a web site is HTML over HTTP (often in
> combination with server-side scripting), which is 100% reliable and
> will "work" on every web browser for all users (or at least as near
> to that as can be achieved).[/color]

Of course, this isn't necessarily true either. There are different versions
of HTML, and different support among different browsers for various HTML
features.

It's conceivable that people are using browsers that don't support CSS, or
even as far back as not supporting tables! Do you redesign your pages to
take these people into consideration, avoiding all table and css features?
Surely not.

So no matter how you approach it, it's always a risk/reward proposition.
For some people, relying on css for the page to look even halfway decent is
worth the risk of making some people leave the page because it's ugly.
For most people, using tables is an obvious yes, because the number of
people using ancient browsers is tiny.
For many people, adding javascript features is worth the risk of some people
not viewing the full features of the site.
For some people, relying on javascript for basic javascript functionality is
worth the risk of losing a percentage of users because the reward of a more
interactive site is worth it to them.

While the general concensus of this group's regulars about supporting non-js
browsers is good, it is all too often portrayed in a black-and-white manner,
when I think it's a lot more gray.

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/

Matt Kruse wrote:
[color=blue][color=green]
>>The starting point for a web site is HTML over HTTP (often in
>>combination with server-side scripting), which is 100% reliable and
>>will "work" on every web browser for all users (or at least as near
>>to that as can be achieved).[/color][/color]
[color=blue]
> Of course, this isn't necessarily true either. There are different versions
> of HTML, and different support among different browsers for various HTML
> features.[/color]

I believe that such user agents are far more rare than user agents not
supporting javascript or a particular DOM, but I'm not an archeologist:-)

We still have to make assumptions at the beginning, and I think it's
fairly reasonable to assume that well-formed HTML should be usable and
present accessible contents for all browsers - exceptions do exist of
course, like in NN4, and can be taken care of when known - in the end
there might always be one browser that will not be able to interpret the
sent content.

However, the point is not about HTML being supported, it is on how to
use javascript so that it doesn't remove any functionality in certain
situations, it's on how to design a web site so that it maximizes the
number of targets while still using javascript or any other technologies
bringing a certain comfort to the user.
[color=blue]
> For some people, relying on javascript for basic javascript functionality is
> worth the risk of losing a percentage of users because the reward of a more
> interactive site is worth it to them.[/color]

If we're talking about basic functionalities, then this is simply not
acceptable. It is indeed *easy* to build a usable HTML interface, and
add a bit of javascript so that the functionality is enhanced, without
loosing functionality - your tree menu is an excellent example of this!

The matter may be a bit different with advanced functionalities, but
that would concern special cases only, and there are always acceptable
solutions using a server-side fallback.
[color=blue]
> While the general concensus of this group's regulars about supporting non-js
> browsers is good, it is all too often portrayed in a black-and-white manner,
> when I think it's a lot more gray.[/color]

Now this is too easy, isn't that indeed a black/white saying? ;-)

I've read your posts and discussions with Richard, and it seems to me
that you generally agree with this consensus, while presenting pragmatic
reasons toning down this consensus (the "gray" part;-)). The main reason
you usually invoke is the programmer's competency, IIRC; that the
programmer wouldn't have the time to become an expert and has to make a
choice to have the project work.

While I'm very sensitive to these kinds of arguments, I cannot accept
that a *professional* programmer doesn't know techniques, design
patterns and models about the language/environment he's working in (of
course an amateur does not have these constraints, but doesn't have the
same expectations about quality as well).

<RANT>
Web design is a programming field, like Java, C++, Perl, LISP etc. are,
but tends to be considered an easy area to step in - programmers become
therefore *sloppy*, things that you would *never* accept in other
programming fields are carelessly done in javascript.

Client-side scripting has its own peculiarities and approaches, and is a
very difficult area - if you're a professional then simply learn them,
as you'd do in other fields - we all have to start from somewhere, and
that's no shame not to be an expert at once in such a complex area.
</RANT>

Scripting is like playing music; you can do it for fun or be paid to do
it; it requires time and effort to play it well; and there's no shortcut
but clear rules on how to play it well.

Regards,
Yep.

Matt Kruse wrote:[color=blue]
>Richard Cornford wrote:[color=green]
>> The starting point for a web site is HTML over HTTP (often in
>> combination with server-side scripting), which is 100%
>> reliable and will "work" on every web browser for all users (or
>> at least as near to that as can be achieved).[/color]
>
> Of course, this isn't necessarily true either. There are different
> versions of HTML, and different support among different browsers
> for various HTML features.[/color]

HTML has always had a very clear attitude about how to handle elements
that are not understood; it ignores their tags. So an ancient browser
with a limited HTML vocabulary is not denying its users access to the
content of web pages, just some of their structuring.
[color=blue]
> It's conceivable that people are using browsers that don't support
> CSS,[/color]

Conceivable? I would have said that was a certainty.
[color=blue]
> or even as far back as not supporting tables! Do you redesign
> your pages to take these people into consideration, avoiding all
> table and css features? Surely not.[/color]

Redesign? I strive to handle design issues at the design stage,
redesigning is a waste of resources (at least when it is not associated
with a more general redesign, facelift, etc, that is demanded for other
reasons). I do construct HTML with a consideration of its unstyled
"presentation". That isn’t at all a difficult task as page content is
usually grouped together in a block, navigation in another (sometimes
two) and any other stuff (advertising, etc) in a small number of other
lumps. Without CSS those lumps will appear in some sort of sequence so
the only questions are whether the navigation should precede or follow
the content and whether the other stuff should go at the beginning or at
the end (or be distributed in some other way).
[color=blue]
> So no matter how you approach it, it's always a risk/reward[/color]
proposition.[color=blue]
> For some people, relying on css for the page to look even halfway
> decent is worth the risk of making some people leave the page because
> it's ugly.[/color]

I assume what you mean here is that one person’s idea of an appealing
visual presentation may not be another’s. That is certainly true, though
corporate visual presentation is rarely so extreme as it would induce an
impression of ugliness on a viewer even if they didn’t actually like it.

Personally I don’t perceive ugliness as a reason for leaving a site.
There is a coincidence that sites that I look at and see as actually
ugly are also sites that I don’t hang around on, but that tends to be
the result of the way that ugliness impacts on their usability. I
recently visited a site where someone had decided that pail pink text on
a scarlet background would be a memorable way of presenting information.
The result was undoubtedly ugly but it was the fact that it was also
unreadable that had me looking elsewhere.
[color=blue]
> For most people, using tables is an obvious yes, because
> the number of people using ancient browsers is tiny.
> For many people, adding javascript features is worth the risk of
> some people not viewing the full features of the site.[/color]

Where is the risk in that? The users of javascript disable browsers
aren't expecting interactivity so as long as a page doesn't claim
capabilities that it cannot deliver they don't even have to be aware
that it would have been any different with javascript enabled.
[color=blue]
> For some people, relying on javascript for basic javascript
> functionality is worth the risk of losing a percentage of users
> because the reward of a more interactive site is worth it to them.[/color]

You say that as if the two were mutually exclusive; that even the
possibility of interactivity necessitated javascript dependence. The
point of my outlining javascript design patterns in my preceding post
was to get across to a newcomer that you can have all the interactivity
you want on a web page, but if you do so by building on top of, and
manipulating, an underlying function HTML you get that interactivity as
an extra enhancement, without any dependency on javascript/browser
support in order to fully use a web page.

So, given a modern dynamic browser (which is pretty much what every
javascript dependent web site requires from the outset) you can
manipulate anything at all to your harts content. You can have all the
interactivity you can think of, and so if interactivity brings reward
you get those rewards.

But where has the risk gone? The users of the javascript disabled
browser and less/non dynamic browsers had no expectation of
interactivity (they don’t get it on any other sites after all), what
they do get is the underlying functional HTML (all they expect and all
they actually need).

All the rewards for (and from) the users of the dynamic javascript
capable browsers, plus no risk of loosing the users of any other
browsers as a result of a needless javascript dependency (and, in a
commercial context, additional rewards resulting from their use of the
site).
[color=blue]
> While the general concensus of this group's regulars about
> supporting non-js browsers is good, it is all too often portrayed
> in a black-and-white manner, when I think it's a lot more gray.[/color]

If someone starts off learning how to design javascript in a way that
adds functionality without introducing any javascript dependency then
when they are presented with a context in which such a dependency does
not matter so much (such as an Intranet) then they are in a position to
make an informed decision about what would be a suitable design strategy
for that context. They will have learnt the discipline so they will know
how and where to relax it.

An author who has not learnt how to handle the design issues (or
disregards them) will not be in a position to suddenly cope with them in
the event that they find themselves in a position where they need to
work to that higher standard.

You get a similar effect in cross-browser scripting. The author of
cross-browser scripts can also author exclusively for IE if the context
makes it appropriate, while the author who can only cope with IE
probably has a lot to unlearn before they can even start to tackle
cross-browser scripts.

But the authors who write exclusively for IE will throw statistics
about, arguing that IE is the only browser worth considering so not
learning how to cope with any others doesn’t matter. And they will
maintain that attitude in the face of any number of demonstrations that
cross-browser scripts can deliver identical functionality on numerous
other browsers in most cases.

It may seem black and white, but I will always advise newcomers that if
they want to learn javascript they should aspire to master cross-browser
scripting and script design suitable for the Internet as a whole (where
javascript is an optional technology). If they can achieve that they
will be in a position to cope with everything they will be asked to do
in any real situation, and they will also be in a position to be
confident that they are not making anything worse through their actions.

Richard.

Richard Cornford wrote:[color=blue]
> HTML has always had a very clear attitude about how to handle elements
> that are not understood; it ignores their tags. So an ancient browser
> with a limited HTML vocabulary is not denying its users access to the
> content of web pages, just some of their structuring.[/color]

Depends on which HTML features are used. If content is put in iframes, for
example, older browsers will not see the content.
[color=blue][color=green]
>> For some people, relying on css for the page to look
>> even halfway decent is worth the risk of making some people leave
>> the page because it's ugly.[/color]
> I assume what you mean here is that one person's idea of an appealing
> visual presentation may not be another's.[/color]

No, I mean some pages use CSS exclusively for all presentation, as it would
be in an ideal world. So to browsers without CSS support, the page looks
horrible, with no formatting, etc.
[color=blue]
> Personally I don't perceive ugliness as a reason for leaving a site.[/color]

I do! I've seen plenty OBNOXIOUS pages... background music, flashing images,
flash animations, etc. I typically browse with almost everything disabled
(flash, active x, music, transitions, etc) but when I don't, I have
encountered pages that made me leave very quickly :)
[color=blue]
> If someone starts off learning how to design javascript in a way that
> adds functionality without introducing any javascript dependency...[/color]

This is still a gray world. What does "adds functionality" mean, anyway?

Is it fair to have a table of html data that is only sortable, filterable,
etc via javascript, and view that as "extra functionality"?
Is it fair to have a plain table of contents of links as navigation for
non-js browsers, but a full easy-to-use dhtml menu system for js browsers?

Defining what is "core functionality" and what is "extra functionality"
isn't so easy.

For example, if an author was to direct non-js users to a plain-text dump of
a page, while offering js users the ability to view, manipulate, change,
annotate, filter, and sort the data - would that be "extra functionality"?
What if the content itself is "extra functionality"? Where is the line
between "core" functionality and "extra" functionality? There isn't always a
clear answer.

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/

Thank you all for your thoughtful and timely responses to my queries; I am
considering the replies and visiting the links. If I may, I will
recapitulate what I have learned up to now, and, though it is off-topic for
this thread, I would like to discuss my needs specifically and take further
advantage of your considerate attentions.

If the approximately one in ten of users whose browser would not handle JS
need to be reached, then the use of JS should only be used to augment a
site, without making it JS dependent. This would exclude higher JS
functions -- but this, too, could have a negative impact on market share,
depending on the functions considered. Designers for commercial sites
wanting to use advanced JS must consider the trade-off between the loss of
that 10% of user market-share, compared to the gain in both initial and
return business that could be expedited by those higher JS functions. For
those writing a site that is not concerned with a 'bottom line', similar
considerations would attend their efforts to 'get the message out' --
whatever it might be. However, when those advanced JS functions are not
necessary, then JS dependency could be avoided by employing, in addition to
the simple JS code, non-JS code as a backup to achieve the same or similar
effects,

My own requirements are simple, and so far there are only two possible JS
functions that I am interested in, if they exist. There are relatively easy
redundant non-JS means by which I could, roughly, achieve the same results;
but, those redundancies seem cumbersome compared to JS script that might
work . I am not yet a JS programmer, however, and I would greatly
appreciate your opinions.

1) First, my site is for displaying 2D graphic images, and it is vital
that their presentation take full advantage of the size of a users monitor,
regardless of its screen resolution settings. CSS code <img style="width:
percentage" src="graphic.file"> enable those images to expand, or contract,
to fit and fill screens, whatever their settings, without spillover and the
need to scroll. However, that doesn't apply to text and their designated
font-size, that I use for an image's title-bar, and in the home page that
lists the links to the various images. Though my pages are fully CSS
(table-free) and liquid (horizontally-compressible), so that all the text is
plainly visible, the variable 'look' to text between differing screen
resolutions, as that font expands or contracts, seems to me to be
unnecessarily crude. If JS code can sniff a users screen resolution, then
the value returned could be used to direct the users browser to pages
constructed specifically for that particular resolution. Or -- more
elegantly -- the returned value could direct a particular setting for the
body {font-size: px}in its controlling style-sheet -- since that "px"
setting is the base value from which all subsequent size "em" values are
calculated, and changing that one "px" value appropriately would alter all
subsequent font-sizes (and other "em" settings like
padding,margin-top,bottom and height values), one could forgoe the need to
actually write different style-sheets for differing screen resolutions.
Does this sound like a strategy to pursue?

One example google returned of a JS screen-resolution sniffer is at
http://www.personal.psu.edu/faculty/...eensniffer.htm. Is it
this simple? (I don't yet know what I'm looking at.)

Of course, as a backup, if a users browser can't handle JS, I would direct
the user to the pages I constructed for an average or common screen
resolution, which, for me is 1024 x768.

2) Second, my home page has no images, gifs, or thumbnails. It
contains only simple text which announces its purpose and provides 'numbers'
that link to the html files that present images. If things go well, I would
be making frequent, even daily, additions of images to the site, and,
therefore, the home-page list of 'numbers' could quickly be out of date for
browsers that have cached the URL. Caching the image/html files would, of
course, be convenient for users -- but caching the home-page would cause
users to miss new work. The obvious solution is to provide a note on the
home-page warning users to refresh/reload the page to stay current -- but,
since the home-page has very little to it and is designed to load quickly,
would it be bad form to try and prevent caching automatically? The meta
http-equiv "no-cache" tags I found which purport to address this feature
(see source code for http://www.w3schools.com/default.asp) do not work,
according to advice I received and to my own testing with IE6 and NN7. Is
there JS code that will prevent caching? The one relevant google return to
"javascript no-cache" is http://www.htmlgoodies.com/beyond/nocache.html ,
but the JS provided is just for NN. There are suggestions on getting the
meta no-cache tags to work, but I haven't yet tested them (sorry). Advice
anyone?

Also, I was elsewhere directed to this link --
http://httpd.apache.org/docs/mod/mod_expires.html -- to learn of another
means to possibly accomplish the same thing. Is Apache HTTP coding
something worth pursuing, if all I want is just this one special no-cache
feature?

Thanks to anyone who had waded through this lengthy posting.

------------------
confused

Matt Kruse wrote:[color=blue]
> Richard Cornford wrote:[/color]
<snip>[color=blue][color=green][color=darkred]
>>> For some people, relying on css for the page to look
>>> even halfway decent is worth the risk of making some people
>>> leave the page because it's ugly.[/color]
>> I assume what you mean here is that one person's idea of an
>> appealing visual presentation may not be another's.[/color]
>
> No, I mean some pages use CSS exclusively for all presentation,
> as it would be in an ideal world. So to browsers without CSS
> support, the page looks horrible, with no formatting, etc.[/color]

Browsers that do not understand CSS still have an attitude about the
meaning of mark-up. They still recognise what P, H1, UL, etc, tags mean
and provide some formatting based on those meanings. So the presentation
for the users of those browsers is not really any more ugly than typed
text on paper. It might not be pretty, but the absence of styling couldn
’t really be said to render text ugly.

(Of course, if the site author has failed to use the semantic aspects of
HTML to mark up the page then the unstyled result may end up being a
glob of text with no clear separation between paragraphs, headings, etc.
But that would be poor HTML authoring.)

But why would this be a problem? The users of these browsers do not see
any other sites styled either so the extent to which any one is rendered
ugly by the absence of style applies to all sites equally. So if the
absence of style induces a user of such a browser to leave one site it
would equally induce them to leave them all.

The users of such browsers probably wouldn’t care about visual
presentation anyway (else they would probably be using a different
browser). The balance of probability is that if they can find what they
are after, read the content and undertake any transactions they feel a
desire to, they will go away happy and never even think about what the
site might have looked like on a different browser.
[color=blue][color=green]
>> Personally I don't perceive ugliness as a reason for leaving a site.[/color]
>
> I do! I've seen plenty OBNOXIOUS pages... background music,
> flashing images, flash animations, etc. I typically browse with
> almost everything disabled (flash, active x, music, transitions,
> etc) but when I don't, I have encountered pages that made me
> leave very quickly :)[/color]

Much as I loath background sounds on web sites (I am yet to encounter
any rational that would justify them), I cannot see that being a
contributor to ugliness (which strikes me as a visual criteria).
Flashing images and text certainly qualify but again that is as much
their impact on usability as anything else, and I often turn away at a
Flash splash screens, but usually before it has downloaded enough to
show anything so visual impact is not a criteria in that case either.
[color=blue][color=green]
>> If someone starts off learning how to design javascript in a
>> way that adds functionality without introducing any
>> javascript dependency...[/color]
>
> This is still a gray world. What does "adds functionality" mean,
> anyway?
>
> Is it fair to have a table of html data that is only sortable,
> filterable, etc via javascript, and view that as "extra
> functionality"?[/color]

Without a server-side fall back, that seems like a very good example.
The primary purpose of a table of data is to be read. The ability to
sort its presentation is a potentially valuable extra, but when it is
not supported on the client there is no reason for the table to become
any less readable.
[color=blue]
> Is it fair to have a plain table of contents of links as
> navigation for non-js browsers, but a full easy-to-use dhtml
> menu system for js browsers?[/color]

You are thinking of these two as distinct. Apart form wondering why it
would be a table where list mark-up is probably better suited, this is
exactly the situation where the manipulation of HTML allows the same
content to perform both roles.

It is like the expanding tree scripts, though more elaborate. Take the
table/lists of links and transform/manipulate it into the DHTML menu.
The supporting browsers get the menu, but the unsporting ones still have
the links (and so the result is still viable navigation).
[color=blue]
> Defining what is "core functionality" and what is "extra
> functionality" isn't so easy.[/color]

In the preceding example "core functionality" is the user's ability to
navigate a web site (absolutely vital for a usable site), "extra
functionality" is the presentation of that navigation as an "easy-to-use
dhtml menu system".

The "core functionality" would be whatever is essential in order that
the user can access, read and navigate a site and perform any
transactions associated with the site, in a commercial context. The
"extra functionality" would be anything that makes that process easier,
quicker, more convenient (cuts down on needless server round trips) or
contributes towards the visual (or structural) presentation of the site
and its contents.
[color=blue]
> For example, if an author was to direct non-js users to a
> plain-text dump of a page, while offering js users the
> ability to view, manipulate, change, annotate, filter, and
> sort the data - would that be "extra functionality"?[/color]

That initially sounds like the "two sites" concept of handling
"inadequate" browsers (with its considerably expanded maintenance burden
(with associated additional expense) and the inevitable divergence of
the two as the inferior site gets a much lower priority for updates and
maintenance).

If an HTML page contains suitable data then javascript is entirely
capable of facilitating its manipulation on the client in any suitably
dynamic browser, and can do so without detracting from availability and
readability of the underlying data in the event that the browser was not
sufficiently dynamic to facilitate the desired content manipulation. The
client-side data manipulation would then easily qualify as "extra
functionality".
[color=blue]
> What if the content itself is "extra functionality"?[/color]

An example?
[color=blue]
> Where is the line between "core"
> functionality and "extra" functionality?[/color]

What is it that cannot be done without in order to have a functional web
site (in the context of the purpose of the site)? By which I don’t mean
the notion that bells and whistles attract customers, I mean only the
things that are needed for the web site to actually work. That would be
the core, you cannot do without it.

Everything else is extra, but there is no need to be restrictive about
what those extras are/do, or how deeply they are layered on top of the
core.
[color=blue]
> There isn't always a clear answer.[/color]

A design principle is not an absolute rule (or physical law), but
needless javascript dependencies will more successfully be avoided by
initially designing scripts with the intention of avoiding dependencies
than by designing scripts with a disregard for the issue. You don't
learn what can be achieved without ever trying.

Richard.

confused replies wrote:[color=blue]
> Thank you all for your thoughtful and timely responses to my queries;[/color]
I am[color=blue]
> considering the replies and visiting the links. If I may, I will
> recapitulate what I have learned up to now, and, though it is[/color]
off-topic for[color=blue]
> this thread, I would like to discuss my needs specifically and take[/color]
further[color=blue]
> advantage of your considerate attentions.
>
> If the approximately one in ten of users whose browser would
> not handle JS need to be reached, then the use of JS should
> only be used to augment a site, without making it JS dependent.[/color]

That is thinking about the situation the wrong way around. It shouldn't
be about reaching those users, in the sense of an active (or extra)
effort, more it should be a question of coming up with a reason for
excluding them (as there is very little need to do that given a suitable
initial design).
[color=blue]
> This would exclude higher JS functions --[/color]

Accommodating the users of javascript disabled/incapable browsers does
not have to impose any restrictions on what can be available to the
users of javascript capable dynamic browsers.
[color=blue]
> but this, too, could have a negative impact on market share,
> depending on the functions considered. Designers for
> commercial sites wanting to use advanced JS must consider the
> trade-off between the loss of that 10% of user market-share,
> compared to the gain in both initial and return business
> that could be expedited by those higher JS functions.[/color]

There is nothing mutually exclusive about employing javascript on web
sites and accommodating the users of javascript disabled/incapable
browsers. So if the first offers real gains (and I often wonder to what
extent that is true (where are the studies backing that assertion up?))
then all the gains can be achieved without any loss of usability for
less capable customers (so no need for a trade off at all).
[color=blue]
> For those writing a site that is not concerned with
> a 'bottom line', similar considerations would attend their
> efforts to 'get the message out' -- whatever it might be.
> However, when those advanced JS functions are not
> necessary, then JS dependency could be avoided by employing,
> in addition to the simple JS code, non-JS code as a backup
> to achieve the same or similar effects,[/color]

Again, specifically, what are these "advanced features" that cannot be
implemented in a modern dynamic browser without introducing a javascript
dependency? If you know nothing about javascript you are not exactly in
a position to judge what can be done without introducing any unnecessary
dependencies and what cannot. There may be a few things that cannot be
done without introducing a dependency but they are the exception (and
maybe best avoided as they are obviously optional), a little thought and
appropriate design and any web site can have its javascript cake and eat
it.
[color=blue]
> My own requirements are simple, and so far there are only two
> possible JS functions that I am interested in, if they exist.
> There are relatively easy redundant non-JS means by which I could,
> roughly, achieve the same results; but, those redundancies seem
> cumbersome compared to JS script that might work . I am not yet
> a JS programmer, however, and I would greatly appreciate your
> opinions.
>
> 1) First, my site is for displaying 2D graphic images,
> and it is vital that their presentation take full advantage
> of the size of a users monitor, regardless of its screen
> resolution settings.[/color]

This is extremely unlikely to be true. There may be a perception that
taking full advantage of the user’s screen resolution is vital, but it
is not. Desirable maybe but it is in no sense vital. (Making a realistic
assessment of the relative significance of criteria is extremely
valuable at the design stage in any project.)

In reality screen resolution (or, more precisely, desktop area pixel
dimensions, as that is the information that is actually available)
rarely has any bearing on a user’s browsing situation. It may be the
case that the users of small monitors will habitually use their browser
maximised (or in full screen mode) but the users of larger monitors and
multi monitor displays will rarely do so. Anyone with a monitor bigger
than 19 inches is actually unlikely to ever browse with the browser
window at full screen. I, for example, never expand my browser window
bigger than about 2/3 of my screen size. That leaves it about the same
size as a full screen window on a 17 inch monitor (maybe a bit under)
but that is absolutely adequate for web browsing.

This means that noticing my desktop dimensions and serving me with an
image perceived as suited to those dimensions is the worst decision that
can be made as it will actively prevent me from seeing the entire image
in my browser window without re-sizing the browser (which is something
that only rarely happens.

Multi-monitor set-ups can be even harder to cope with as the desktop
dimensions reported vary with the browser and OS. Sometimes you get
dimensions that represent the smallest box that can enclose all of the
monitor displays, which means that if the monitors are not all the same
size there will be areas of that rectangle that are not displayable on
any monitor. Alternatively the reported dimensions may be those of the
"primary" display, not necessarily the biggest and not necessarily the
one in which the browser window appears.

In the end, the dimensions of the browser window's viewable area tells
you more about the user’s situation than the desktop pixel dimensions.
[color=blue]
> CSS code <img style="width: percentage" src="graphic.file">
> enable those images to expand, or contract, to fit and fill
> screens, whatever their settings, without spillover and the
> need to scroll.[/color]

Web browsers are really bad at scaling images (they use extremely
primitive algorithms for the task), but if you want to do that you can.
You will actually be scaling relative to the window and not the
screen/desktop. (and the percentage dimensions may as well appear in the
CSS rather than the IMG tags).
[color=blue]
> However, that doesn't apply to text and their designated
> font-size, that I use for an image's title-bar, and in the
> home page that lists the links to the various images. ...[/color]
<snip>[color=blue]
> ... . If JS code can sniff a users screen resolution, then
> the value returned could be used to direct the users browser
> to pages constructed specifically for that particular resolution.[/color]

Avoid making multiple versions of the same static web page, it adds
considerably to the maintenance costs of any sight (even if that cost is
only your own time). A single server side script outputting variations
on a single page based on external criteria would be easier to handle
(but I am not sure whether this scaling idea is a good one anyway).
[color=blue]
> Or -- more elegantly -- the returned value could direct a
> particular setting for the body {font-size: px}in its controlling
> style-sheet -- since that "px" setting is the base value from
> which all subsequent size "em" values are calculated, and changing
> that one "px" value appropriately would alter all subsequent[/color]
font-sizes[color=blue]
> (and other "em" settings like padding,margin-top,bottom and height
> values), one could forgoe the need to actually write different
> style-sheets for differing screen resolutions. Does this sound
> like a strategy to pursue?[/color]

Apart form the fact that the desktop pixel dimensions have no bearing on
the user’s window dimensions, setting/modifying the relative or absolute
font size of the BODY element on a page that otherwise uses exclusively
inherited font-size relative units in its CSS will allow the entire
contents of the page to be scaled.

But scaling a page to "suite" the screen (or even the window dimensions)
is probably not a good idea. Part of the reason for allowing users to
adjust/set/override font size is to give them the opportunity to
compensate for personal conditions, be they poor eyesight or unusual
monitor configurations. Your desire to take control away from the user
and determine font size on your own criteria (even flexibly) may well
detract from a real need for that facility on the part of the user.
[color=blue]
> One example google returned of a JS screen-resolution sniffer is at
> http://www.personal.psu.edu/faculty/...eensniffer.htm.
> Is it this simple? (I don't yet know what I'm looking at.)[/color]

That script reads - screen.width - , which is the wrong dimension to be
reading even for the screen. Instead - screen.availWidth - takes into
account things like taskbars (which are not necessarily at the bottom of
the screen), at leas on some browsers.

But whoever wrote that scrip was no programmer (had no grasp of logic)
and I wouldn’t recommend using it (or, by implication, anything else
from any site that presents it with the proposition that it be used, as
they are obviously not qualified to recognise when a script is
nonsense).
[color=blue]
> Of course, as a backup, if a users browser can't handle JS,
> I would direct the user to the pages I constructed for an
> average or common screen resolution, which, for me is 1024 x768.[/color]

You have completely missed the point. Don’t make special pages for
special conditions. Take your default 1024X768 page and use javascript
to turn it into whatever alternative page you perceive as suitable when
it gets to the client. If the whole thing is already fluid and all you
want to do is set the font-size on the body element then just do that.
It will work on every javascript capable dynamic web browser, and the
rest will already be looking at the default page.
[color=blue]
> 2) Second, my home page has no images, gifs, or thumbnails. ...[/color]
<snip>[color=blue]
> ... The meta http-equiv "no-cache"
> tags I found which purport to address this feature
> (see source code for http://www.w3schools.com/default.asp) do not[/color]
work,
<snip>
.... ). Advice anyone?[color=blue]
>
> Also, I was elsewhere directed to this link --
> http://httpd.apache.org/docs/mod/mod_expires.html -- ...[/color]
<snip>

Forget about javascript for this, it has no control over caching (and
the best that can be done with javascript is a bogus hack using the -
location - object). META tags are not going to be of much help either.

What you need to understand in this context is HTTP and the headers that
it uses to _influence_ caching:-

<URL: http://www.mnot.net/cache_docs/ >

(that page is mostly about encouraging caching, but any mechanism for
encouraging caching will also facilitate discouraging it if applied to
that problem instead.)

Ultimately it will be the HTTP server (Apache) that will facilitate your
cache control, though the expires module alone is not the full solution.

Richard.

Yann-Erwan Perio wrote:
[color=blue]
> Matt Kruse wrote:[color=green][color=darkred]
>>>The starting point for a web site is HTML over HTTP (often in
>>>combination with server-side scripting), which is 100% reliable and
>>>will "work" on every web browser for all users (or at least as near
>>>to that as can be achieved).[/color]
>>
>> Of course, this isn't necessarily true either. There are different versions
>> of HTML, and different support among different browsers for various HTML
>> features.[/color]
>
> I believe that such user agents are far more rare than user agents not
> supporting javascript or a particular DOM, [...][/color]

On the contrary. The claims-to-be most used browser today lacks
(proper) support for many (features of) web standards, including
(of) HTML. And there is still no browser (at least I know none,
and I know more than 10 for different OSes and platforms) that
fully supports HTML-SHORTTAG, which lead to defective developments
like the "HTML Compatibility Guidelines" (Appendix C of the XHTML
1.0 Specification).

PointedEars

-- the returned value could direct a particular setting for the
body {font-size: px}in its controlling style-sheet -- since that "px"
setting is the base value from which all subsequent size "em" values are
calculated, and changing that one "px" value appropriately would alter all
subsequent font-sizes (and other "em" settings like
padding,margin-top,bottom and height values), one could forgoe the need to
actually write different style-sheets for differing screen resolutions.
Does this sound like a strategy to pursue?
[color=blue][color=green][color=darkred]
>>>>following testing, this won't work, since other other 'sizing'[/color][/color][/color]
declarations using 'em' for a particular selector ( like
padding,margin-top,bottom and height values) will be based on the font-size
for that particular selector, not on the commanding font-size of the body
declaration.

The solution would seem to be to have JS that would return a value about a
users screen resolution (avail) then use that value to direct their browser
to pages tailored to that particular screen size.

Why bother, you wonder? I am a digital fine artist, who intends to use my
website on the internet as my primary means of exhibition; the professionl
standard I am pursueing, therefore, is different -- not better, but
different -- than the usual commercial site. If the option exists to target
a user's screen resolution and available window size, then, for me, it must
be addressed.

------------