Did Anyone Backup the "Code Worth Recommending Project"?

Discussion in 'Javascript' started by Jeremy J Starcher, Apr 25, 2009.

  1. Did anyone snag a copy of the Code Worth Recommending Project before it
    vanished?

    Old URL < http://cljs.michaux.ca >

    I checked with The Wayback Machine < http://archive.org > and they didn't
    have it.
    Jeremy J Starcher, Apr 25, 2009
    #1
    1. Advertising

  2. Jeremy J Starcher wrote:
    > Did anyone snag a copy of the Code Worth Recommending Project before it
    > vanished?
    >
    > Old URL < http://cljs.michaux.ca >
    >
    > I checked with The Wayback Machine < http://archive.org > and they didn't
    > have it.


    ,-<http://web.archive.org/web/*/http://cljs.michaux.ca/>
    |
    | * Material typically becomes available here 6 months after collection

    However, the Google cache doesn't have it, too:

    <http://209.85.129.132/search?q=cache:http%3A%2F%2Fcljs.michaux.ca%2F>

    You must have had used a robots.txt of sorts to forbid caching.

    Another Web cache is Coral CDN:

    <http://michaux.ca.nyud.net:8090/>

    (I took those from the CacheIt! Firefox extension.) I don't know what the
    actual URI of the CWRP was, so you could try that if you still know it.

    And sorry, no, I didn't mirror it.


    PointedEars
    Thomas 'PointedEars' Lahn, Apr 25, 2009
    #2
    1. Advertising

  3. On Sat, 25 Apr 2009 21:26:17 -0400, kangax wrote:

    > Jeremy J Starcher wrote:
    >> Did anyone snag a copy of the Code Worth Recommending Project before it
    >> vanished?
    >>
    >> Old URL < http://cljs.michaux.ca >
    >>
    >> I checked with The Wayback Machine < http://archive.org > and they
    >> didn't have it.
    >>
    >>

    > If I'm not mistaken, many ideas (if not everything) from CWR were
    > implemented in Peter's Fork library <http://forkjavascript.org/> and
    > David's "My Library" <http://www.cinsoft.net/mylib.html>
    >
    > You can browse trunk of Fork via trac
    > <http://code.michaux.ca/trac/browser/trunk/Fork/public/javascripts/fork>



    Ah, I know that David's "My Library" used a number of ideas from CWR but
    it looks like he added a lot to it as well. I didn't realize that Fork
    used the ideas to, but I should have.

    Thanks.
    Jeremy J Starcher, Apr 27, 2009
    #3
  4. Jeremy J Starcher

    David Mark Guest

    On Apr 27, 3:24 pm, Jeremy J Starcher <> wrote:
    > On Sat, 25 Apr 2009 21:26:17 -0400, kangax wrote:
    > > Jeremy J Starcher wrote:
    > >> Did anyone snag a copy of the Code Worth Recommending Project before it
    > >> vanished?

    >
    > >> Old URL <http://cljs.michaux.ca>

    >
    > >> I checked with The Wayback Machine <http://archive.org> and they
    > >> didn't have it.

    >
    > > If I'm not mistaken, many ideas (if not everything) from CWR were
    > > implemented in Peter's Fork library <http://forkjavascript.org/> and
    > > David's "My Library" <http://www.cinsoft.net/mylib.html>

    >
    > > You can browse trunk of Fork via trac
    > > <http://code.michaux.ca/trac/browser/trunk/Fork/public/javascripts/fork>

    >
    > Ah, I know that David's "My Library" used a number of ideas from CWR but
    > it looks like he added a lot to it as well.  I didn't realize that Fork
    > used the ideas to, but I should have.
    >


    Fork predates CWR. Most of CWR ended up in My Library, but most of My
    Library is not CWR (it became defunct soon after I started my
    project.)
    David Mark, Apr 28, 2009
    #4
  5. Jeremy J Starcher

    David Mark Guest

    On Apr 28, 1:23 pm, Jeremy J Starcher <> wrote:
    > On Tue, 28 Apr 2009 10:12:23 -0700, David Mark wrote:
    > > On Apr 27, 3:24 pm, Jeremy J Starcher <> wrote:
    > >> Ah, I know that David's "My Library" used a number of ideas from CWR
    > >> but it looks like he added a lot to it as well.  I didn't realize that
    > >> Fork used the ideas to, but I should have.

    >
    > > Fork predates CWR.  Most of CWR ended up in My Library, but most of My
    > > Library is not CWR (it became defunct soon after I started my project.)

    >
    > It was your "My Library" [my grammar checker is going to love that] that
    > got me looking for CWR.  I was, uh, looking for code to recommend to
    > someone that was free of legal encumbrance.  


    The only recommendation I would make regarding that project is to
    learn from it. The first lesson is that a general-purpose script is a
    bad idea. There are silly mistakes to be found (some documented in
    its forum) and it has never been thoroughly tested (I haven't tried it
    in any browser released after the beginning of 2008.)

    The first thing to ask your associate is what they want to do (and in
    what context.) My Library, Fork Javascript and the rest are likely
    not ideal solutions. However, by reading those scripts (as opposed to
    a fantasy like jQuery), your associate may learn enough to move
    forward on their own.
    David Mark, Apr 28, 2009
    #5
  6. Jeremy J Starcher

    David Mark Guest

    kangax wrote:
    > David Mark wrote:
    > > On Apr 28, 1:23 pm, Jeremy J Starcher <> wrote:
    > >> On Tue, 28 Apr 2009 10:12:23 -0700, David Mark wrote:
    > >>> On Apr 27, 3:24 pm, Jeremy J Starcher <> wrote:
    > >>>> Ah, I know that David's "My Library" used a number of ideas from CWR
    > >>>> but it looks like he added a lot to it as well. I didn't realize that
    > >>>> Fork used the ideas to, but I should have.
    > >>> Fork predates CWR. Most of CWR ended up in My Library, but most of My
    > >>> Library is not CWR (it became defunct soon after I started my project.)
    > >> It was your "My Library" [my grammar checker is going to love that] that
    > >> got me looking for CWR. I was, uh, looking for code to recommend to
    > >> someone that was free of legal encumbrance.

    > >
    > > The only recommendation I would make regarding that project is to
    > > learn from it. The first lesson is that a general-purpose script is a
    > > bad idea. There are silly mistakes to be found (some documented in

    >
    > That probably depends on how one defines a general-purpose script.
    > Undoubtedly, a general purpose solution will always be less efficient
    > than a specific one. Nevertheless, I don't see how a collection of
    > low-level helpers (if such collection falls under the definition of
    > "general-purpose script") is a bad idea. Various getElement(s)?By*, XHR
    > and event handling wrappers, class manipulation, DOM traversal, etc. -
    > all come in useful when creating higher-level widgets.


    Sure. I meant general-purpose and monolithic (like Prototype, jQuery,
    etc.)

    >
    > Of course, even these low-level helpers are generic to a certain degree.
    > Should `hasClass` separate tokens based on /\s/ or
    > /[\\u0020\\u0009\\u000A\\u000C\\u000D]/? Should `getElementsByTagName`
    > wrapper take care of older IE not working with wildcard ("*")? Should
    > `getTextContent` take care of Safari 2.x ignoring text of hidden
    > elements? Should position-related helpers work in quirks mode?


    Yes, context is everything in browser scripting, which is why general-
    purpose scripts are generally a bad idea.

    >
    > Besides determining if a script must work in HTML/XHTML and
    > standards/quirks modes, it all seems to boil down to - a) which known


    Standards mode and HTML are a good starting point.

    > browsers it should support (i.e. explicitly taking care of known bugs in
    > their implementations), and b) which edge cases it should take care of.


    Yes, history must be taken into account (as well as the future.)

    >
    > Which mistakes are you talking about? I remember there were some
    > concerns in CWR threads about which properties should be tested and
    > which browsers should be supported.


    There's at least one silly bug in the Flash module (related to
    attributes of all things.) I just read some reports about IE8's
    handling of clip styles, which tells me that a couple of the effects
    will need updates. Certainly there are others.

    And remember, CWR was CWR in name only. It wasn't around long enough
    to recommend anything (and most of My Library was never in CWR.) Also
    realize that CWR and My Library date back to 2007 and strategies have
    evolved since. The browsers haven't changed, but best practices for
    cross-browser scripting certainly have.

    Of course, the clip issue could have been anticipated. Looking at the
    code today, it was obviously written with IE6/7 in mind. That was a
    stupid thing to do then and I must fix a line or two to deal with it
    now. I know where I went wrong and I know the logic that will put it
    right (for this and future versions of IE.) The browser developers
    are very easy to predict, especially the ones that work for MS.

    In contrast, libraries like jQuery are all about taking wrong turns
    and relying on unit tests to offer advice like dashboard GPS units.
    That is why they must be upgraded every time a new browser version is
    released (and why they cut the tethers to the old versions after a
    year or two.)
    David Mark, Apr 29, 2009
    #6
  7. Jeremy J Starcher

    David Mark Guest

    On Apr 29, 7:07 pm, Jeremy J Starcher <> wrote:
    > On Wed, 29 Apr 2009 14:33:39 -0700, David Mark wrote:
    > > And remember, CWR was CWR in name only. It wasn't around long enough to
    > > recommend anything (and most of My Library was never in CWR.)  Also
    > > realize that CWR and My Library date back to 2007 and strategies have
    > > evolved since.  The browsers haven't changed, but best practices for
    > > cross-browser scripting certainly have.

    >
    > True, true...
    >
    > However:  AFAIK, there isn't any nice list/book/example of what is
    > current best strategies and practices.


    There is at least one book coming, but I think there are good examples
    out there for virtually anything you can think of now. The first
    mistake is looking for everything in one nice package.

    >
    > Be sure to deregister any event handling before leaving the page to help


    Absolutely not. Do not create circular references involving host
    objects. Do not use libraries that insist on doing so when attaching
    events. Be sure to avoid the unload event like the plague. Always
    ask yourself, what wouldn't the libraries do?

    > avoid IE's memory-leaks.  Oh, unless you are on Firefox, in which case an
    > onpageunload causes Fx to invalidate its memory cache and slow down
    > backwards navigation.


    Fast history navigation is hardly exclusive to Firefox. If memory
    serves me correctly, MS came had it in IE2. Name a major browser that
    doesn't do it, provided you do *not* create unload listeners.

    >
    > Load scripts in the head.  Or, load them right before you close the
    > 'body' tag.  Or, load them dynamically to avoid them hanging the browser.


    Those are all context-sensitive decisions.

    >
    > Code your pages to degrade nicely on -any- browser and take all known
    > browser bugs into account .. even IE4 and NS4.  Except IE5 for the Mac. 
    > Nobody is using that one anyways -- and requires buying a Mac to test.


    You decide the cutoff for your site or app. You just have to know
    when to cut it off. Are you really worried about IE4 and NS4? NS4
    has no document.body. That is likely line one of the first tests for
    a modern script. IE4 has no document.documentElement, which is also a
    no-brainer to test in a modern script. So those two are typically
    weeded out immediately. Think of IE5 Mac as ancient quasi-standard
    browser with unknown bugs. There's lots of those out there. You
    can't know all of their quirks and you can't code for all of their
    quirks. All you can do is follow standards, use sound practices, keep
    things simple as possible and test on as many agents as is feasible.

    And what are you saying? You should buy a Mac anyway!
    David Mark, Apr 30, 2009
    #7
  8. Jeremy J Starcher

    David Mark Guest

    On Apr 30, 9:31 am, kangax <> wrote:
    > David Mark wrote:
    >
    > > kangax wrote:
    > >> David Mark wrote:

    > [...]
    > >>> The only recommendation I would make regarding that project is to
    > >>> learn from it.  The first lesson is that a general-purpose script is a
    > >>> bad idea.  There are silly mistakes to be found (some documented in
    > >> That probably depends on how one defines a general-purpose script.
    > >> Undoubtedly, a general purpose solution will always be less efficient
    > >> than a specific one. Nevertheless, I don't see how a collection of
    > >> low-level helpers (if such collection falls under the definition of
    > >> "general-purpose script") is a bad idea. Various getElement(s)?By*, XHR
    > >> and event handling wrappers, class manipulation, DOM traversal, etc. -
    > >> all come in useful when creating higher-level widgets.

    >
    > > Sure.  I meant general-purpose and monolithic (like Prototype, jQuery,
    > > etc.)

    >
    > It's good to see some of the JS libraries, like YUI, realize that
    > modular approach is the sanest way to go. Now if only they didn't sniff
    > in their DOM module
    > <http://github.com/yui/yui3/blob/0b9552b9cf1deb8b848b8b513d2a11fe43cb7...>


    And their event module. YUI is junk too. Just bigger (and more
    modular) junk.

    >
    > [...]
    >
    > >> Besides determining if a script must work in HTML/XHTML and
    > >> standards/quirks modes, it all seems to boil down to - a) which known

    >
    > > Standards mode and HTML are a good starting point.

    >
    > Absolutely.
    >
    > [...]
    >
    > >> Which mistakes are you talking about? I remember there were some
    > >> concerns in CWR threads about which properties should be tested and
    > >> which browsers should be supported.

    >
    > > There's at least one silly bug in the Flash module (related to
    > > attributes of all things.)  I just read some reports about IE8's
    > > handling of clip styles, which tells me that a couple of the effects
    > > will need updates.  Certainly there are others.

    >
    > I saw you posted a message in "My Library" group about "IE8 and clip"
    > but haven't had time to read it carefully yet.


    That one isn't a big deal. A couple of special effects may be down in
    IE8. Fix should be a couple of lines.

    >
    >
    >
    > > And remember, CWR was CWR in name only. It wasn't around long enough
    > > to recommend anything (and most of My Library was never in CWR.)  Also
    > > realize that CWR and My Library date back to 2007 and strategies have
    > > evolved since.  The browsers haven't changed, but best practices for
    > > cross-browser scripting certainly have.

    >
    > Glancing at the code quickly, I can see some mistakes in "Fork", but not
    > in "My Library" (except dependencies testing that I mentioned earlier
    > which appeared to be a non-issue).


    That's another issue with large scripts. It is hard to spot little
    mistakes. Trust me, there are some. I know I didn't patch the Flash
    module, so it is still fouling up the "class" attribute of the
    replacement OBJECT. That one is pretty silly, but I just don't have
    time to mess with My Library right now.

    >
    > It looks like back in '07 best practices already included solid
    > foundation of `isHost*` methods; nature of memory leaks in IE was
    > already researched well enough (to know that circular references should
    > be avoided); Which evolution are you talking about?


    Lots of little things. Using My Library as an example, it is too
    generalized, does too much to support ancient browsers, unnecessarily
    attaches an unload listener to fix memory leaks that are never
    created. Creates closures where none are needed, doesn't leverage QSA
    (there's a five minute project), doesn't leverage built-in transitions
    (except for IE), references getBoxObjectFor (thankfully not for
    anything important), some modules create expandos (e.g. query), etc.

    >
    >
    >
    > > Of course, the clip issue could have been anticipated.  Looking at the
    > > code today, it was obviously written with IE6/7 in mind.  That was a
    > > stupid thing to do then and I must fix a line or two to deal with it
    > > now.  I know where I went wrong and I know the logic that will put it
    > > right (for this and future versions of IE.)  The browser developers
    > > are very easy to predict, especially the ones that work for MS.

    >
    > > In contrast, libraries like jQuery are all about taking wrong turns
    > > and relying on unit tests to offer advice like dashboard GPS units.

    >
    > Unit tests is still an essential aspect of any serious
    > library/application. They are not meant as a guiding light for
    > trial-and-error development, of course; rather a way to maintain the
    > code safely and ensure system integrity.


    Yes, they are very important. I leave that stuff to others, getting
    involved only when things go wrong (thankfully that is rare.) That's
    one of the reasons I find jQuery evangelists so amusing. They do seem
    to spend a large percentage of their lives watching unit tests. They
    must see progress meters in their sleep.

    > Software tends to be changed
    > with time, sometimes changes need to be done fast and there's no time to
    > analyze how and what they affect. Unit tests simply allow for a more
    > efficient development (Of course, making a system decoupled and modular
    > helps to reduce risk greatly :))


    When I make a little change, it is nice to know that it is a little
    change. Modularity is key, but what is missing from scripts like My
    Library is interchangeability. As one of my clients mentioned
    recently, it would be nice to have another set of checkboxes to
    indicate the desired level of browser support. CWR started out as
    interchangeable functions and I just picked the level of support that
    I felt was best in 2007.
    David Mark, Apr 30, 2009
    #8
  9. In comp.lang.javascript message <E76Kl.15764$
    om>, Thu, 30 Apr 2009 00:18:44, Jeremy J Starcher <>
    posted:

    >Trouble is, this collected wisdom of c.l.js has never been distilled
    >down. The FAQ is a start, but we really need a "Things you don't even
    >know enough to ask" kind of thing.


    You will find some of those on my site, put there mainly as a result of
    demonstrated ignorance here. Of course, you will know them all already;
    but you will know them so well that you might not think to mention them.

    There could be a FAQ Note on the subject.

    The FAQ Notes would be more actually, as opposed to potentially, useful
    if the FAQ contained an index to the FAQ notes - the major entries from
    the TOC in the Notes.

    --
    (c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
    Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
    Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
    Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
    Dr J R Stockton, Apr 30, 2009
    #9
  10. Jeremy J Starcher

    David Mark Guest

    On Apr 29, 8:18 pm, Jeremy J Starcher <> wrote:
    > On Wed, 29 Apr 2009 16:25:07 -0700, David Mark wrote:
    > > On Apr 29, 7:07 pm, Jeremy J Starcher <> wrote:
    > > > However:  AFAIK, there isn't any nice list/book/example of what is
    > > > current best strategies and practices.

    > > There is at least one book coming, but I think there are good examples
    > > out there for virtually anything you can think of now.  The first
    > > mistake is looking for everything in one nice package.

    >
    > I look forward to the book.
    >
    > [ Snipped comments on de-registering event handlers ]
    >
    > You see, I know that and you know that .. but Jane Q. Public trying to
    > learn Javascript doesn't know that and there isn't a lot of c.l.js-
    > approved sites out there for them to learn from.  People are going to
    > learn from example and I was hoping that archived CWR would be part of
    > that example.
    >
    > > > Load scripts in the head.  Or, load them right before you close the
    > > > 'body' tag.  Or, load them dynamically to avoid them hanging the
    > > >  browser.

    > > Those are all context-sensitive decisions.

    >
    > ACK.
    >
    > > > Code your pages to degrade nicely on -any- browser and take all known
    > > > browser bugs into account .. even IE4 and NS4.  Except IE5 for the
    > > > Mac.  
    > > > Nobody is using that one anyways -- and requires buying a Mac to test..

    > > You decide the cutoff for your site or app.  You just have to know
    > > when to cut it off.  Are you really worried about IE4 and NS4?

    >
    > Me, no.  I don't worry about IE4 or NS4.  For most things I baseline test
    > to IE6  and make sure the fall back stuff works under IE 5.5.  I don't
    > even test under IE 5 all that often.
    >
    > However, there are corporate environments where testing is still for IE 4
    > because it got written into the specs and never removed.
    >
    > > NS4
    > > has no document.body.  That is likely line one of the first tests for
    > > a modern script.  IE4 has no document.documentElement, which is also a
    > > no-brainer to test in a modern script.  So those two are typically
    > > weeded out immediately.

    >
    > Full ACK.
    >
    > > Think of IE5 Mac as ancient quasi-standard
    > > browser with unknown bugs.  There's lots of those out there.  You
    > > can't know all of their quirks and you can't code for all of their
    > > quirks.  All you can do is follow standards, use sound practices, keep
    > > things simple as possible and test on as many agents as is feasible.

    >
    > I've never looked at or tested against IE5Mac, but from everything I've
    > heard, I have to agree with you there too.


    It's quite a piece of work. Doubtful that anyone uses it today as
    most "Ajax sites" would be unusable. You will hear users of libraries
    talking about "not worrying if their sites work with Mac IE" due to
    the magical compatibility properties of their chosen monolith, but
    they are definitely dreaming.

    >
    > Trouble is, this collected wisdom of c.l.js has never been distilled
    > down.  The FAQ is a start, but we really need a "Things you don't even
    > know enough to ask" kind of thing.
    >
    > Thats where my friend is, and what got me looking for the CWR archives.  
    > I am not looking at getting a full library for her, but I'd love to be
    > able to put together a good solid skeleton ... everything from the proper
    > 4.01 doctype to a solid addEvent solution.  A good feature test example
    > that she can add to as she needs.


    Add CSS files and you have a framework. The more coupling between the
    three the better (just be sure to document tne relationships.)

    And what makes you think that your friend needs an "addEvent
    solution?" If they are just starting out, do they really need more
    than one event per type per element? Tell them to start with the on*
    properties show them how to get the event target for delegation.

    >
    > > And what are you saying?  You should buy a Mac anyway!

    >
    > Oh, a Mac is on my list of things to buy but I have a half-dozen things
    > ahead of it on the priority scale.  Unless I'm willing to settle for an
    > oversized Mac laptop, I can't get one the proper Scottish way[1].


    I don't follow exactly.

    >
    > [1] Mugging the English.


    Do the English carry over-sized Macbooks exclusively?
    David Mark, May 1, 2009
    #10
  11. kangax wrote:
    > David Mark wrote:
    >>
    >> kangax wrote:
    >>> David Mark wrote:

    > [...]
    >>>> The only recommendation I would make regarding that project is to
    >>>> learn from it. The first lesson is that a general-purpose script is a
    >>>> bad idea. There are silly mistakes to be found (some documented in
    >>> That probably depends on how one defines a general-purpose script.
    >>> Undoubtedly, a general purpose solution will always be less efficient
    >>> than a specific one. Nevertheless, I don't see how a collection of
    >>> low-level helpers (if such collection falls under the definition of
    >>> "general-purpose script") is a bad idea. Various getElement(s)?By*, XHR
    >>> and event handling wrappers, class manipulation, DOM traversal, etc. -
    >>> all come in useful when creating higher-level widgets.

    >>
    >> Sure. I meant general-purpose and monolithic (like Prototype, jQuery,
    >> etc.)

    >
    > It's good to see some of the JS libraries, like YUI, realize that
    > modular approach is the sanest way to go. Now if only they didn't sniff
    > in their DOM module
    > <http://github.com/yui/yui3/blob/0b9552b9cf1deb8b848b8b513d2a11fe43cb7485/src/dom/js/dom.js>
    >


    I can find plenty of small nits in the code and some comments that I
    cannot believe to be true. The |create| method (where the odiferous
    sniffing takes place) seems to have some mistakes in part of it.

    I can't get the tests to run from that download. "YAHOO is not defined."

    Running:-

    /<yui3>/src/dom/tests/dom.html

    - is see the error:-

    YAHOO is not defined
    (?)()(Object config=Object Env=Object version=test)dom.html (line 95)
    onComplete()()yui.js (line 408)
    use()()yui.js (line 472)
    dom.html()()dom.html (line 94)
    [Break on this error] tool = YAHOO.tool,
    dom.html (line 95

    I want to run the tests for the |create| method.


    [...]

    > Unit tests is still an essential aspect of any serious
    > library/application. They are not meant as a guiding light for
    > trial-and-error development, of course; rather a way to maintain the
    > code safely and ensure system integrity. Software tends to be changed
    > with time, sometimes changes need to be done fast and there's no time to
    > analyze how and what they affect. Unit tests simply allow for a more
    > efficient development (Of course, making a system decoupled and modular
    > helps to reduce risk greatly :))
    >
    > [...]
    >


    Having a solid test suite takes a lot of risk out of refactoring, and in
    any software project, refactoring is very important (requirement changes
    dictate code changes, mistakes are found in existing code, etc).

    The code design evolves as the requirements evolve. Methods might need
    to get moved or broken into smaller routines up as they become more
    complex. ADTs ("classes", in the general sense) get created, removed,
    replaced, etc.

    If the design is not changed as requirements change, it can get so bad
    that it seems more attractive to start over with a new codebase.

    The time saved is not just in easing a requirements change; it's the QA,
    bugs, regression bugs, and bug scrub meetings. That takes everyone's
    time and can tend to get more people spending their time blaming the
    developer.

    Having proof that something works can be helpful when no bugs are found
    in that piece of suspect code; because it can lead to looking elsewhere
    for cause of the problem.

    (I've also found plenty of my own bugs in testing).
    </soapbox>

    I found the biggest downside to testing was setting it up and learning
    how to do it.

    Garrett
    Garrett Smith, May 4, 2009
    #11
  12. Dr J R Stockton wrote:
    > In comp.lang.javascript message <E76Kl.15764$
    > om>, Thu, 30 Apr 2009 00:18:44, Jeremy J Starcher <>
    > posted:
    >
    >> Trouble is, this collected wisdom of c.l.js has never been distilled
    >> down. The FAQ is a start, but we really need a "Things you don't even
    >> know enough to ask" kind of thing.

    >
    > You will find some of those on my site, put there mainly as a result of
    > demonstrated ignorance here. Of course, you will know them all already;
    > but you will know them so well that you might not think to mention them.
    >
    > There could be a FAQ Note on the subject.
    >
    > The FAQ Notes would be more actually, as opposed to potentially, useful
    > if the FAQ contained an index to the FAQ notes - the major entries from
    > the TOC in the Notes.
    >


    I am not quite sure what you mean: "it would be useful if the FAQ
    contained an index to the FAQ notes." Are you suggesting placing the
    entire index page for the notes? But then "the major entries from the
    TOC in the Notes" seems to suggest the reverse -- adding an index to the
    FAQ within the notes document.

    The FAQ contains links to the notes where relevant to the question at
    hand. The FAQ also links to the notes very near the top of the document,
    in "What questions are on-topic for comp.lang.javascript?" and "Why was
    my post not answered?" questions

    One thing that has come up a few times is the URI for the notes is long
    and unmemorable. The path is something like:-

    /faq/faq_notes/faq_notes.html

    - but should instead be:-

    /faq/notes/

    (using default index page).

    To do this, the links would need to be updated, in those documents. An
    http redirect could be set up for the old faq_notes/ paths.

    Richard Cornford has permissions for the "notes" documents.

    Garrett
    Garrett Smith, May 6, 2009
    #12
  13. In comp.lang.javascript message <gtsjrq$3qt$>, Wed,
    6 May 2009 11:11:03, Garrett Smith <> posted:
    >Dr J R Stockton wrote:


    >> The FAQ Notes would be more actually, as opposed to potentially,
    >>useful
    >> if the FAQ contained an index to the FAQ notes - the major entries from
    >> the TOC in the Notes.
    >>

    >
    >I am not quite sure what you mean: "it would be useful if the FAQ
    >contained an index to the FAQ notes." Are you suggesting placing the
    >entire index page for the notes?


    No, that would be "the index" rather than "an index".

    > But then "the major entries from the TOC in the Notes" seems to
    >suggest the reverse -- adding an index to the FAQ within the notes
    >document.


    No, that's grammatically a further detail.

    Take the source of the UL in "Index of /faq/faq_notes" at <http://www.ji
    bbering.com/faq/faq_notes/>, replace the visual aspect (shown next) of
    each link with the H1 of the page that it links to (e.g. "Javascript
    Closures"), and perform any necessary adjustments (omit "Parent
    Directory" and "faq_notes.css", re-order, etc.). Perhaps add to the
    visible text the number of the FAQ section.

    * Parent Directory
    * alt_dynwrite.html
    * clj_posts.html
    * cljs_charter.html
    * closures.html
    * contributors.html
    * cookies.html
    * faqNotes.zip
    * faq_notes.css
    * faq_notes.html
    * form_access.html
    * misc.html
    * not_browser_detect.html
    * pots1.html
    * script_tags.html
    * square_brackets.html
    * type_convert.html


    Alternatively, which is how I was earlier thinking of doing it, take the
    ToC in faq_notes.html#toc but retain only "Introduction", the numbered
    top-level list entries, and all after "Miscellaneous". The results
    should be much the same.

    Make it FAQ section 1.5. It would then be easier to find the Notes than
    as ...

    >The FAQ contains links to the notes where relevant to the question at
    >hand. The FAQ also links to the notes very near the top of the
    >document, in "What questions are on-topic for comp.lang.javascript?"
    >and "Why was my post not answered?" questions




    >One thing that has come up a few times is the URI for the notes is long
    >and unmemorable. The path is something like:-
    >
    >/faq/faq_notes/faq_notes.html
    >
    >- but should instead be:-
    >
    >/faq/notes/
    >
    >(using default index page).
    >
    >To do this, the links would need to be updated, in those documents. An
    >http redirect could be set up for the old faq_notes/ paths.



    In earlier discussions in this group, it was agreed that routine
    references to the FAQ, for example in FAQ 1.4, should use the full form,
    independent of short cuts, defaults, etc. "http://www.jibbering.com/faq
    /index.html" *looks* complete. The same should apply to the Notes, and
    to the Regular Postings.

    It seems likely that putting all the Notes material in
    http://www.jibbering.com/faq/faq_notes/ makes access control easier.

    /faq/faq_notes/faq_notes.html looks a bit silly because faq_notes is
    repeated - rename the file to index.html.


    Suggestions for making my $seq.htm faster would be of
    interest; I really want to be able to put 5.8e6 in the
    first window and have a run-time of less than 12 hours
    (FF3, "busy" warning OFF (about:config to re-enable))
    or Chrome.

    --
    (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
    Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
    PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
    Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
    Dr J R Stockton, May 7, 2009
    #13
    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. Peter Michaux
    Replies:
    45
    Views:
    376
    Peter Michaux
    Dec 7, 2007
  2. Peter Michaux
    Replies:
    16
    Views:
    234
    Peter Michaux
    Nov 26, 2007
  3. David Mark
    Replies:
    152
    Views:
    808
  4. David Mark

    isFunction (Code Worth Recommending Project)

    David Mark, Dec 8, 2007, in forum: Javascript
    Replies:
    25
    Views:
    229
    Peter Michaux
    Dec 12, 2007
  5. Peter Michaux
    Replies:
    0
    Views:
    149
    Peter Michaux
    Dec 13, 2007
Loading...

Share This Page