How many browsers JS enabled?

Discussion in 'Javascript' started by confused, May 31, 2004.

  1. confused

    confused Guest

    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, May 31, 2004
    #1
    1. Advertising

  2. "confused" <> writes:

    > 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.


    That's (obviously) not a sentiment that is generally shared by this group.
    It is wiser to use it wisely :)

    > 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!


    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.

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


    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 -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, May 31, 2004
    #2
    1. Advertising

  3. confused wrote:
    > 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.


    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.

    > 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% --

    <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.

    > that is certainly workable for me!


    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, May 31, 2004
    #3
  4. confused

    Matt Kruse Guest

    Richard Cornford wrote:
    > 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).


    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, May 31, 2004
    #4
  5. Matt Kruse wrote:

    >>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).


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


    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.

    > 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.


    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.

    > 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.


    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.
    Yann-Erwan Perio, May 31, 2004
    #5
  6. Matt Kruse wrote:
    >Richard Cornford wrote:
    >> 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).

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


    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.

    > It's conceivable that people are using browsers that don't support
    > CSS,


    Conceivable? I would have said that was a certainty.

    > 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.


    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).

    > 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.


    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.

    > 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.


    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.

    > 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.


    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).

    > 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.


    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, Jun 1, 2004
    #6
  7. confused

    Matt Kruse Guest

    Richard Cornford wrote:
    > 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.


    Depends on which HTML features are used. If content is put in iframes, for
    example, older browsers will not see the content.

    >> 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.

    > I assume what you mean here is that one person's idea of an appealing
    > visual presentation may not be another's.


    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.

    > Personally I don't perceive ugliness as a reason for leaving a site.


    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 :)

    > If someone starts off learning how to design javascript in a way that
    > adds functionality without introducing any javascript dependency...


    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/
    Matt Kruse, Jun 1, 2004
    #7
  8. 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/r/c/rcg8/uid/screensniffer.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
    confused replies, Jun 1, 2004
    #8
  9. Matt Kruse wrote:
    > Richard Cornford wrote:

    <snip>
    >>> 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.

    >> I assume what you mean here is that one person's idea of an
    >> appealing visual presentation may not be another's.

    >
    > 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.


    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.

    >> Personally I don't perceive ugliness as a reason for leaving a site.

    >
    > 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 :)


    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.

    >> If someone starts off learning how to design javascript in a
    >> way that adds functionality without introducing any
    >> javascript dependency...

    >
    > 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"?


    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.

    > 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?


    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).

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


    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.

    > 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"?


    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".

    > What if the content itself is "extra functionality"?


    An example?

    > Where is the line between "core"
    > functionality and "extra" functionality?


    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.

    > There isn't always a clear answer.


    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.
    Richard Cornford, Jun 1, 2004
    #9
  10. confused replies wrote:
    > 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.


    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).

    > This would exclude higher JS functions --


    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.

    > 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.


    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).

    > 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,


    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.

    > 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.


    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.

    > 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.


    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).

    > 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. ...

    <snip>
    > ... . 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.


    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).

    > 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?


    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.

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


    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).

    > 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.


    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.

    > 2) Second, my home page has no images, gifs, or thumbnails. ...

    <snip>
    > ... 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,
    <snip>
    .... ). Advice anyone?
    >
    > Also, I was elsewhere directed to this link --
    > http://httpd.apache.org/docs/mod/mod_expires.html -- ...

    <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.
    Richard Cornford, Jun 1, 2004
    #10
  11. Yann-Erwan Perio wrote:

    > Matt Kruse wrote:
    >>>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).

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

    >
    > I believe that such user agents are far more rare than user agents not
    > supporting javascript or a particular DOM, [...]


    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
    Thomas 'PointedEars' Lahn, Jun 2, 2004
    #11
  12. -- 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?

    >>>>following testing, this won't work, since other other 'sizing'

    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.

    ------------
    confused replies, Jun 2, 2004
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gabor
    Replies:
    3
    Views:
    600
    Jacob Yang [MSFT]
    Aug 26, 2003
  2. =?Utf-8?B?U2FtYmE=?=

    Detecting Script enabled or not in Client Browsers

    =?Utf-8?B?U2FtYmE=?=, Jul 29, 2005, in forum: ASP .Net
    Replies:
    4
    Views:
    334
    Rob Amos
    Jul 29, 2005
  3. Deryck
    Replies:
    51
    Views:
    5,245
    Art Sackett
    Aug 2, 2004
  4. El Kabong

    Browsers, browsers! Quo vadis?

    El Kabong, May 11, 2007, in forum: HTML
    Replies:
    23
    Views:
    873
    dorayme
    May 13, 2007
  5. damezumari
    Replies:
    18
    Views:
    245
    Richard Cornford
    Dec 20, 2006
Loading...

Share This Page