IE6 won't hide dynamically created span elements

Discussion in 'Javascript' started by Nicholas Couch, Sep 17, 2004.

  1. I have a little form with a couple of dynamically generated list
    boxes. When the user makes a selection from the first box, the second
    box is refreshed. When they make a selection from the second box, I
    concatenate the selections from the two boxes and add the string to a
    list at the top of the form, using createElement and appendChild. The
    list is actually a bunch of span elements contained within a div. Each
    span element includes a small graphic of a red X, which the user can
    click to delete that item from the list.

    All of this works just fine in Mozilla and Opera, but - wait for it -
    the delete functionality fails in IE, throwing an "Object Required"
    error on this line:

    this.style = document.getElementById(nm).style;

    where nm is the ID of the span element I'm trying to hide, by setting
    it's display property to "none."

    What's really interesting is the fact that I have one or more span
    elements in that div when the form first loads, and IE will hide these
    HTML-based elements without complaining. It's only the spans that I
    generate on the fly that it has a problem hiding.

    Must be something wrong with the way I'm creating those dynamic spans,
    you say? Maybe so, but IE does display them okay, and the code all
    works great in the other two browsers. Now I'm no javascript veteran,
    by any means, but this appears to me to be a bug in IE. What I asking
    here is whether anybody knows of a workaround for this, or maybe a
    better way of accomplishing what I'm trying to do.

    Thanks in advance,
    Blake Couch
    Javascript Noob
     
    Nicholas Couch, Sep 17, 2004
    #1
    1. Advertising

  2. Nicholas Couch wrote:


    > this.style = document.getElementById(nm).style;


    That should be 'nm' ...

    this.style = document.getElementById('nm').style;

    I can only guess that's your problem without actually looking at the code.
     
    john henry bonham, Sep 17, 2004
    #2
    1. Advertising

  3. Nicholas Couch

    Fred Oz Guest

    Nicholas Couch wrote:
    [snip]
    > All of this works just fine in Mozilla and Opera, but - wait for it -
    > the delete functionality fails in IE, throwing an "Object Required"
    > error on this line:
    >
    > this.style = document.getElementById(nm).style;
    >
    > where nm is the ID of the span element I'm trying to hide, by setting
    > it's display property to "none."

    [snip]

    You could try putting your elements inside <div> rather than
    <span> - I think the effect is the same and you have much more
    functionality available from divs. Try something like:

    divRef.style.display='none';

    where divRef is a reference to the div you want to hide.

    I tried the above, it worked fine in Safari and IE 5.2 on
    Mac - no guarantee for IE on Windows but I have done a similar
    thing for Windows using divs and it works fine.

    Cheers, Rob
     
    Fred Oz, Sep 17, 2004
    #3
  4. Nicholas Couch wrote:
    <snip>
    > Must be something wrong with the way I'm creating those
    > dynamic spans, you say?


    Yes.

    > Maybe so, but IE does display them okay, and the
    > code all works great in the other two browsers.


    So it is not 100% faulty.

    > Now I'm no javascript veteran, by any means,


    Obviously, as it doesn't take much experience to work out that in order
    to debug code people need to be able to see it.

    > but this appears to me to be a bug in IE.


    What, a web browser with a bug? ;)

    > What I asking here is whether anybody knows of
    > a workaround for this,


    It probably doesn't need a workaround. Cross browser code would probably
    suffice.

    > or maybe a better way
    > of accomplishing what I'm trying to do.


    What you are trying to do (at least claming that you are trying to do)
    works successfully in IE browsers.

    Richard.
     
    Richard Cornford, Sep 17, 2004
    #4
  5. Fred Oz <> wrote in message news:<414aa137$0$24385$>...
    > Nicholas Couch wrote:
    > [snip]
    > > All of this works just fine in Mozilla and Opera, but - wait for it -
    > > the delete functionality fails in IE, throwing an "Object Required"
    > > error on this line:
    > >
    > > this.style = document.getElementById(nm).style;
    > >
    > > where nm is the ID of the span element I'm trying to hide, by setting
    > > it's display property to "none."

    > [snip]
    >
    > You could try putting your elements inside <div> rather than
    > <span> - I think the effect is the same and you have much more
    > functionality available from divs. Try something like:
    >
    > divRef.style.display='none';
    >
    > where divRef is a reference to the div you want to hide.
    >
    > I tried the above, it worked fine in Safari and IE 5.2 on
    > Mac - no guarantee for IE on Windows but I have done a similar
    > thing for Windows using divs and it works fine.
    >
    > Cheers, Rob



    Thanks for the suggestion, but I've actually tried all sorts of
    combinations of elements - spans inside a div, divs inside a span,
    divs inside another div, paragraphs, you name it. The spans are what I
    really want to use, for cosmetic reasons.

    It always comes back to the same thing: it's the dynamically generated
    elements that IE chokes on, no matter what type they are. It's like
    those objects are not getting registered somehow, even though they
    display okay.

    Thanks again,
    BC
     
    Nicholas Couch, Sep 17, 2004
    #5
  6. Richard -

    I didn't post my code because it's pretty clear that IE, not my code, is
    the problem. I'm pretty sure that I am indeed using cross-browser DOM1
    code, and as I already said, it all works great in at least two other
    browsers. What I was hoping to find was a response from someone who has
    run up against the same bug in IE and found a workaround, but since you
    seem to be so keen on seeing the code, here it is:

    function positionChange()
    {
    var b = document.form1.baseSelect;
    var posSel = document.form1.positionSelect;
    var base = b.options[b.selectedIndex].text
    var p = posSel.options[posSel.selectedIndex].text
    var v = posSel.options[posSel.selectedIndex].value;
    var newElem = "span";
    // here's where we create a new element under the "prefs" element
    // first we get a reference to prefs
    var pr = new getObj("prefs");
    // then we create a new element
    var newel = document.createElement(newElem);
    // finally, append the new element to the prefs element
    pr.obj.appendChild(newel);
    // ???
    newel.setAttribute("ID", "pref" + v);
    newel.setAttribute("style", "display:block;");
    // create an anchor element for the new element
    var an = document.createElement("a");
    // append the anchor to the new element
    newel.appendChild(an);
    an.setAttribute("href", "javascript:drop_pref(\"pref" + v + "\")");
    an.setAttribute("title", "delete");
    // create a new IMG element to go with the anchor
    var newimg = document.createElement("img");
    // append the image to the anchor
    an.appendChild(newimg);
    newimg.setAttribute("src", "/common/images/delete_small.gif");
    newimg.setAttribute("border", "0");
    newimg.setAttribute("alt", "delete");
    // create a TextNode element for the new element and append it
    var txt = document.createTextNode(" " + base + " - " + p);
    newel.appendChild(txt);
    // create a line break and append that
    var br = document.createElement("br");
    newel.appendChild(br);
    }

    function drop_pref(id)
    {
    var x = new getObj(id);
    // alert("display = " + x.style.display);
    x.style.display = 'none';
    }

    function getObj(nm)
    {
    if (document.getElementById)
    {
    this.obj = document.getElementById(nm);
    this.style = document.getElementById(nm).style;
    }
    else if (document.layers)
    {
    this.obj = document.layers(nm);
    this.style = document.layers(nm);
    // "old" Netscape
    }
    else if (document.all)
    {
    this.obj = document.all(nm);
    this.style = document.all(nm).style;
    // old IE
    }
    }

    I appreciate any insight you can give on this problem.

    Thanks,
    BC


    *** Sent via Developersdex http://www.developersdex.com ***
    Don't just participate in USENET...get rewarded for it!
     
    Nicholas Couch, Sep 17, 2004
    #6
  7. Nicholas Couch wrote:
    > Richard -
    >
    > I didn't post my code because it's pretty clear that IE,
    > not my code, is the problem.


    And as you cannot change IE you therefor could not solve your problem by
    changing your code.

    > I'm pretty sure that I am indeed using cross-browser
    > DOM1 code,


    DOM 1 code is not necessarily cross-browser (even cross-DOM 1 supporting
    browsers).

    > and as I already said, it all works great in at least two
    > other browsers. What I was hoping to find was a response
    > from someone who has run up against the same bug in IE
    > and found a workaround,


    Without being able to see the code it is not possible to know which
    bug/feature of IE you have run up against (all browsers have bugs and
    features, usually lot of them).

    > but since you seem to be so keen on seeing the code, here
    > it is:
    >

    <snip>
    > newel.setAttribute("ID", "pref" + v);

    ^^
    Code == quick and painless answer!

    When creating elements dynamically, instead of using setAttribute,to set
    HTMLElement properties listed in the HTML DOM it is advisable to set the
    corresponding object properties directly. In this case the - id -
    property of the new span element:-

    newel.id = ("pref" + v);

    - the resulting code works with all HTML DOM browsers.

    If you insist on using setAttribute then it is necessary to use
    attribute names in the form that IE understands them, thus exactly the
    same mixed case strings as are found as named properties of IE's
    attributes collection. In this case IE will act on the setting of an
    "id" attribute if that attribute name is _all_ lowercase_. (But it is
    easier to set the properties directly.)

    <snip>
    > newel.appendChild(an);
    > an.setAttribute("href",
    > "javascript:drop_pref(\"pref" + v + "\")");

    <snip>

    Javascript pseudo-protocol HREFs are known troublemakers and should
    never be used in cross browser code. Instead, at this point you should
    assign a harmless - href - property (as it will never be acted upon '#'
    would do) and assign a navigation-cancelling onclick handler to the -
    onclick - property of the A element. Then you no longer need an ID
    attribute anyway as such an onclick handler can eliminate its containing
    span from the document with:-

    this.parentNode.parentNode.removeChild(this.parentNode);

    As could a similar event handler on <BUTTON> or <INPUT type="image">
    elements in the same context.

    Richard.
     
    Richard Cornford, Sep 17, 2004
    #7
  8. Well, Richard, you're absolutely right - I should have included my code
    in my first post. Changing the setAttribute calls to setting properties
    directly solved the problem. On the other hand, if IE didn't treat
    setAttribute in a non-standard way, I wouldn't have had this problem in
    the first place. I read in Danny Goodman's book that appendChild,
    setAttribute and the like are DOM1 _and_ supported by IE as of version
    5. If I had read closer, I would have seen his discussion of the way IE
    handles setAttribute. It supports those calls alright, but in its own
    peculiar way.

    One thing still puzzles me. When I try to set the display style of my
    new span with

    newel.style = "display:block;";

    IE throws a "member not found" error. At first I simply commented this
    line, and all was well. Then I changed it to read

    newel.style.display = "block";

    and that worked too, so I kept it. Now presumably the problem I was
    having before had to do with IE not finding the span object in its
    collection, or perhaps more precisely, not finding the style attribute
    of the span object. So does IE create the necessary style attribute if I
    fail to specify it myself, but not create it if I specify it in a way
    that doesn't conform to its interpretation of setAttribute? More
    importantly, does anybody care?

    Thanks,
    BC


    *** Sent via Developersdex http://www.developersdex.com ***
    Don't just participate in USENET...get rewarded for it!
     
    Nicholas Couch, Sep 17, 2004
    #8
  9. Nicholas Couch wrote:
    > Well, Richard, you're absolutely right - I should
    > have included my code in my first post.


    Yes you should, you would have had fixed code at least 4 hours sooner.
    As should all the other individuals posting questions to this group who
    don't know enough to appreciate that there are 50-odd ways of screwing
    most things up and that it is impossible to tell which actually applies
    without seeing the code and its context. (While we can all guess, and
    even guess correctly sometimes, it is frustrating to be being
    continually asked to guess when code is all that is needed for
    certantly.)

    <snip>
    > ... . I read in Danny Goodman's book ...

    <snip>

    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.

    <snip>
    > One thing still puzzles me. When I try to set the display
    > style of my new span with
    >
    > newel.style = "display:block;";


    The reason that I specifically stated that the properties that should be
    defined directly on the element instead of using setAttribute are the
    HTML attribute-corresponding properties defined in the _HTML_ DOM
    specification was that other attributes are handled differently. The -
    style - property of a DOM element (that implements the
    ElementCSSInlineStyle interface) refers to an object implementing the
    CSSStyleDeclaration interface from the W3C CSS DOM specification. Where
    it is defined as a read-only property (the - style - property of the
    element, not the CSSStyleDeclaration interface's properties).

    The ElementCSSInlineStyle interface is formalisation of behaviour
    originating in IE 4 and well supported in modern browsers. When an
    element is created it already has a - style - property that refers to an
    object, so it is best to set the properties of that object to the
    desired values (or to set the - className - property of the element
    itself, to have it acquire as set of style properties defined in CSS
    elsewhere).

    > IE throws a "member not found" error. At first I simply commented
    > this line, and all was well. Then I changed it to read
    >
    > newel.style.display = "block";
    >
    > and that worked too, so I kept it.


    Yes that works, but it is a bit illogical to create a SPAN element (the
    semantically neutral inline element intended for little more than the
    application of CSS) and then give it a "block" display property, when
    you could create a DIV element (the semantically neutral block element)
    and just let its display property default to "block" as normal.

    > Now presumably the problem I was having before
    > had to do with IE not finding the span object in its
    > collection, or perhaps more precisely, not finding


    > the style attribute of the span object. So does
    > IE create the necessary style attribute if I fail
    > to specify it myself,


    Any created element (at least on modern browsers) will have a - style -
    property from the moment of its creation, that represents the current
    state of its inline style, as an object with named properties.

    > but not create it if I specify it in a way that doesn't
    > conform to its interpretation of setAttribute? More
    > importantly, does anybody care?


    It is normal to set the properties related to inline style on the object
    provided not through the use of setAttribute('style' ,' ... ');

    Richard.
     
    Richard Cornford, Sep 17, 2004
    #9
  10. Richard Cornford wrote:
    >
    > <snip>
    >
    >>... . I read in Danny Goodman's book ...

    >
    > <snip>
    >
    > Danny Goodman's books are out of date and teach practices that are
    > positively harmful for cross-browser scripting.
    >
    > <snip>
    >


    Virtually any book in the computing field is likely to be out of date
    shortly after publication. I have the second edition of "Dynamic HTML,
    the Definitive Reference," published in 2002. I gather you would not
    consider it definitive, but is it really that out of date only two years
    later? What would be a better resource for a confessed javascript noob?

    BC





    *** Sent via Developersdex http://www.developersdex.com ***
    Don't just participate in USENET...get rewarded for it!
     
    Nicholas Couch, Sep 17, 2004
    #10
  11. On 17 Sep 2004 20:41:13 GMT, Nicholas Couch <> wrote:

    [snip]

    > Virtually any book in the computing field is likely to be out of date
    > shortly after publication. I have the second edition of "Dynamic HTML,
    > the Definitive Reference," published in 2002. I gather you would not
    > consider it definitive, but is it really that out of date only two years
    > later? What would be a better resource for a confessed javascript noob?


    It's not that Javascript books are out-of-date, but that they're simply
    bad in the first place. As Richard tends to point out in discussions such
    as this, the majority of book and Web authors don't understand the
    complexities of scripting[1], and the Web is worse-off for it. As such,
    there tends to be few resources that can be recommended, aside from a few
    choice articles on topics like the evils of browser detection.

    Personally, I can do little more than recommend reading the FAQ and it
    links, and continuing to read and ask questions in this group. It's not
    quite the self-enabling answer you were probably looking for, but I don't
    think there's much that can be about that with the current state of things.

    Mike

    <URL:http://jibbering.com/faq/>


    [1] I'd like to point out that I don't claim to, either. It's why I
    participate in this, and other, authoring groups. It's amazing to realise
    just how clueless one can be. :D

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
     
    Michael Winter, Sep 17, 2004
    #11
  12. Nicholas Couch

    Grant Wagner Guest

    Michael Winter wrote:

    > As Richard tends to point out in discussions such
    > as this, the majority of book and Web authors don't understand the
    > complexities of scripting[1], and the Web is worse-off for it.
    >
    > [1] I'd like to point out that I don't claim to, either. It's why I
    > participate in this, and other, authoring groups. It's amazing to realise
    > just how clueless one can be. :D


    The complexities of scripting are also the reason I hear "JavaScript sucks" so
    much. And I don't just hear it from developers, I also hear it from end-users
    who fail to understand it is not the technology that "sucks", but the
    particular style of scripting on the sites they are visiting. This badly
    written script is caused by the exact thing you mentioned, Web authors not
    understanding the complexities of the environment they are developing for.

    When they are approached and informed that something they have authored is not
    working on some combination of OS, browser, firewall and/or popup-blocking
    software, their first reaction is... you guessed it... "JavaScript sucks".
    Well, their first reaction might be "Windows sucks" or "IE sucks", or "Mac
    sucks" or "Mozilla sucks", but ultimately it comes down to blaming something
    other than their inability to understand that they do not control the
    environment in which their code is running, and as a result, extra care must be
    taken to ensure that when (not if) the code fails, it does so in a way that
    will not leave the visitor's browser crippled.

    As you said, I am still learning as well. I am lucky enough to do most of my
    work for an Intranet where I support only(!) Netscape 4.78, IE 5.5+, recent
    Gecko-based browsers and Opera 7. And I have the option of insisting that the
    user upgrade to a more recent Gecko variation or Opera 7 if they are running an
    older version which does not support some functionality which does not work
    properly.

    And even with this "controlled" environment, Windows XP Service Pack 2 revealed
    some weakly written client-side JavaScript which caused problems and had to be
    fixed.

    When people tell me writing client-side JavaScript isn't "real" programming, I
    just smile and resort to "if you say so". Then wait for them to have their
    first experience with "why doesn't formName.submit(); work in Mozilla!". :)

    --
    Grant Wagner <>
    comp.lang.javascript FAQ - http://jibbering.com/faq
     
    Grant Wagner, Sep 17, 2004
    #12
  13. Grant Wagner wrote:
    > Michael Winter wrote:
    >> As Richard tends to point out ...

    <snip>
    >> ... . It's amazing to realise
    >> just how clueless one can be. :D


    But very essential in any effort to become non-clueless.

    <snip>
    > When people tell me writing client-side JavaScript isn't
    > "real" programming, I just smile and resort to "if you say
    > so". ...

    <snip>

    Earlier today I noticed a job advert:-

    <URL: http://www.cwjobs.co.uk/JS/JobDetails.asp?JobID=12451782 >
    (That is unlikely to be a stable URL)

    Containing the line: "You will need a solid experience of Web
    Development generating HTML, Javascript, CSS and Graphics, ideally with
    some programming.". Obviously written by someone who actually believes
    they can hire someone to write javascript who doesn't necessarily know
    anything about programming. I can imagine the outcome :-(

    Richard.
     
    Richard Cornford, Sep 18, 2004
    #13
  14. I'd like to explore this a little further, and get a little more
    specific. The Goodman book to which I referred earlier is primarily a
    reference, covering DHTML, CSS, DOM, etc. It is not a tutorial per se.
    Would I be wrong to trust it as a reference? Is the information
    presented therein likely to be inaccurate, or as Richard suggested,
    out of date? Can anyone give me an example of an instance where the
    book is wrong?

    I'm quite serious about this. As I've already noted, I've not done a
    whole lot of Javascript programming previously (I've been programming
    in other languages for well over 20 years), but it looks like I may
    well be doing a lot of it in the foreseeable future. I don't want to
    get off on the wrong foot by relying on a lousy reference book.

    BC




    "Michael Winter" <> wrote in message news:<opsehqdvfxx13kvk@atlantis>...
    >
    > [snip]
    >
    > It's not that Javascript books are out-of-date, but that they're simply
    > bad in the first place.
    >
    > [snip]
    >
     
    Nicholas Couch, Sep 18, 2004
    #14
  15. Robert <> wrote in message news:<>...
    >
    > [snip]
    >
    > Or maybe it is this book: Dynamic HTML: The Definitive Reference, 2nd
    > Edition A Comprehensive Resource for HTML, CSS, DOM & JavaScript. This
    > contains a lot of reference information. I thought about buying it, but
    > if I recall right, it has a very broad coverage and contains a little
    > less coverage on the core javascript language than the book below.
    >
    > [snip]
    >


    Yes, that's the one I refer to in message 12 in this thread. I bought
    it precisely because I wanted a resource with broad coverage, and
    because I read several strong recommendations for it, on this
    newsgroup and elsewhere. Plus I already have a couple of books devoted
    primarily to javascript, including the O'Reilly/Flanagan book.

    The important thing, from my point of view, is to know whether or not
    I can rely
    on these or any other books as I try to increase my level of expertise
    in javascript programming. When regular and authoritative participants
    in this newsgroup tell me, essentially, that so-and-so's books are no
    good and that no Javascript books can be trusted, I'd like to know
    with specificity why that is so. It seems to me that when there's so
    much importance placed on conforming to a certain posting orthodoxy in
    this group, there ought to be just as much emphasis placed on
    substantiating one's opinion of the work of others in the field - in
    the interest of the common good, of course....

    BC
     
    Nicholas Couch, Sep 19, 2004
    #15
  16. Nicholas Couch wrote:
    > Robert wrote:
    >> Or maybe it is this book: Dynamic HTML: The Definitive
    >> Reference, 2nd Edition ...

    <snip>
    > Yes, that's the one I refer to in message 12 in this thread.
    > I bought it precisely because I wanted a resource with
    > broad coverage, and because I read several strong
    > recommendations for it, on this newsgroup and elsewhere.


    I have never seen a recommendation of any Danny Goodman book posted to
    this newsgroup in the last couple of years, strong or otherwise. At
    least by anyone worth paying any attention to, which is important as the
    only limitation on posting a recommendation of anything is having access
    to a new server or the internet (so not really a qualification in
    javascript in itself).

    > Plus I already have a couple of books devoted
    > primarily to javascript, including the O'Reilly/Flanagan book.
    >
    > The important thing, from my point of view, is to know
    > whether or not I can rely on these or any other books
    > as I try to increase my level of expertise in javascript
    > programming.


    Reference material published in books only needs to reproduce (often
    re-worded) the original sources (ECMA, W3C, Microsoft, Netscape, ect.)
    accurately in order to be useful. They can tell you what is out there,
    and what you can expect it to do where it is implemented. As will the
    original sources.

    Any book written in 2002 is going to have problems saying useful things
    about browser implementations. At the start of 2002 Netscape 7 and Opera
    7 did not exist, Mozilla has changed considerably over the intervening
    years (along with all the Gecko browsers) and books rarely even mention
    browsers such as IceBrowser (called IceStorm at the time) and NetFront.
    Unsurprisingly as most books take the "both browsers" attitude prevalent
    around the turn of the century, possibly making concessions for extreme
    changes made between Netscape 4 and 6.

    That is in fact the main problem with Danny Goodman's code. He tends to
    take the attitude that the browser executing his code will be one of a
    known set of browsers and never considers the consequences of a script
    encountering a browser outside of that set (that and applying some
    really clumsy techniques to dealing with even that limited set of
    browsers).

    In reality reference material for the object models is not a major issue
    in browser scripting, though it would be nice if some of the minor
    browsers published more specifics about their implementations). The real
    problem is in script design; designing for the consequences of failure
    of a browser to support a particular feature. It is that aspect of
    scripting that takes the effort to learn, and also the aspect most
    poorly addressed in existing javascript books.

    > When regular and authoritative participants in this newsgroup
    > tell me, essentially, that so-and-so's books are no good and
    > that no Javascript books can be trusted, I'd like to know
    > with specificity why that is so. It seems to me that when
    > there's so much importance placed on conforming to a certain
    > posting orthodoxy in this group, there ought to be just as
    > much emphasis placed on substantiating one's opinion of the
    > work of others in the field - in the interest of the common
    > good, of course....


    The section of the FAQ on javascript books says just about all that
    needs saying on the subject. None of the regulars on this group are
    willing to endorse any book other than David Flanagan's and even that
    was following a debate on the subject and the expression of misgivings.

    Of the last two newly published javascript books I have looked at, one
    was written apparently without an appreciation that javascript is quite
    unlike Java, and so was filled with clear factual errors (that would
    mostly have been true of Java), and the second (featuring "advanced" in
    the title) expounded methods so poor that their use would be somewhere
    between stupid and disastrous.

    Richard.
     
    Richard Cornford, Sep 19, 2004
    #16
  17. On Sun, 19 Sep 2004 14:25:27 -0600, Richard Cornford wrote:
    > I have never seen a recommendation of any Danny Goodman book posted to
    > this newsgroup in the last couple of years, strong or otherwise. At
    > least by anyone worth paying any attention to, which is important as


    Well, that's part of the problem, isn't it? How is one to judge, unless
    one regularly spends time reading the group? I spent a few hours the other
    day, before I made my original post, searching via Google Groups, looking
    for posts that might give me a clue as to a solution to the problem I was
    experiencing. I saw many posts by yourself, Andrew Thompson, Michael
    Winter, Martin Honnen, Randy Webb, Fred Oz, Lasse Reichstein Nielsen,
    Thomas 'PointedEars' Lahn, Grant Wagner, and a host of others. During that
    brief period I became aware that there are certain regular participants in
    the group who are considered purveyors of bad advice, but I wasn't looking
    for any depth of understanding of your particular subculture on the
    internet. I was looking for a solution to a very specific programming
    problem. In the process I ran across at least two or three recommendations
    for Goodman's DHTML book, which I considered valuable in the absence of
    any recommendations to the contrary. I don't recall how old those posts
    were, and they may not even have been from this group, now that I think
    about it, but anything is better than nothing, usually.


    > The section of the FAQ on javascript books says just about all that
    > needs saying on the subject. None of the regulars on this group are
    > willing to endorse any book other than David Flanagan's and even that
    > was following a debate on the subject and the expression of misgivings.


    I have to disagree, with that "just about all that needs saying" bit. It
    may be enough for the regular participants here, because you know each
    other's judgement, presumably, but as an outsider there are lots of
    alternative conclusions I could draw from the fact that there's only one
    book in existence you can all agree on, even grudgingly, as valuable.
    Nothing personal, Richard, but there are a lot of cranks on usenet.

    At any rate, I appreciate your taking the time to respond here in more
    detail, and I appreciate the efforts of everyone else who posted on this
    thread. I certainly know a whole lot more than I did before I started
    this, and that's what it's all about.

    BC
     
    Nicholas Couch, Sep 20, 2004
    #17
  18. JRS: In article <>,
    dated Sun, 19 Sep 2004 10:01:49, seen in news:comp.lang.javascript,
    Nicholas Couch <> posted :
    >
    >Yes, that's the one I refer to in message 12 in this thread.


    The articles in a thread are not globally numbered.

    They may arrive in different servers in different orders; they are
    differently displayed by different newsreaders; readers need show no
    number. So it is not sound to refer to them by a sequence number.

    The Message-ID, in the header, provides a reference which should be
    perpetually unique over all newsgroups; "My message, Date: 17 Sep 2004
    20:41:13 GMT", is good enough for the present purpose.

    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
    Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
    Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
    No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
     
    Dr John Stockton, Sep 20, 2004
    #18
  19. JRS: In article <>, dated Tue,
    21 Sep 2004 08:30:35, seen in news:comp.lang.javascript, Andrew Thompson
    <> posted :
    >On Mon, 20 Sep 2004 11:45:43 +0100, Dr John Stockton wrote:
    >
    >(Usenet posts)
    >> They may arrive in different servers in different orders; they are
    >> differently displayed by different newsreaders; readers need show no
    >> number. So it is not sound to refer to them by a sequence number.

    >
    >As an aside, I often provide links to the Google archives
    >that take the form http://google.com/groups?th=2123446#9
    >(a totally false URL), in preferecne to using the single,
    >much longer 'selm; parameter.



    But those with off-line news readers do not have immediate access to web
    services; but, if it is a good newsreader, it will have retained earlier
    articles in the thread, and one can find them given date & time or
    Message-ID.

    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
    Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
    Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
    No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
     
    Dr John Stockton, Sep 21, 2004
    #19
  20. On Wed, 22 Sep 2004 07:20:06 GMT, Andrew Thompson <>
    wrote:

    [snip]

    > Excuse me for being dense (shrugs, or not, as you wish)
    > but is the 'Message-ID' equivalent to the 'selm' parameter
    > as used by Google. (I suspect that is what it is, but am
    > unsure)


    Yes, it is.

    My last post in this thread (to Nicholas Couch, Friday 21:37 GMT) as the
    following Google URL:

    <URL:http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=opsehqdvfxx13kvk%40atlantis>

    If you check the headers of that post, you'll see:

    Message-ID: <opsehqdvfxx13kvk@atlantis>

    URL-encoded, it's the same as the selm parameter (though it is missing the
    angle brackets).

    Mike

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
     
    Michael Winter, Sep 22, 2004
    #20
    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. Fulio Open

    Can span include span?

    Fulio Open, Jun 26, 2009, in forum: HTML
    Replies:
    5
    Views:
    552
    dorayme
    Jun 26, 2009
  2. msimmons
    Replies:
    0
    Views:
    497
    msimmons
    Jul 16, 2009
  3. Stéphane Klein
    Replies:
    2
    Views:
    1,768
    John Nagle
    Mar 30, 2010
  4. Stefan Behnel
    Replies:
    0
    Views:
    489
    Stefan Behnel
    Mar 29, 2010
  5. Dan Bishop

    DataGrid (body only) contained in <span>...</span> tags

    Dan Bishop, Jun 7, 2004, in forum: ASP .Net Datagrid Control
    Replies:
    2
    Views:
    280
    Kilic Beg
    Jun 7, 2004
Loading...

Share This Page