SitePoint Sponsor

User Tag List

Results 1 to 21 of 21
  1. #1
    SitePοint Troll disgracian's Avatar
    Join Date
    Aug 2006
    Location
    Samsara
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Ubiquity of JavaScript

    I'm preparing to overhaul my tired old site and I'd like to make more extensive use of JavaScript as I go. However what I'm after is a rough gague, if such a thing exists, of how many users disable it (mostly IE users turning off JScript, I'm guessing) and how many don't have browsers that support it.

    Most of the "mission critical" features I presume would be server-scripted, but I'm not knowledgable in that area at all, so what general aspects of a website's content/features would you entrust to client-scripting?

    Any feedback welcome.

    Cheers,
    D.

  2. #2
    I ♥ PHP
    Join Date
    Jul 2003
    Location
    Melbourne, Australia
    Posts
    579
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't know that you eill ever find any decent statistics for this, but I work in the following way. for most sites I create, Javascript provides added functionality only. If the user has Javascript disabled for any reason, the site will still function perfectly. If using Javascript navigation, or AJAX calls, it is always added in through the code itself so that there is no sign of broken scripts if the browser has scripting disabled.

    The second option, is to create a site/application that relies on Javascript. This is something where you need to either have a limited, known target userbase, such as in an enclosed intranet, or you are willing to lose visitors because the site relies too heavily on Javascript. Obviously something like Google Maps would not function at all without Javascript enabled.

    Look at it this way, will the Javascript be required for the site to operate, as in, is it a web "application" that uses Javascript down to its core functionality, or will it be a website that can benefit from Javascript coding? If so, have a good look at unobtrusive techniques to allow for the best experience for non-javascript users.



    Regards,
    Jordan

  3. #3
    SitePοint Troll disgracian's Avatar
    Join Date
    Aug 2006
    Location
    Samsara
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    At least for the meantime there's probably nothing much that a <noscript> element couldn't fix. About the only major loss of functionality I can forsee is the lack of an email address in plain sight for spam harvesters.

    Cheers,
    D.
    Last edited by disgracian; Aug 30, 2006 at 02:00. Reason: used wrong tag

  4. #4
    SitePoint Member
    Join Date
    Aug 2006
    Posts
    19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I use statcounter.com to track accesses to my site. One thing it tracks is how many users have scripting turned off. Last time I looked 0.8% of users had it turned off.

    Also, I notice that once they see my 'scripting required' message, some actually go and turn it on. Not sure of those numbers but my gut feel is about a quarter of the script-off users turn it once told to.

    -J

  5. #5
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,608
    Mentioned
    24 Post(s)
    Tagged
    1 Thread(s)
    Of course those with web readers probably don't want javascript turned on because their reader can't tell them what the Javascript is doing accurately enough.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  6. #6
    SitePοint Troll disgracian's Avatar
    Join Date
    Aug 2006
    Location
    Samsara
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Web readers don't have a problem with the document.write() method, do they? That's mainly what I'd be using it for.

    Cheers,
    D.

  7. #7
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,608
    Mentioned
    24 Post(s)
    Tagged
    1 Thread(s)
    document.write is deprecated and should not be used (and can't be used with XHTML or after the page has loaded).

    All web page updates should be done either via innerHTML or (better) via the DOM.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  8. #8
    &#083;itePoint Aficionado JVLB's Avatar
    Join Date
    Jan 2002
    Location
    N 44 56.537' W 123 3.683'
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Document.write isn't exactly deprecated, it just doesn't work with XHTML because of the way XML parsers work. You'll still find plenty of examples of document.write on the W3C's tutorial site.

  9. #9
    SitePοint Troll disgracian's Avatar
    Join Date
    Aug 2006
    Location
    Samsara
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    felgall - document.write works fine as long as the page is served as text/html (which nearly all of them are and will continue to be until IE supports XHTML.

    Cheers,
    D.

  10. #10
    &#083;itePoint Aficionado JVLB's Avatar
    Join Date
    Jan 2002
    Location
    N 44 56.537' W 123 3.683'
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by disgracian
    Web readers don't have a problem with the document.write() method, do they?
    I seem to remember reading an article that dissected the performance of web readers in this regard and, as I recall, some do, some don't. The evidence presented suggested that readers are in a primative state of development.

  11. #11
    Non-Member deathshadow's Avatar
    Join Date
    Jul 2006
    Location
    Dublin, NH
    Posts
    901
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I used to be a big DHTML advocate, as in sections of repetative pre-CSS code it can cause huge bandwidth savings, AND a lot of typing.

    Now though, I'm increasingly of the opinion that javascript should be treated a bit like CSS. Just as many people say html is for data, css is for formatting - I'm starting to think that writing out actual CONTENT or navigation with Javascript is just a bad idea.

    MOST of the time you can implement similar functions server side if you are doing things like alternating styles - and accessing the DOM you can manipulate the normal tags via their CSS properties for content handling - meaning more and more you just don't need to use document.write in the first place.

    Though there are still some cases where handling or changing the content is the only way to get it to work - JW's example of google maps is a great, well... example.

    Like ANY other technology - you just have to not overuse it just because it's available or you just learned it. I made that mistake with javascript on a site a few years ago and JUST this past march 'put things right'. As with CSS, unless not using it breaks the entire content, you should make every effort to make your html present something coherent and navigatable to the user if javascript isn't present.

    Which is where a lot of javascript on websites, most notably on menus, /FAILS/ hard.

  12. #12
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,608
    Mentioned
    24 Post(s)
    Tagged
    1 Thread(s)
    Yes document.write still works under certain circumstances but where the code gets written from a document.write statement can differ between browsers resulting in the text appearing in different places. If you want consistency then you should avoid using it.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  13. #13
    SitePοint Troll disgracian's Avatar
    Join Date
    Aug 2006
    Location
    Samsara
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall
    All web page updates should be done either via innerHTML or (better) via the DOM.
    Do you know of any good resources for learning how to do the latter?

    Cheers,
    D.

  14. #14
    &#083;itePoint Aficionado JVLB's Avatar
    Join Date
    Jan 2002
    Location
    N 44 56.537' W 123 3.683'
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Document.write's only utility, in my estimation, is to build a page from scratch in a new window without having to go to the server. I've used it to produce a local popup calendar window. I used document.write to create a fully formed page, with a DOCTYPE! declaration, CSS stylesheet, the works, all without a trip down Internet lane.

    For adding a text node, it is somewhat debatable whether the DOM methods provide any greater utility than innerHTML. Certainly, innerHTML is easier and more popular, which is why virtually all browsers support it. In theory innerHTML is less efficient because of its calls to the browser's HTML rendering engine, but for adding a little text to an existing element, the difference is negligible.

    The DOM methods of createElement, appendNode, etc. come into their own when dealing with page elements. This page at the W3Schools lists the methods (as well as others) that permit element creation: http://www.w3schools.com/htmldom/dom_obj_document.asp

    Here's a quick example of using the two approaches to produce a similar effect:

    Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    <html>
    <head>
    <title>innerHTML/Node Demo I</title>
    <meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
    <style type="text/css">
    html,body{height:100%;}
    #divOne{height:50%;background:#dde;}
    #divTwo{height:50%;background:#edd;}
    #divOne td{border:3px solid #acb;}
    #divTwo td{border:3px solid #b8a;}
    </style>
    <script type="text/javascript">
    
    // A simple example of using the innerHTML non-standard (but well-supported) DOM method
    // vs. the W3C node/child DOM - compares/contrasts innerHTML's facility at HTML-input 
    // rendering and node model's easy insertion methods.
    // Note that the node methods are more efficient internally as they bypass the 
    // HTML parser to more directly manipulate the rendering engine. 
    
    function demoInnerHTML(){
      var new_txt=prompt('Please enter new text:','<b>new text<\/b>');
      document.getElementById("tdOne").innerHTML+="<br \/>"+new_txt;
    }
    function nodeWork(){
      var new_txt=prompt('Please enter new text:','new text');
      var insSpan=document.createElement("span");
      var insTd=document.getElementById("tdTwo");
      insSpan.appendChild(document.createTextNode(new_txt));
      insSpan.appendChild(document.createElement("br"));
      insSpan.style.fontWeight="bold";
      insTd.insertBefore(insSpan,insTd.lastChild);
    }
    </script>
    </head>
    <body>
    <div id="divOne">
    <p>
    <a href="#" onclick="demoInnerHTML();return false;">Demo innerHTML</a>
    </p>
    <table>
    <tr>
    <td id="tdOne">some text</td>
    </tr>
    </table>
    </div>
    <div id="divTwo">
    <p>
    <a href="#" onclick="nodeWork();return false;">Insert a node</a>
    </p>
    <table>
    <tr>
    <td id="tdTwo"><span>some text </span><br /><span>and other text</span></td>
    </tr>
    </table>
    </div>
    </body>
    </html>

  15. #15
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,159
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by disgracian
    document.write works fine as long as the page is served as text/html (which nearly all of them are and will continue to be until IE supports XHTML.
    Serving XHTML as text/html may be acceptable (albeit pointless), but only if it still works when served as an XML application!

    An HTML-only practice like document.write(), which requires the XHTML document to be served as text/html, is a very, very bad thing. Especially if your purpose for using XHTML is 'future-proofing'.
    Birnam wood is come to Dunsinane

  16. #16
    SitePοint Troll disgracian's Avatar
    Join Date
    Aug 2006
    Location
    Samsara
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo
    Serving XHTML as text/html may be acceptable (albeit pointless)
    Well, last time I tried the HTML4.01 validator at W3.org, it wouldn't even detect missing closing tags, so in terms of development I'd say it's far from pointless.
    Especially if your purpose for using XHTML is 'future-proofing'.
    I figure I've got plenty of time before Microsoft releases IE8.

    Cheers,
    D.

  17. #17
    &#083;itePoint Aficionado JVLB's Avatar
    Join Date
    Jan 2002
    Location
    N 44 56.537' W 123 3.683'
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    HTML 5 is now under development, yes, really.

    Oh, and if you use HTML 4.01 Strict, it will find many errors that slide in Transitional.
    Last edited by JVLB; Sep 5, 2006 at 08:10.

  18. #18
    I ♥ PHP
    Join Date
    Jul 2003
    Location
    Melbourne, Australia
    Posts
    579
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by JVLB
    HTML 5 is now under development, yes, really.
    This is the second time I've seen someone quote this in the past week, can you provide links to any information regarding this please?

  19. #19
    SitePοint Troll disgracian's Avatar
    Join Date
    Aug 2006
    Location
    Samsara
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Even the Strict DocType for HTML4.01 is way too lax in validating.

    Cheers,
    D.

  20. #20
    SitePοint Troll disgracian's Avatar
    Join Date
    Aug 2006
    Location
    Samsara
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by J Windebank
    This is the second time I've seen someone quote this in the past week, can you provide links to any information regarding this please?
    http://whatwg.org/specs/web-apps/current-work/ - Do a search for "HTML5" and you'll see a few mentions, but nothing of any great substance.

    Cheers,
    D.

  21. #21
    &#083;itePoint Aficionado JVLB's Avatar
    Join Date
    Jan 2002
    Location
    N 44 56.537' W 123 3.683'
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The effort on HTML 5 is just getting underway. I've seen a few news articles in trade publications like InfoWorld or eWeek mentioning it and stating it was with the blessing of the W3C. Definitely just the formative stages, but it reflects the frustration with XHTML.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •