How to count how many visitor's have js enabled and how many does not?

Discussion in 'Javascript' started by damezumari, Dec 16, 2006.

  1. damezumari

    damezumari Guest

    I would like to know how many of the visitors to my site has js enabled
    and how many has it turned off.

    I haven't found a simple solution searching Google groups so I suggest
    the following using php and mysql:

    Create a table mc_jscount table in mysql with two fields nonjs (int)
    and js (int). Create one record with nonjs and js set to zero.

    Put this code at the top of your page:

    <?php
    // increase nonjs by 1
    $sql = 'update mc_jscount set nonjs = nonjs + 1';
    $result = mysql_query($sql);
    if (mysql_affected_rows() == -1) {echo 'Unexpected error in the
    query:<br/>'; die($sql);}

    // check if we are calling this page again ourselves, see below, if we
    do $p_count is set
    if (isset($p_count))
    {
    $sql = 'update mc_jscount set nonjs = nonjs - 2, js = js + 1';
    $result = mysql_query($sql);
    if (mysql_affected_rows() == -1) {echo 'Unexpected error in the
    query:<br/>'; die($sql);}
    }
    else
    // write the javascript below:
    echo '<script language = "JavaScript">
    location.href = "mc_default.php?count=1";
    </script>';
    ?>

    A nonjs visitor to the page will increase the nonjs field by 1 and
    since he has not js enabled the script php writes will not run.

    A js visitor will have nonjs increased by 1 when he enters the page,
    then since this is the first call to the page $p_count is not set so
    the javascript will be written and executed. When it executes he
    returns to the page so nonjs is increased by 1 again. However now nonjs
    is reduced by 2 and js is increased by 1, which takes care of the two
    nonjs increases earlier. This time the script is not written so he can
    go on and enjoy the page.

    If this does not work, according to my testing it does, or is a long
    winded way of doing something simple, please post a comment.

    Thanks!

    Regards,

    Jan Nordgreen
     
    damezumari, Dec 16, 2006
    #1
    1. Advertising

  2. damezumari

    pcx99 Guest

    Re: How to count how many visitor's have js enabled and how manydoes not?

    damezumari wrote:
    > I would like to know how many of the visitors to my site has js enabled
    > and how many has it turned off.



    You don't have to be so complicated.

    <script language='Javascript" type='text/javascript'>
    <!--
    var testimg = new Image();
    testimg.src='hasJavascript.gif';
    //-->
    </script>
    <noscript>
    <img src='noJavascript.gif' width=1 height=1>
    </noscript>

    Now just make a transparent 1x1 pixel gif, copy and name it as you see
    above, then let your web server log sort it all out :) Let the sucker
    run for a month and a quick look at analog or webalizer or whatever
    reporting software you use will give you exactly how many people loaded
    the hasJavascript.gif and how many people downloaded noJavascript.gif.


    --
    http://www.hunlock.com -- Musings in Javascript, CSS.
    $FA
     
    pcx99, Dec 16, 2006
    #2
    1. Advertising

  3. damezumari

    Randy Webb Guest

    Re: How to count how many visitor's have js enabled and how manydoes not?

    pcx99 said the following on 12/16/2006 1:44 AM:
    > damezumari wrote:
    >> I would like to know how many of the visitors to my site has js enabled
    >> and how many has it turned off.

    >
    >
    > You don't have to be so complicated.
    >
    > <script language='Javascript" type='text/javascript'>


    Don't make it more complicated than it needs to be then. Drop the
    deprecated language attribute and the utterly useless HTML comment
    delimiters in script blocks.

    > <!--
    > var testimg = new Image();
    > testimg.src='hasJavascript.gif';
    > //-->
    > </script>
    > <noscript>
    > <img src='noJavascript.gif' width=1 height=1>
    > </noscript>
    >
    > Now just make a transparent 1x1 pixel gif, copy and name it as you see
    > above, then let your web server log sort it all out :) Let the sucker
    > run for a month and a quick look at analog or webalizer or whatever
    > reporting software you use will give you exactly how many people loaded
    > the hasJavascript.gif and how many people downloaded noJavascript.gif.


    And it won't report how many have JS enabled and images disabled........
    Or, JS disabled and images disabled. Back to the drawing board.

    --
    Randy
    Chance Favors The Prepared Mind
    comp.lang.javascript FAQ - http://jibbering.com/faq
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Dec 16, 2006
    #3
  4. damezumari

    pcx99 Guest

    Re: How to count how many visitor's have js enabled and how manydoes not?

    Randy Webb wrote:
    > pcx99 said the following on 12/16/2006 1:44 AM:
    >> damezumari wrote:
    >>> I would like to know how many of the visitors to my site has js enabled
    >>> and how many has it turned off.

    >>
    >>
    >> You don't have to be so complicated.
    >>
    >> <script language='Javascript" type='text/javascript'>

    >
    > Don't make it more complicated than it needs to be then. Drop the
    > deprecated language attribute and the utterly useless HTML comment
    > delimiters in script blocks.


    HTMLKit is quite happy to insert all of this nice stuff for me the
    moment I start typing <script. Since it costs nothing* to provide a
    little ancient/exotic browser insurance, I indulge it, especially since
    it evokes such amusing hostility in some people. I have a REALLY good
    laugh whenever the topic is brought up because not even the w3
    validators will complain about a language definition in the script tag
    or comment "insulators", and lord knows they complain about everything else.

    * Since we're playing lawyercode -- nothing=cost so trivial in terms of
    performance/bandwidth as to not being worth notice.

    >> <!--
    >> var testimg = new Image();
    >> testimg.src='hasJavascript.gif';
    >> //-->
    >> </script>
    >> <noscript>
    >> <img src='noJavascript.gif' width=1 height=1>
    >> </noscript>
    >>
    >> Now just make a transparent 1x1 pixel gif, copy and name it as you see
    >> above, then let your web server log sort it all out :) Let the sucker
    >> run for a month and a quick look at analog or webalizer or whatever
    >> reporting software you use will give you exactly how many people
    >> loaded the hasJavascript.gif and how many people downloaded
    >> noJavascript.gif.

    >
    > And it won't report how many have JS enabled and images disabled........
    > Or, JS disabled and images disabled. Back to the drawing board.


    In the upper block you scold me for using 'deprecated language' and in
    the second block you scold me for not pandering to 'deprecated surfing' :p

    That said, I understand accessibility and some wireless access devices
    would have javascript but for whatever reasons (small screen, user
    blind, etc) surf without images. If this is a major concern simply
    having the javascript redirect the page if only to itself with a
    ?JS=hasJavascript addendum will throw a unique entry into the log file.
    Meaning (TotalHits-(TotalhasJavascript*2)) = No Javascript. (*2 to
    factor out the original unredirected hit). This eliminates searchBots
    in the javascript area but you'll still need to filter them out in the
    noJavascript area based on the user agents in the web logs something
    that would need to be done anyway regardless of the system used since
    bots would inordinately skew the "no-js" numbers up (another plus for
    using weblog reporting).


    The Images worthwhile/Images notworthwhile debate aside, one thing is
    certain, using weblogs to track this information is a great deal simpler
    than using mysql/php/html for the simple fact that web logs record the
    user agent and there are enough weblog analyzers out that will let you
    look at your data in countless different ways. The fact that it
    requires less coding effort and has much richer reporting options still
    makes analyzing the log file one of the simplest and easiest ways to
    approach this problem.


    --
    http://www.hunlock.com -- Musings in Javascript, CSS.
    $FA
     
    pcx99, Dec 16, 2006
    #4
  5. damezumari wrote:
    > I would like to know how many of the visitors to my site
    > has js enabled and how many has it turned off.


    So you are not interested in how many never had it to start with?

    However, what is the point of knowing that? The availability of
    client-side scripting does not guarantee the ability to take any
    particular action with client-side scripting. Scriptable browser4s have
    always varied considerably in how dynamic that are, and what facilities
    they may provide (and which configuration settings may impact the use of
    those facilities), and some technologies that depend on scripting also
    depend on some other browser features. For example, AJAX requires a
    client-side XML HTTP Request object, which may not be implemented in any
    specific browser, and in IEs 5-6 requires the scripting of ActiveX that
    is "marked safe for scripting" to be enabled in the pertinent security
    zone in addition to JScript.

    > I haven't found a simple solution searching Google groups


    You will not find simple solutions to insoluble problems (though you may
    find people proposing 'solution').

    <snip>
    > If this does not work, according to my testing it does,


    I don't see any measures to take account of remote HTTP caches or
    caching firewalls/proxies. But how are you going about testing the
    influence of various HTTP caches on your code?

    > or is a long winded way of doing something simple,
    > please post a comment.


    If someone bookmarks (or worse, links to) the page with the query string
    isn't their re-visiting (or others visiting through the link) the page
    going to throw the numbers off?

    Richard.
     
    Richard Cornford, Dec 16, 2006
    #5
  6. pcx99 wrote:
    > Randy Webb wrote:
    >> pcx99 said the following on 12/16/2006 1:44 AM:
    >>> damezumari wrote:
    >>>> I would like to know how many of the visitors to my site
    >>>> has js enabled and how many has it turned off.
    >>>
    >>>
    >>> You don't have to be so complicated.
    >>>
    >>> <script language='Javascript" type='text/javascript'>

    >>
    >> Don't make it more complicated than it needs to be then.
    >> Drop the deprecated language attribute and the utterly
    >> useless HTML comment delimiters in script blocks.

    >
    > HTMLKit is quite happy to insert all of this nice stuff for me
    > the moment I start typing <script.


    No greater condemnation of HTMLKit or its authors could be presented.

    > Since it costs nothing* to provide a
    > little ancient/exotic browser insurance,


    What "ancient/exotic browser insurance"? The HTML style comments in
    script elements was a workaround for browsers pre-dating Netscape 2 and
    IE 3. We are currently at a point where a very good general case can be
    made for totally disregarding 4th generation browses. There is also the
    question of the possible future use of XHTML, where the contents of
    script elements are PCDAT and <!-- .. --> style comments may be removed
    by XML parsers, removing the script content in the process.

    > I indulge it, especially since
    > it evokes such amusing hostility in some people.


    Why do you see it as hostility to suggest not using attributes that are
    depressed themselves and redundant alongside required attributes is
    pointless? Or that actions taken to mitigate the behaviour of browsers
    so old that nobody is still using them is better left out?

    > I have a REALLY good laugh whenever the topic is brought
    > up because not even the w3 validators will complain about
    > a language definition in the script tag


    It will complain if you attempt to validate against a strict version of
    the DTDs.

    > or comment "insulators",


    An HTML validator will never complain about the contents of CDATA, and
    an XHTML validator is very unlikely to complain about the contents of a
    comment.

    > and lord knows they complain
    > about everything else.


    No they don't, they complain about formally invalid documents, as they
    are designed to do.

    > * Since we're playing lawyercode -- nothing=cost so trivial
    > in terms of performance/bandwidth as to not being worth notice.


    It is still a strange attitude that has the editor making code-authoring
    decisions.

    >>> <!--
    >>> var testimg = new Image();
    >>> testimg.src='hasJavascript.gif';


    There is no public standard that states that script enabled web browsers
    will implement a global Image constructor, or that assignments to the -
    src - property of such an object will result in an HTTP request being
    made. It is certainly the case that even some browsers that support the
    object will not make the request (IceBrowser 5 being the first example
    that springs to mind).

    <snip>
    >> And it won't report how many have JS enabled and images
    >> disabled........ Or, JS disabled and images disabled.
    >> Back to the drawing board.

    >
    > In the upper block you scold me for using 'deprecated
    > language' and in the second block you scold me for not
    > pandering to 'deprecated surfing' :p


    What makes taking advantage of the configuration options available on
    the very newest browsers "deprecated surfing"? Isn't this really a VKish
    'I cannot cope so I will deny the need to cope by deprecating the issue'
    attitude?

    > That said, I understand accessibility and some wireless access
    > devices would have javascript but for whatever reasons (small
    > screen, user blind, etc) surf without images.
    > If this is a major concern simply having the javascript
    > redirect the page if only to itself with a
    > ?JS=hasJavascript addendum will throw a unique entry into
    > the log file.


    Doesn't that mean that the javascript enabled visitors will only ever
    get a chance to bookmark the page with the value on the query string,
    and so whenever they re-visit the site they will re-enforce the numbers
    for javascript enabled visitors, independently of whether thy have
    javascript enabled at the time (and never re-issuing the first request)?
    If the starting position already demonstrates a propensity for users to
    have javascript enabled then you may end up with a self-biasing system,
    that swings rapidly to the extreme position.

    <snip>
    > ... , one
    > thing is certain, using weblogs to track this information is
    > a great deal simpler than using mysql/php/html for the simple
    > fact that web logs record the user agent and there are enough
    > weblog analyzers out that will let you look at your data in
    > countless different ways.


    Web logs on a server are only capable of reporting HTTP requests that
    get to the server, while it is a necessity of HTTP that servers never be
    required to serve all requests directed in their direction. Several
    years ago it was already being assented that without the proportion of
    HTTP requests that were then being served from HTTP caches on the
    network the load would have far exceeded the capacity of the network.

    > The fact that it requires less coding effort and has much
    > richer reporting options still makes analyzing the log file
    > one of the simplest and easiest ways to approach this problem.


    Or one of the simplest ways of deluding yourself into believing whatever
    you wanted to believe before looking.

    Richard.
     
    Richard Cornford, Dec 16, 2006
    #6
  7. damezumari

    damezumari Guest

    Hi Richard,

    Thank you, and to the others, for answering.


    > However, what is the point of knowing that?


    I am new to web development and in the process of creating a site. I
    started out believing that everybody has js enabled. Now that I about
    to make it accessible for non-js users as well I got curious to know
    for how many people I do this extra work. 3%, 10%?

    > I don't see any measures to take account of remote HTTP caches or
    > caching firewalls/proxies. But how are you going about testing the
    > influence of various HTTP caches on your code?


    I don't even know what 'remote HTTP caches' mean so I can't answer.

    > If someone bookmarks (or worse, links to) the page with the query string
    > isn't their re-visiting (or others visiting through the link) the page
    > going to throw the numbers off?


    No. I am interested in the proportion of visits who has js enabled, not
    the number of visitors.

    Regards,

    Jan Nordgreen
     
    damezumari, Dec 16, 2006
    #7
  8. damezumari wrote:
    > Thank you, and to the others, for answering.
    >
    >> However, what is the point of knowing that?

    >
    > I am new to web development and in the process of creating
    > a site. I started out believing that everybody has js
    > enabled. Now that I about to make it accessible for non-js
    > users as well I got curious to know for how many people I
    > do this extra work. 3%, 10%?


    Right, so what you want to know is not the proportion of visitors who
    have javascript enabled vs disabled but rather the proportion of
    potential visitors for whom your javascript dependent version of the
    site was non-viable as the result of that javascript dependency. While
    all users with javascript disabled/unavailable will find a javascript
    dependent site non-viable the odds are good that any scripted action
    that introduces such a dependency will also render a site non-viable to
    the users of script enabled browsers that do not provide the
    facilities/features required by the actual scripts. Thus studying the
    proportion of users with javascript disabled (even if practical) would
    not properly answer your real question.

    >> I don't see any measures to take account of remote HTTP
    >> caches or caching firewalls/proxies. But how are you going
    >> about testing the influence of various HTTP caches on your
    >> code?

    >
    > I don't even know what 'remote HTTP caches' mean so I can't
    > answer.


    HTTP caches are the manifestation of on of the potentials in the HTTP
    protocol that act to render all server-based statistics gathering
    problematic to the point of being mostly meaningless in the area of
    deriving generalisations. You have attempted to write a statistics
    gathering script without even knowing they exist, let alone what they
    may do, how they may do it or what the implications are. You are not
    alone in this and the accumulated effect is that almost all statistics
    relating to any general aspect of HTTP are utterly bogus. And mostly you
    can tell they are bogus by observing that published statistics never
    explain the statistics gathering process used, and do not reveal what,
    if any, measures have been taken to account for the statistics gathering
    issues inherent in HTTP.

    You will be hard presses to find anybody who is familiar with HTTP how
    will give any credence to any general web-based statistics at all (this
    is as opposed to server gathered statistics used for server-specific
    tasks such as load balancing and optimisation). On the other hand you
    will find plenty of people who pay attention to such statistics, but
    will find them as ignorant of HTTP as you currently are.

    You should research the subject, it will save you wasting a great deal
    of time in worthless pursuits.

    >> If someone bookmarks (or worse, links to) the page with the
    >> query string isn't their re-visiting (or others visiting
    >> through the link) the page going to throw the numbers off?

    >
    > No. I am interested in the proportion of visits who has js enabled,
    > not the number of visitors.


    That would not matter. An individual re-visiting your site using a
    bookmark that included you redirect query string will still skew the
    results and impact the reported proportions as well as the totals.

    Richard.
     
    Richard Cornford, Dec 16, 2006
    #8
  9. damezumari

    pcx99 Guest

    Re: How to count how many visitor's have js enabled and how manydoes not?

    Richard Cornford wrote:
    > pcx99 wrote:
    >> HTMLKit is quite happy to insert all of this nice stuff for me
    >> the moment I start typing <script.

    >
    > No greater condemnation of HTMLKit or its authors could be presented.


    Oh I use PSPad and a few other editors as well, but like I say HTML kit
    is a bit of a personality test good for endless laughs when its code is
    posted on certain discussion boards :)

    >> Since it costs nothing* to provide a
    >> little ancient/exotic browser insurance,

    >
    > What "ancient/exotic browser insurance"? The HTML style comments in
    > script elements was a workaround for browsers pre-dating Netscape 2 and
    > IE 3. We are currently at a point where a very good general case can be
    > made for totally disregarding 4th generation browses. There is also the
    > question of the possible future use of XHTML, where the contents of
    > script elements are PCDAT and <!-- .. --> style comments may be removed
    > by XML parsers, removing the script content in the process.


    Aye. But because of the fact that web pages tend to hang around
    forever, these tags you are so obsessive about will never truly go away.
    They're not going to be revoked like the analog spectrum to be
    re-assigned to something greater and grander. Because it costs nothing
    to allow them to remain in the browser's parsers or at least ignored by
    the parser, they will remain. They will never be used for something
    else, forever a tiny comment in the <script> tag.

    >> I indulge it, especially since
    >> it evokes such amusing hostility in some people.

    >
    > Why do you see it as hostility to suggest not using attributes that are
    > depressed themselves and redundant alongside required attributes is
    > pointless? Or that actions taken to mitigate the behaviour of browsers
    > so old that nobody is still using them is better left out?


    Because it's anal retentive and the argument is as pointless as the tags
    themselves. It costs nothing to leave them in, people can use them
    without any ill effects. It won't break the page, it won't break future
    pages, it won't break old browsers it won't break new browsers.

    Every time the debate is brought up it SCREAMS pompous arrogance because
    it is a tangent that has NOTHING at all to do with the original problem
    and it doesn't even hinder getting a working answer to the problem save
    for the pointless time and effort spent debating the tangent when effort
    could be expended solving the original problem.

    >> I have a REALLY good laugh whenever the topic is brought
    >> up because not even the w3 validators will complain about
    >> a language definition in the script tag

    >
    > It will complain if you attempt to validate against a strict version of
    > the DTDs.
    >
    >> or comment "insulators",

    >
    > An HTML validator will never complain about the contents of CDATA, and
    > an XHTML validator is very unlikely to complain about the contents of a
    > comment.


    Aye, but apparently people do ;) Strict mode catches language=?
    That's a new one, but I shouldn't be surprised. I validate loose. It's
    harder to code for, more frustrating to write, but in the end a little
    more powerful in getting your objectives met with a spot of professional
    polish. Yes I know the professional web page has a higher chance of
    breaking in the next browser version but professional also means the
    resources to fix it when that happens or having the site totally
    revamped anyway because there is a re-design schedule.

    >> and lord knows they complain
    >> about everything else.

    >
    > No they don't, they complain about formally invalid documents, as they
    > are designed to do.


    Funny how accurate the <script language=""> personality test is ;)

    BTW, you, randy, and the other shaman might as well set up a macro for
    your rants because even when I'm using pspad I'm likely as not to drop
    in Language <!-- --> just for chuckles. Hmmm I better set up a response
    macro while I'm here...

    <begin macro> :p <end macro>

    there, that will do it :)

    >> * Since we're playing lawyercode -- nothing=cost so trivial
    >> in terms of performance/bandwidth as to not being worth notice.

    >
    > It is still a strange attitude that has the editor making code-authoring
    > decisions.


    No. The editor makes code making suggestions. It's up to me to decide
    if I want to be lazy and leave it in, or hit the backspace a few times,
    or failing that, go in and customize the package so it doesn't include
    comments or language when generating a script block. So far the scales
    are deeply tipped toward "status quo" and no amount of rants on CLJ is
    going to change that.

    >> In the upper block you scold me for using 'deprecated
    >> language' and in the second block you scold me for not
    >> pandering to 'deprecated surfing' :p

    >
    > What makes taking advantage of the configuration options available on
    > the very newest browsers "deprecated surfing"? Isn't this really a VKish
    > 'I cannot cope so I will deny the need to cope by deprecating the issue'
    > attitude?


    No this is a 'cost benefit analysis' The original problem sought out a
    generalized estimate of JS/non-JS surfers. The shaman swooped in and
    decided it needed to be a formal scientific survey despite the fact that
    there will never be 100% valid results unless each visitor to the web
    page is required to set up an account and log in before visiting the
    test page, and further that each person that logs in be matched to a
    real world identity and that they log in under carefully monitored
    network conditions between the client and server.

    Since that level of accuracy will not be met we are discussing a
    generalized, glorified, hit counter regardless of what you and randy
    would like to otherwise believe. And since you're so fond of quoting
    history, perhaps you would like to quote the grand and glorious history
    images have had in hit counting. I think you'll find that, failing the
    resources to do scientific studies of page hits, it's a time honored and
    accepted practice of counting pages.

    >> That said, I understand accessibility and some wireless access
    >> devices would have javascript but for whatever reasons (small
    >> screen, user blind, etc) surf without images.
    >> If this is a major concern simply having the javascript
    >> redirect the page if only to itself with a
    >> ?JS=hasJavascript addendum will throw a unique entry into
    >> the log file.

    >
    > Doesn't that mean that the javascript enabled visitors will only ever
    > get a chance to bookmark the page with the value on the query string,
    > and so whenever they re-visit the site they will re-enforce the numbers
    > for javascript enabled visitors, independently of whether thy have
    > javascript enabled at the time (and never re-issuing the first request)?
    > If the starting position already demonstrates a propensity for users to
    > have javascript enabled then you may end up with a self-biasing system,
    > that swings rapidly to the extreme position.


    Surely, in order to press an attack, you're not blindly overlooking the
    fact that referer urls (or lack thereof), history manipulation for the
    current url, framesets, and other log analysis can't be used to offset
    bookmarks. Or did you truly not consider these tools? Either way, it
    doesn't look that great for you over there.

    >> thing is certain, using weblogs to track this information is
    >> a great deal simpler than using mysql/php/html for the simple
    >> fact that web logs record the user agent and there are enough
    >> weblog analyzers out that will let you look at your data in
    >> countless different ways.

    >
    > Web logs on a server are only capable of reporting HTTP requests that
    > get to the server, while it is a necessity of HTTP that servers never be
    > required to serve all requests directed in their direction. Several
    > years ago it was already being assented that without the proportion of
    > HTTP requests that were then being served from HTTP caches on the
    > network the load would have far exceeded the capacity of the network.


    There you go trying to make this into a scientific survey where that was
    never a part of the original problem. The fellow wasn't looking for a
    dissertation, just a generalized hit counter that separated JS from non JS.

    >> The fact that it requires less coding effort and has much
    >> richer reporting options still makes analyzing the log file
    >> one of the simplest and easiest ways to approach this problem.

    >
    > Or one of the simplest ways of deluding yourself into believing whatever
    > you wanted to believe before looking.


    Drumroll please! And the answer is...







    Please, do fill in the blank.

    --
    http://www.hunlock.com -- Musings in Javascript, CSS.
    $FA
     
    pcx99, Dec 17, 2006
    #9
  10. damezumari

    damezumari Guest

    Hi Richard,

    Thank you for your last comment.

    > You should research the subject, it will save you wasting a great deal
    > of time in worthless pursuits.


    I couldn't agree more! This was my first step in my researching. Thanks
    to you and the others who answered I have learnt a lot and am ready for
    my second step.

    Thanks!

    Regards,

    Jan Nordgreen
     
    damezumari, Dec 17, 2006
    #10
  11. damezumari

    Mike.Duffy Guest

    pcx99 <> wrote in
    news:TW%gh.9023$:


    >
    > Drumroll please! And the answer is...
    >


    I forget who said it first, but I say as well; use the
    "javascript.enabled" thingy.

    If someone uses a browser that deliberately mocks it, then the end result
    is the same as a spoiled ballot in an election. By this I mean that a
    deliberate one is counted the same as an accidental one, regardless of how
    obvious it is accidental or not.

    Of course, in Canada we have the option of returning the ballot to the
    scrutineer, saying that we don't want to vote for anyone on the list. It
    pisses the off because they have to keep the ballots separate as well as
    count them separately. I'm not able to relate this last point to a browser
    javascript analogy, but I'm sure somebody can, given the huge volume of
    debate that has been generated over a question that seems to have an
    obvious answer.
     
    Mike.Duffy, Dec 17, 2006
    #11
  12. In article <TW%gh.9023$>, pcx99
    <> writes

    <snip>
    >Yes I know the professional web page has a higher chance of breaking in
    >the next browser version but professional also means the resources to
    >fix it when that happens or having the site totally revamped anyway
    >because there is a re-design schedule.

    <snip>

    So that's what "professional" means : bodge it today, then charge extra
    money to bodge it tomorrow.

    John
    --
    John Harris
     
    John G Harris, Dec 17, 2006
    #12
  13. damezumari

    damezumari Guest

    damezumari, Dec 18, 2006
    #13
  14. Richard Cornford wrote:
    > damezumari wrote:
    > > Thank you, and to the others, for answering.
    > >
    > >> However, what is the point of knowing that?

    > >
    > > I am new to web development and in the process of creating
    > > a site. I started out believing that everybody has js
    > > enabled. Now that I about to make it accessible for non-js
    > > users as well I got curious to know for how many people I
    > > do this extra work. 3%, 10%?

    >
    > Right, so what you want to know is not the proportion of visitors who
    > have javascript enabled vs disabled but rather the proportion of
    > potential visitors for whom your javascript dependent version of the
    > site was non-viable as the result of that javascript dependency. While
    > all users with javascript disabled/unavailable will find a javascript
    > dependent site non-viable the odds are good that any scripted action
    > that introduces such a dependency will also render a site non-viable to
    > the users of script enabled browsers that do not provide the
    > facilities/features required by the actual scripts. Thus studying the
    > proportion of users with javascript disabled (even if practical) would
    > not properly answer your real question.


    How about a faqentry for this generally common question? Has this idea
    been turned down in the past? It was certainly something I was confused
    by when i learned about the <noscript> tags and thought that they would
    solve my problems.

    Peter
     
    Peter Michaux, Dec 18, 2006
    #14
  15. damezumari

    Evertjan. Guest

    Peter Michaux wrote on 18 dec 2006 in comp.lang.javascript:

    > Richard Cornford wrote:
    > How about a faqentry for this generally common question? Has this idea
    > been turned down in the past? It was certainly something I was confused
    > by when i learned about the <noscript> tags and thought that they would
    > solve my problems.


    Good idea.

    However we should stress that this needs serverside coding.

    ======================================

    A NOT tested clientside javascript + serverside ASP-JScript example,
    finding the percentage of page requests, not of users:

    <img src='/count.asp' style='display:none;'>
    <script type='text/javascript'>
    var tempImg = new Image();
    tempImg = "/count.asp?enabled=1";
    </script>

    ======== count.asp ==========

    <% response.expires = -500 %>
    <script runat=server language=jscript>

    // db connection opening stuff

    sql = (request.querystring('enabled')==1)
    ? 'UPDATE CountTbl SET enabled = enabled + 1'
    : 'UPDATE CountTbl SET count = count + 1';

    // sql executing and db closing stuff
    // sending tiny img header and body stuff

    </script>

    ===================

    the running percentage can be read from the database by:

    Percentage of page requests with Javascript enabled:
    <% = Math.round( 100 * enabled / count); %> %.



    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Dec 18, 2006
    #15
  16. damezumari

    rchmura Guest

    A quick and easy soltuion to this is to use http://gostats.com to count
    number of js enabled visitors as well as other js specific data. (Just
    so that the wheel isn't re-invented)
     
    rchmura, Dec 19, 2006
    #16
  17. damezumari

    Evertjan. Guest

    rchmura wrote on 19 dec 2006 in comp.lang.javascript:

    > A quick and easy soltuion to this is to use http://gostats.com to count
    > number of js enabled visitors as well as other js specific data. (Just
    > so that the wheel isn't re-invented)


    A quick and easy soltuion to WHAT?

    [please always quote on usenet]

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Dec 19, 2006
    #17
  18. rchmura wrote:
    > A quick and easy soltuion to this is to use
    > http://gostats.com


    Isn't it quickest, easiest and probably cheapest to just make the
    numbers up off the top of your head? Fabricate a credible number and the
    odds are nobody will even question it.

    > to count number of js enabled visitors as well as
    > other js specific data.


    My experience of looking at scripts used for that purpose (they are
    intermittently the subjects of questions on this group) is that they are
    written by less than competent browser scripters with no more than a
    limited experience of two or three browsers, and that they fall down
    when exposed to anything out of the ordinarily. With the consequence
    that whatever they do report (if they get that far in some cases) will
    not necessarily reflect reality.

    The last example I looked at was so riddled with dubious assumptions in
    the client side code that it announced that my IE 6 was an "undefined"
    (literally) version of Opera with javascript disabled (even though the
    report originated with client-side code). And that bogus output directly
    followed from one user configuration setting.

    > (Just so that the wheel isn't re-invented)


    And if there has never been a wheel to be re-invented? What is the moral
    of the Hans Christian Anderson story "The Emperor's new Clothes"? Maybe
    Caveat Emptor in the end.

    Richard.
     
    Richard Cornford, Dec 20, 2006
    #18
  19. damezumari wrote:
    > Here is a good article on web analytics:
    >
    > http://en.wikipedia.org/wiki/Web_analytics


    Good? It reads like it was written by a producer of web statistics
    reporting software who would rather not mention the limitations inherent
    in the filed as that would not be good for marketing.

    Richard.
     
    Richard Cornford, Dec 20, 2006
    #19
    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:
    627
    Jacob Yang [MSFT]
    Aug 26, 2003
  2. Greg Collins [InfoPath MVP]

    Active Visitor Count

    Greg Collins [InfoPath MVP], Nov 10, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    457
    Juan T. Llibre
    Nov 10, 2005
  3. Joshua Muheim
    Replies:
    5
    Views:
    131
    Phlip
    Aug 11, 2007
  4. confused

    How many browsers JS enabled?

    confused, May 31, 2004, in forum: Javascript
    Replies:
    11
    Views:
    257
    confused replies
    Jun 2, 2004
  5. Tom
    Replies:
    7
    Views:
    338
    Dr John Stockton
    Jun 18, 2004
Loading...

Share This Page