Simple script works in Firefox but not IE7

Discussion in 'Javascript' started by garey, Apr 28, 2009.

  1. garey

    garey Guest

    Hi -

    I am trying to write some Javascript that will move both buttons
    and selects from far left of the viewport into and out of the
    viewport. I present a button that moves in another button. The second
    button moves in a select.

    All of this works in Firefox. Moving the button in and out works
    in IE7, but moving in the select does not, despite the exact same code
    being used in both cases. The code is below. Note that I added the
    "min-height: 0" style statement to the style because I thought that
    this might be a Microsoft "layout" problem, but setting min-height
    did not affect the problem.

    Any help appreciated;

    Garey Mills

    <html>
    <head>
    <style type="text/css">

    div.extraout { position: absolute; left: -9999em; min-height: 0 }

    </style>

    <script language="JavaScript">

    function ucbmoveIn(name) {

    var elem = document.getElementById(name);
    elem.style.position = "static";

    }

    function ucbmoveOut(name) {

    var elem = document.getElementById(name);
    elem.style.position = "absolute";

    }

    </script>
    </head>

    <body>

    <button name="more" value="more" onClick='ucbmoveIn("l");return
    false;'>More</button>

    <div class="extraout" id="l">
    <table>
    <tr>
    <td><button name="a" value="a" onClick='ucbmoveIn("a");return
    false;'>A</button></td>
    </tr>
    </table>
    <button name="less" value="less" onClick='ucbmoveOut("l");return
    false;'>Hide</button>
    </div>

    <div class="extraout" id="a">
    <tr><td>As</td><td>

    <select name="lA" id="lA" size="10" multiple="multiple">
    <option value="ach">acholi</option>
    <option value="ada">adangme</option>
    <option value="afh">afrihili</option>
    </select>
    </td></tr></table>
    <button name="hideAs" value="hideAs" onClick='ucbmoveOut("a");return
    false;'>Hide</button>
    </div>

    </body>
    </html>
     
    garey, Apr 28, 2009
    #1
    1. Advertising

  2. garey wrote:
    > I am trying to write some Javascript that will move both buttons
    > and selects from far left of the viewport into and out of the
    > viewport. I present a button that moves in another button. The second
    > button moves in a select.
    >
    > All of this works in Firefox. Moving the button in and out works
    > in IE7, but moving in the select does not, despite the exact same code
    > being used in both cases. The code is below. Note that I added the
    > "min-height: 0" style statement to the style because I thought that
    > this might be a Microsoft "layout" problem, but setting min-height
    > did not affect the problem.
    >
    > Any help appreciated;
    >
    > Garey Mills
    >
    > <html>


    Not Valid.

    > <head>
    > <style type="text/css">
    >
    > div.extraout { position: absolute; left: -9999em; min-height: 0 }


    Smart people hide the element instead of placing it in CSS hell.

    > </style>
    >
    > <script language="JavaScript">


    Not Valid. HTML 4.01 and the `type' attribute turn 10 years this December;
    amazing how long such obsolete nonsense as above keeps floating around the Web.

    <http://validator.w3.org/>

    > function ucbmoveIn(name) {
    >
    > var elem = document.getElementById(name);


    The feature test is missing. RTFM, RTFFAQ, STFW.

    > elem.style.position = "static";


    "static" is the default value. Had you not mindlessly moved the element
    beyond good and evil in the first place, that operation would have been
    unnecessary.

    >
    > }
    >
    > function ucbmoveOut(name) {
    >
    > var elem = document.getElementById(name);


    See above.

    > elem.style.position = "absolute";


    No.

    > }
    >
    > </script>
    > </head>
    >
    > <body>
    >
    > <button name="more" value="more" onClick='ucbmoveIn("l");return
    > false;'>More</button>


    The less compatible `button' element is unnecessary here, a (dynamically
    generated) input[type="button"] suffices.

    > <div class="extraout" id="l">


    Very self-explaining ID, really.

    > <table>
    > <tr>
    > <td><button name="a" value="a" onClick='ucbmoveIn("a");return
    > false;'>A</button></td>


    See above.

    > </tr>
    > </table>


    You don't need this table at all. Learn HTML and CSS before you try to
    learn JS.

    > <button name="less" value="less" onClick='ucbmoveOut("l");return
    > false;'>Hide</button>


    See above. Forget about `return false'; use type="button" instead and
    generate this dynamically. (Did anyone tell you already that you should
    learn HTML before you try to learn JS?)

    > </div>
    >
    > <div class="extraout" id="a">


    See above.

    > <tr><td>As</td><td>


    Not Valid. There is no table for this table row as the one table in the
    document ended well before this line.

    > <select name="lA" id="lA" size="10" multiple="multiple">


    See above. Besides, this isn't XHTML, is it? HTML UAs tend to choke on
    this boolean syntax, even though SGML allows it. RTFM.

    > [...]
    > </td></tr></table>
    > <button name="hideAs" value="hideAs" onClick='ucbmoveOut("a");return
    > false;'>Hide</button>


    See above.


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

  3. garey

    Eric Bednarz Guest

    Thomas 'PointedEars' Lahn <> writes:

    >> <select name="lA" id="lA" size="10" multiple="multiple">

    >
    > See above. Besides, this isn't XHTML, is it?


    Why would that matter?

    > HTML UAs tend to choke on this


    That’s a nice bunch of weasel words.

    > boolean syntax,


    Come again?

    > even though SGML allows it.


    I withdraw my first question.

    You seem to know that HTML UAs don’t have any SGML capabilities. Please
    explain all those URI references to the W3C validation service to
    confirm compliance with a validating SGML system.

    > RTFM.


    Or STFW if you are too cheap to buy the manual that actually matters if
    you want to discuss esoterica.
     
    Eric Bednarz, Apr 30, 2009
    #3
  4. Eric Bednarz wrote:
    > Thomas 'PointedEars' Lahn <> writes:
    >>> <select name="lA" id="lA" size="10" multiple="multiple">

    >> See above. Besides, this isn't XHTML, is it?

    >
    > Why would that matter?


    In XHTML this is required; in HTML this is recommended against.

    >> HTML UAs tend to choke on this

    >
    > That’s a nice bunch of weasel words.
    >
    >> boolean syntax,

    >
    > Come again?
    >
    >> even though SGML allows it.

    >
    > I withdraw my first question.
    >
    > You seem to know that HTML UAs don’t have any SGML capabilities. Please
    > explain all those URI references to the W3C validation service to
    > confirm compliance with a validating SGML system.
    >
    >> RTFM.

    >
    > Or STFW if you are too cheap to buy the manual that actually matters if
    > you want to discuss esoterica.


    Idiot. <http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.4>

    <http://jibbering.com/faq/#posting>
    <http://www.catb.org/~esr/faqs/smart-questions.html#before>


    PointedEars
     
    Thomas 'PointedEars' Lahn, Apr 30, 2009
    #4
  5. kangax wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> garey wrote:
    >>> div.extraout { position: absolute; left: -9999em; min-height: 0 }

    >> Smart people hide the element instead of placing it in CSS hell.

    >
    > CSS hell? Please explain another way to "hide" an element in such way
    > that its content is "picked up" and pronounced by screen readers.


    No, because the whole thing is not accessible in the first place.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Apr 30, 2009
    #5
  6. garey

    David Mark Guest

    On Apr 30, 8:53 am, kangax <> wrote:
    > Thomas 'PointedEars' Lahn wrote:
    > > garey wrote:

    > [...]
    > >> div.extraout { position: absolute; left: -9999em; min-height: 0 }

    >
    > > Smart people hide the element instead of placing it in CSS hell.

    >
    > CSS hell? Please explain another way to "hide" an element in such way
    > that its content is "picked up" and pronounced by screen readers.


    If an element is hidden, you don't want it to be read by screen
    readers. If it is not hidden, you certainly don't want to place it
    off-screen so that only blind people will be aware of it.
     
    David Mark, Apr 30, 2009
    #6
  7. garey

    David Mark Guest

    On Apr 30, 12:47 pm, kangax <> wrote:
    > David Mark wrote:
    > > On Apr 30, 8:53 am, kangax <> wrote:
    > >> Thomas 'PointedEars' Lahn wrote:
    > >>> garey wrote:
    > >> [...]
    > >>>> div.extraout { position: absolute; left: -9999em; min-height: 0 }
    > >>> Smart people hide the element instead of placing it in CSS hell.
    > >> CSS hell? Please explain another way to "hide" an element in such way
    > >> that its content is "picked up" and pronounced by screen readers.

    >
    > > If an element is hidden, you don't want it to be read by screen
    > > readers.  If it is not hidden, you certainly don't want to place it
    > > off-screen so that only blind people will be aware of it.

    >
    > Most of the time not. But there are cases when information can be
    > perceived fully only visually and some additional content/explanation
    > needs to be presented to a screen reader. These cases are rare but they
    > do come up once in a while.


    Sure, there are exceptions. I've seen that strategy advocated as a
    replacement for hidden visibility though, which it clearly is not.

    >
    > I suppose this article explains it best (and features actual examples):
    >
    > <http://www.webaim.org/techniques/css/invisiblecontent/>


    No time at the moment, but beware of anything you find on the Web.
    Just as with JS, there are lots of people expressing lots of ideas
    about how to use CSS on the Web (and most of them are wrong.)

    >
    > --
    > kangax
     
    David Mark, Apr 30, 2009
    #7
  8. garey

    David Mark Guest

    On Apr 30, 8:13 pm, kangax <> wrote:
    > David Mark wrote:
    > > On Apr 30, 12:47 pm, kangax <> wrote:

    > [...]
    > >> I suppose this article explains it best (and features actual examples):

    >
    > >> <http://www.webaim.org/techniques/css/invisiblecontent/>

    >
    > > No time at the moment, but beware of anything you find on the Web.
    > > Just as with JS, there are lots of people expressing lots of ideas
    > > about how to use CSS on the Web (and most of them are wrong.)

    >
    > That's true; There's plenty of bizarre explanations and workarounds
    > floating around. WebAIM, on the other hand, is a quite respected
    > resource, as far as I know. If you have any objections to the material
    > from that article, I would be interested to hear them.


    I'll check it out when I get a chance.

    >
    > On a side note, it would be nice if the information one can find in this
    > newsgroup would get more attention on the web. Cornford's and


    More is always better when it comes to attention. Lots of
    misconceptions to clear up at this point.

    > Crockford's articles are good examples of spreading some of the
    > browser-scripting (or language, overall) techniques, as well as Peter
    > Michaux's blog (I think one of his feature detection -related articles
    > is how I found out about comp.lang.javascript in the first place).
    >
    > Some time ago, I made a naive attempt at releasing a set of examples of
    > some of the common feature tests one might stumble upon. The funny thing
    > is that when it got to Ajaxian, some people actually argued about
    > sniffing being "faster" and supposedly more superior.


    Ajaxian is a rag. And that must have been some time ago as I don't
    think anyone would argue for browser sniffing at this point.
     
    David Mark, May 1, 2009
    #8
  9. garey

    Eric Bednarz Guest

    Thomas 'PointedEars' Lahn <> writes:

    [multiple="multiple"]

    >>> RTFM.

    >>
    >> Or STFW if you are too cheap to buy the manual that actually matters if
    >> you want to discuss esoterica.

    >
    > Idiot.


    You are a pompous wannabe-hacker permanently stuck in adolescence.

    > <http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.4>


    If you wanna be pragmatic, the HTML 4.01 spec is ten years old, that
    section was already in the first HTML 4 spec that is eleven years old,
    and if you consider WG speed it is likely that this note is about the
    browser landscape twelve years ago or older. So this is supposed to back
    up your statement “HTML UAs tend to choke on this�

    If you wanna be dogmatic, there are no ‘boolean attributes’ in
    SGML. There’s attribute name omission for name token lists, and
    historically that was *the* reason to enable SHORTTAG in the quixotic
    attempt to retrofit HTML into an SGML application.
    So where’s the appendix note that explains how ‘boolean attributes’
    enable notation like
    <td justify>
    ? :)
     
    Eric Bednarz, May 1, 2009
    #9
  10. Eric Bednarz wrote:
    > Thomas 'PointedEars' Lahn <> writes:
    > [multiple="multiple"]
    >>>> RTFM.
    >>> Or STFW if you are too cheap to buy the manual that actually matters if
    >>> you want to discuss esoterica.

    >> Idiot.

    >
    > You are a pompous wannabe-hacker permanently stuck in adolescence.


    At least I'm not such a luser like you. I've given (you) enough hints on
    where to find the relevant information, yet you've been either unable or
    unwilling to look it up, and instead engage in pointless quibbling over
    words without even trying to back up *your* assertions.

    >> <http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.4>

    >
    > If you wanna be pragmatic, the HTML 4.01 spec is ten years old, that
    > section was already in the first HTML 4 spec that is eleven years old,
    > and if you consider WG speed it is likely that this note is about the
    > browser landscape twelve years ago or older. So this is supposed to back
    > up your statement “HTML UAs tend to choke on this�


    Unless someone can provide sufficient proof to the contrary. Which nobody
    can, of course.

    > If you wanna be dogmatic, there are no ‘boolean attributes’ in
    > SGML. There’s attribute name omission for name token lists, and
    > historically that was *the* reason to enable SHORTTAG in the quixotic
    > attempt to retrofit HTML into an SGML application.


    Interesting if true, but entirely irrelevant here. Following the HTML 4.01
    Specification, Appendix B, section 3.4, has only potential advantages and no
    drawbacks.

    > So where’s the appendix note that explains how ‘boolean attributes’
    > enable notation like
    > <td justify>
    > ? :)


    Hush, hush, baby.


    PointedEars
     
    Thomas 'PointedEars' Lahn, May 1, 2009
    #10
  11. garey

    David Mark Guest

    On May 2, 11:46 pm, kangax <> wrote:
    > David Mark wrote:
    > > On Apr 30, 8:13 pm, kangax <> wrote:

    > [...]
    > >> Some time ago, I made a naive attempt at releasing a set of examples of
    > >> some of the common feature tests one might stumble upon. The funny thing
    > >> is that when it got to Ajaxian, some people actually argued about
    > >> sniffing being "faster" and supposedly more superior.

    >
    > > Ajaxian is a rag.  And that must have been some time ago as I don't
    > > think anyone would argue for browser sniffing at this point.

    >
    > You'll be surprised :)


    Not really.

    >
    > Less than a month ago someone created a jQuery plugin to emulate
    > text-overflow on non-supporting browsers
    > <http://ajaxian.com/archives/text-overflow-for-firefox-via-jquery>


    Nobodies don't count. :)

    >
    > Then someone in the comments says - "Because of the use of
    > $.browser.mozilla in the plugin, this won’t work with jQuery 1.3.2+."


    Which isn't true (for some definition of "work" that applies to all of
    the other plugins as well.)

    >
    > A response to that comment:
    >
    > <cite>
    > @MichaelThompson: this is why feature detection never gets you all the
    > way there. There’s no way to detect this feature from javascript, as it
    > is a purely visual feature that doesn’t affect the DOM state in any way..
    > </cite>


    The usual BS. I saw this one (and thousands like it over the last
    five years or so.)

    >
    > Another response made me spill my coffee:
    >
    > <cite>
    > It’s not terribly difficult to replace jQuery’s browser detection with
    > your own.


    All old news. The jQuery cult preaches incompetence.

    >
    > For instance:
    > var isGecko = (!!window.Array.every || !!window.Iterator ||
    > !!window.getComputedStyle) && !!document.doctype && !window.opera &&
    > (!!window.devicePixelRatio && !!window.getMatchedCSSRules);


    That's a new one. What do they infer from that?

    >
    > First group is features Gecko has introduced; second and fourth avoid
    > confusion with some Safari versions; third is obvious.
    > </cite>


    These are the people building major Websites today. They won't be
    around much longer.

    >
    > I suggested to remove silly inference by testing style of an element and
    > an author actually did remove an inference from the script (which made
    > it compatible with new jQuery :))


    Please don't help jQuery. As with Prototype, it doesn't deserve your
    help.

    >
    > My "solution" was:
    >
    > var s = document.documentElement.style;
    > if (!('textOverflow' in s || 'OTextOverflow' in s)) {
    > // implement workaround


    I assume the second is the proprietary Opera style.

    >
    > }
    >
    > which I would now probably replace with something like:
    >
    > var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
    >    var docEl = document.documentElement, s;
    >    if (docEl && (s = docEl.style)) {
    >      return typeof s.textOverflow == 'string' ||
    >        typeof s.OTextOverflow == 'string';
    >    }
    >    return null;
    >
    > })();


    Something like that. So much for hysterics about browser sniffing
    being needed to get "all the way there." Hopefully the readers of
    that blog will get this point now.

    There are indeed cases where you can't detect (or test) a feature
    (e.g. PNG translucency support.) As we know, there are other ways to
    make such decisions (e.g. IE conditional comments.) Often the issue
    can be designed out of the system (e.g. substitute GIF's for IE < 7 in
    a conditionally added style sheet.) General purpose scripts like
    jQuery and its plugins don't design anything out as they want to
    please as many incapable people as possible.

    >
    > I'm still not convinced that document.documentElement's style should not
    > be tested since HTML can not have a style attribute, but if that's a
    > concern, it's trivial to test an element that supports it. The problem
    > is that then a test would rely on `document.createElement` being available.


    Depends on the context. A recent project I worked on would have FoUC
    in IE4 (or browsers that don't support
    document.documentElement.style.) I can certainly live with that, so I
    wouldn't consider adding a call to createElement.

    >
    > var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
    >    if (/^(?:function|object|unknown)$/i.test(document.createElement)){
    >      var el = document.createElement('div'), s;
    >      if (el && (s = el.style)) {
    >        return typeof s.textOverflow == 'string' ||
    >          typeof s.OTextOverflow == 'string';
    >      }
    >    }
    >    return null;
    >
    > })();


    Why not wait until the body is ready to test this. The only
    conceivable reason for this that I can see is to emulate text overflow
    with script for browsers that don't support those rules. You wouldn't
    do that until the body is ready.

    Also, the flag doesn't tell you much. You should create a function
    (like setOpacity) rather than a flag.
     
    David Mark, May 3, 2009
    #11
  12. garey

    David Mark Guest

    On May 3, 4:10 pm, kangax <> wrote:
    > David Mark wrote:
    > > On May 2, 11:46 pm, kangax <> wrote:

    > [...]
    > >> I suggested to remove silly inference by testing style of an element and
    > >> an author actually did remove an inference from the script (which made
    > >> it compatible with new jQuery :))

    >
    > > Please don't help jQuery.  As with Prototype, it doesn't deserve your
    > > help.

    >
    > I don't explicitly help jQuery. In this case, I saw a misconception, as
    > well as a trivial solution and I thought it made sense to point out more
    > or less robust replacement. I don't care if it's jQuery or Mootools that
    > this misconception is employed into; The same way any of us would
    > recommend a best practice to someone asking for advice in this newsgroup.


    I was half-kidding. But you do work on Prototype, which seems like
    masochism to me.

    >
    > I do "help" Prototype.js because my work involves maintaining intranet
    > based apps that use it quite heavily. Since these apps are not for
    > general web and are only required to work in a limited set of clients, I
    > don't see a reason to wipe Prototype out (nor do I have a time to do
    > so). There's a lot of code and it does what it needs to do just fine
    > (that is, for people who use it).


    You should definitely wipe it out of your projects, rather than try to
    keep it up.

    >
    > I also happen to be a Prototype.js core developer (for a couple of
    > months now) and am trying to eliminate all of the bogus stuff from the
    > library. You can probably imagine that it's no easy task;


    This is what I'm talking about.

    > Prototype
    > happens to penetrate an environment way too much and makes too many bold
    > actions. Sniffing is another problem. I removed half of it, but some
    > things are just impossible to get rid of, due to "specific" design of a
    > library. What's frustrating is that some sniffs don't even have an
    > explanation; I, for example, still have no idea why Prototype.js
    > disables element extension when userAgent looks like it's a Mobile
    > Safari. Changelog is hardly helpful too.


    Right. It's a derelict at this point. Abandon ship.

    >
    >
    >
    > >> My "solution" was:

    >
    > >> var s = document.documentElement.style;
    > >> if (!('textOverflow' in s || 'OTextOverflow' in s)) {
    > >> // implement workaround

    >
    > > I assume the second is the proprietary Opera style.

    >
    > Yes it is.
    >
    > The problem I see here is that if Mozilla decides to implement
    > text-overflow via its proprietary version, e.g. - "MozTextOverflow" -
    > the code would need to be changed. Same could happen with Webkit,
    > Konqueror or whatever else. This kind of sucks.


    I doubt it. The next browser versions will likely support the CSS3
    rule.

    >
    > Do you think it would make sense to include those in a test right away
    > (as an intelligent guess)?


    Not at this time.

    >
    > It feels sloppy and it's not clear when to "stop". It's quite a mess
    > with all these proprietary CSS3 patching that browser vendors rush to
    > implement but are cautious to mess with currently draft CSS3 names.


    So why are you trying to mess with it in script? Opacity I can see
    (for animations.) Just put the CSS3 rule in your style sheet (along
    with the Opera rendition if you must.)

    >
    > var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
    >    var docEl = document.documentElement, s;
    >    if (docEl && (s = docEl.style)) {
    >      return typeof s.textOverflow == 'string' // CSS3
    >        || typeof s.OTextOverflow == 'string' // opera
    >        || typeof s.MozTextOverflow == 'string' // mozilla
    >        || typeof s.WebkitTextOverflow == 'string' // webkit
    >        || typeof s.KhtmlTextOverflow == 'string'; // khtml
    >    }
    >    return null;
    >
    > })();
    >
    > Isn't there also "-ms" and "-icab"? :)


    Not that I know of.

    >
    >
    >
    >
    >
    > >> }

    >
    > >> which I would now probably replace with something like:

    >
    > >> var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
    > >>    var docEl = document.documentElement, s;
    > >>    if (docEl && (s = docEl.style)) {
    > >>      return typeof s.textOverflow == 'string' ||
    > >>        typeof s.OTextOverflow == 'string';
    > >>    }
    > >>    return null;

    >
    > >> })();

    >
    > > Something like that.  So much for hysterics about browser sniffing
    > > being needed to get "all the way there."  Hopefully the readers of
    > > that blog will get this point now.

    >
    > > There are indeed cases where you can't detect (or test) a feature
    > > (e.g. PNG translucency support.)  As we know, there are other ways to

    >
    > True. Visual aspects can not be tested. Iframe shim for IE (needed to
    > prevent SELECT elements leaking through) is a good example. Then there
    > are key events discrepancies which are not easy to test either (maybe
    > only by testing user-generated key event but that could be quite a hassle)
    >
    > > make such decisions (e.g. IE conditional comments.)  Often the issue
    > > can be designed out of the system (e.g. substitute GIF's for IE < 7 in
    > > a conditionally added style sheet.)  General purpose scripts like
    > > jQuery and its plugins don't design anything out as they want to
    > > please as many incapable people as possible.

    >
    > >> I'm still not convinced that document.documentElement's style should not
    > >> be tested since HTML can not have a style attribute, but if that's a
    > >> concern, it's trivial to test an element that supports it. The problem
    > >> is that then a test would rely on `document.createElement` being available.

    >
    > > Depends on the context.  A recent project I worked on would have FoUC
    > > in IE4 (or browsers that don't support

    >
    > Interesting. So FoUC would occur when `style` property of a
    > `document.documentElement` was accessed?


    No, I was referring to a specific case where the absence of
    documentElement.style would result in FoUC and that would be the only
    effect on the behavior.

    >
    > I was also thinking about a more compatible alternative of getting a
    > "dummy" element for inspection:
    >
    > function getElement(){
    >    var el = document.documentElement;
    >    if (el) return el;
    >    if (document.createElement) {
    >      el = document.createElement('div');
    >      if (el) return el;
    >    }}
    >


    If you absolutely must get a reference to an arbitrary element before
    the body is ready, you should use createElement. It is the best bet
    anyway as you don't know what documentElement might hold (could have
    been modified by other scripts.)

    > ...
    > var el = getElement();
    > if (el && el.style) {
    >    ...
    >
    > }
    >
    > or maybe a more specific `getStyle` helper -
    >
    > function getStyle(){
    >    var el = document.documentElement, s;
    >    if (!el && document.createElement) {
    >      el = document.createElement('div');
    >    }
    >    if (el && (s = el.style)) return s;}


    Of course, you don't normally need such information until the body is
    ready, so you could just use the body instead of the documentElement.
    The only common case I can think of is preventing FoUC.

    >
    > ...
    > var style = getStyle();
    > if (style) {
    >    ...
    >
    >
    >
    > }
    > > document.documentElement.style.)  I can certainly live with that, so I
    > > wouldn't consider adding a call to createElement.

    >
    > >> var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
    > >>    if (/^(?:function|object|unknown)$/i.test(document.createElement)) {
    > >>      var el = document.createElement('div'), s;
    > >>      if (el && (s = el.style)) {
    > >>        return typeof s.textOverflow == 'string' ||
    > >>          typeof s.OTextOverflow == 'string';
    > >>      }
    > >>    }
    > >>    return null;

    >
    > >> })();

    >
    > > Why not wait until the body is ready to test this.  The only
    > > conceivable reason for this that I can see is to emulate text overflow
    > > with script for browsers that don't support those rules.  You wouldn't
    > > do that until the body is ready.

    >
    > That's an option, of course. I just don't like to use `body` when not
    > absolutely needed (for the reason of making it more compatible and
    > portable).


    How does that make it more compatible or portable? Do you mean
    portable to other parts of the document (e.g. the head?)

    > On the other hand, it's all about context, as you said. If
    > I'm writing this test inline and body is already available, i would
    > probably use it.


    A load (or DOMContentLoaded) listener is the more likely place to
    inspect styles.

    >
    >
    >
    > > Also, the flag doesn't tell you much.  You should create a function
    > > (like setOpacity) rather than a flag.

    >
    > Which flag are you talking about?


    IS_TEXT_OVERFLOW_SUPPORTED tells me that one of the two styles is
    present. What do I do now?
     
    David Mark, May 3, 2009
    #12
  13. garey

    David Mark Guest

    On May 3, 7:57 pm, kangax <> wrote:
    > David Mark wrote:
    > > On May 3, 4:10 pm, kangax <> wrote:
    > >> David Mark wrote:
    > >>> On May 2, 11:46 pm, kangax <> wrote:
    > >> [...]
    > >>>> I suggested to remove silly inference by testing style of an elementand
    > >>>> an author actually did remove an inference from the script (which made
    > >>>> it compatible with new jQuery :))
    > >>> Please don't help jQuery.  As with Prototype, it doesn't deserve your
    > >>> help.
    > >> I don't explicitly help jQuery. In this case, I saw a misconception, as
    > >> well as a trivial solution and I thought it made sense to point out more
    > >> or less robust replacement. I don't care if it's jQuery or Mootools that
    > >> this misconception is employed into; The same way any of us would
    > >> recommend a best practice to someone asking for advice in this newsgroup.

    >
    > > I was half-kidding.  But you do work on Prototype, which seems like
    > > masochism to me.

    >
    > I had to make our apps work in IE8. Removing sniffing from Prototype
    > worked a magic (no surprise there). It was also a fun and useful
    > exercise that taught me about feature detection a bit more. I made some
    > mistakes of course but the result is probably better than parsing poor
    > userAgent string for no apparent reason.


    Virtually anything is better than parsing the UA string. The fact
    that Prototype still does that, long after IE8 was released (and ten
    years since IE changed significantly) should tell you it is over. You
    can't keep it up, certainly not if you have to confine your changes to
    the needs of whatever is left of the community.

    >
    > [...]
    >
    > >> The problem I see here is that if Mozilla decides to implement
    > >> text-overflow via its proprietary version, e.g. - "MozTextOverflow" -
    > >> the code would need to be changed. Same could happen with Webkit,
    > >> Konqueror or whatever else. This kind of sucks.

    >
    > > I doubt it.  The next browser versions will likely support the CSS3
    > > rule.

    >
    > But there's a chance that CSS3 does not become final before Mozilla (or
    > any other browser) decides to implement it, isn't there?


    It's possible. I just don't see them adding MozTextOverflow without
    textOverflow. You could write one generic function to use for all
    such on-the-fence styles (e.g. opacity, rounded corners.)

    >
    >
    >
    > >> Do you think it would make sense to include those in a test right away
    > >> (as an intelligent guess)?

    >
    > > Not at this time.

    >
    > Ok.
    >
    >
    >
    > >> It feels sloppy and it's not clear when to "stop". It's quite a mess
    > >> with all these proprietary CSS3 patching that browser vendors rush to
    > >> implement but are cautious to mess with currently draft CSS3 names.

    >
    > > So why are you trying to mess with it in script?  Opacity I can see
    > > (for animations.)  Just put the CSS3 rule in your style sheet (along
    > > with the Opera rendition if you must.)

    >
    > To emulate it in Javascript, as I understand it.


    Oh, the OP. I thought you were working on a patch for Prototype.

    >
    >
    >
    >
    >
    > >> var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
    > >>    var docEl = document.documentElement, s;
    > >>    if (docEl && (s = docEl.style)) {
    > >>      return typeof s.textOverflow == 'string' // CSS3
    > >>        || typeof s.OTextOverflow == 'string' // opera
    > >>        || typeof s.MozTextOverflow == 'string' // mozilla
    > >>        || typeof s.WebkitTextOverflow == 'string' // webkit
    > >>        || typeof s.KhtmlTextOverflow == 'string'; // khtml
    > >>    }
    > >>    return null;

    >
    > >> })();

    >
    > >> Isn't there also "-ms" and "-icab"? :)

    >
    > > Not that I know of.

    >
    > IE8 switched to vendor-specific names for some names, like infamous
    > filter <http://msdn.microsoft.com/en-us/library/ms530752(VS.85).aspx>. I
    > think they actually recommended using "-ms-" prefixed names instead of
    > their non-standard versions.


    Never used them.

    >
    > It appears that there's "-ms-text-overflow" as well
    > <https://developer.mozilla.org/en/CSS/text-overflow>


    Fair enough. That I would use as there is certainly no text-overflow
    in IE.

    >
    > [...]
    >
    > >>> Depends on the context.  A recent project I worked on would have FoUC
    > >>> in IE4 (or browsers that don't support
    > >> Interesting. So FoUC would occur when `style` property of a
    > >> `document.documentElement` was accessed?

    >
    > > No, I was referring to a specific case where the absence of
    > > documentElement.style would result in FoUC and that would be the only
    > > effect on the behavior.

    >
    > I see.
    >
    >
    >
    >
    >
    > >> I was also thinking about a more compatible alternative of getting a
    > >> "dummy" element for inspection:

    >
    > >> function getElement(){
    > >>    var el = document.documentElement;
    > >>    if (el) return el;
    > >>    if (document.createElement) {
    > >>      el = document.createElement('div');
    > >>      if (el) return el;
    > >>    }}

    >
    > > If you absolutely must get a reference to an arbitrary element before
    > > the body is ready, you should use createElement.  It is the best bet
    > > anyway as you don't know what documentElement might hold (could have
    > > been modified by other scripts.)

    >
    > Good point, although it again depends on a context, of course. In this
    > case, for example, it seems unlikely that one of the style properties
    > was removed or replaced with another value, as in:
    >
    > document.documentElement.style.textOverflow = 'muahaha';
    >
    > Although the fact that some browsers allow an arbitrary property to be
    > assigned to a style object proves that it's a good idea to create a
    > dummy element from the scratch. Too bad even dummy element can be "evil":
    >
    > // in Firefox 3.0.10
    > HTMLDivElement.prototype.filter = 'alpha(opacity=50)';
    > document.createElement('div').filter; // "alpha(opacity=50)"


    Simple enough. Throw out all scripts featuring such patterns (just
    like the ones that make inferences based on navigator.userAgent.)

    >
    > I had a rule about creating an element dynamically only when it (or one
    > of its properties/attributes) needed to be modified and used
    > `documentElement` for any "read-only" test.
    >
    > [...]
    >
    > >>> Why not wait until the body is ready to test this.  The only
    > >>> conceivable reason for this that I can see is to emulate text overflow
    > >>> with script for browsers that don't support those rules.  You wouldn't
    > >>> do that until the body is ready.
    > >> That's an option, of course. I just don't like to use `body` when not
    > >> absolutely needed (for the reason of making it more compatible and
    > >> portable).

    >
    > > How does that make it more compatible or portable?  Do you mean
    > > portable to other parts of the document (e.g. the head?)

    >
    > Yes, I often don't use "onload" at all (so body is not available), but
    > assign event handlers globally and use event delegation. This way you
    > avoid any problems that arise from load/DOMContentLoaded.


    I didn't follow that exactly. When do you attach listeners?

    >
    >
    >
    >
    >
    > >> On the other hand, it's all about context, as you said. If
    > >> I'm writing this test inline and body is already available, i would
    > >> probably use it.

    >
    > > A load (or DOMContentLoaded) listener is the more likely place to
    > > inspect styles.

    >
    > >>> Also, the flag doesn't tell you much.  You should create a function
    > >>> (like setOpacity) rather than a flag.
    > >> Which flag are you talking about?

    >
    > > IS_TEXT_OVERFLOW_SUPPORTED tells me that one of the two styles is
    > > present.  What do I do now?

    >
    > You know that it's not supported and emulate it with
    > jQue^H^H^H^HJavascript, I suppose :)


    Right. I forgot what the OP was doing. Still a function makes
    sense. One branch sets style properties, the other trims the text
    content and adds an ellipsis when needed. ISTM I had to do something
    similar recently. I'll have to look into -ms-text-overflow.

    Would be nice if they had -ms-border-radius or -ms-transition (instead
    of filter.) But what I would really like to see is -moz-transition.
     
    David Mark, May 4, 2009
    #13
  14. kangax wrote:
    > David Mark wrote:
    >> On May 3, 7:57 pm, kangax <> wrote:

    > [...]
    >>> But there's a chance that CSS3 does not become final before Mozilla (or
    >>> any other browser) decides to implement it, isn't there?

    >> It's possible. I just don't see them adding MozTextOverflow without
    >> textOverflow. You could write one generic function to use for all
    >> such on-the-fence styles (e.g. opacity, rounded corners.)

    >
    > That's a good idea.


    JFTR: The Test Suites[1] show that Gecko has partial CSS3 support already
    (CSS3 Selectors in particular). As for what is required before CSS3 can
    become a Recommendation please see the "Status of this document" sections of
    the respective CSS3 modules and the W3C Process Document.

    [1] <http://www.w3.org/Style/CSS/Test/>

    >>> Although the fact that some browsers allow an arbitrary property to be
    >>> assigned to a style object proves that it's a good idea to create a
    >>> dummy element from the scratch. Too bad even dummy element can be "evil":
    >>>
    >>> // in Firefox 3.0.10
    >>> HTMLDivElement.prototype.filter = 'alpha(opacity=50)';
    >>> document.createElement('div').filter; // "alpha(opacity=50)"

    >> Simple enough. Throw out all scripts featuring such patterns (just
    >> like the ones that make inferences based on navigator.userAgent.)

    >
    > No doubt about that, but I was talking about an uncontrolled
    > environment.


    You mean "controlled"?

    > The same way you make your scripts work with augmented `Object.prototype`


    The same way?

    > (if I'm not mistaken)


    Probably you are.

    > even though scripts that augment it should be considered dangerous as well.


    Not dangerous (there is no danger in a runtime error), but inappropriate
    (because either it breaks for-in iteration or it makes it considerably less
    efficient), and therefore to be avoided.

    >>> Yes, I often don't use "onload" at all (so body is not available), but
    >>> assign event handlers globally and use event delegation. This way you
    >>> avoid any problems that arise from load/DOMContentLoaded.

    >> I didn't follow that exactly. When do you attach listeners?

    >
    > To a `document.documentElement` at any time and use event delegation
    > (for any event that bubbles, of course).


    I don't think that is a reasonable or compatible approach.

    >> [..] But what I would really like to see is -moz-transition.

    >
    > You're certainly not the only one who wants them.
    > <https://bugzilla.mozilla.org/show_bug.cgi?id=435441> with 19 votes (I
    > just voted as well)


    Thanks for the pointer.


    PointedEars
     
    Thomas 'PointedEars' Lahn, May 6, 2009
    #14
  15. garey

    David Mark Guest

    On May 6, 6:48 pm, kangax <> wrote:
    > Thomas 'PointedEars' Lahn wrote:
    > > kangax wrote:
    > >> David Mark wrote:
    > >>> On May 3, 7:57 pm, kangax <> wrote:
    > >> [...]
    > >>>> But there's a chance that CSS3 does not become final before Mozilla (or
    > >>>> any other browser) decides to implement it, isn't there?
    > >>> It's possible.  I just don't see them adding MozTextOverflow without
    > >>> textOverflow.  You could write one generic function to use for all
    > >>> such on-the-fence styles (e.g. opacity, rounded corners.)
    > >> That's a good idea.

    >
    > > JFTR: The Test Suites[1] show that Gecko has partial CSS3 support already
    > > (CSS3 Selectors in particular).  As for what is required before CSS3 can
    > > become a Recommendation please see the "Status of this document" sections of
    > > the respective CSS3 modules and the W3C Process Document.

    >
    > > [1] <http://www.w3.org/Style/CSS/Test/>

    >
    > Good to know. Thanks.
    >
    >
    >
    > >>>> Although the fact that some browsers allow an arbitrary property to be
    > >>>> assigned to a style object proves that it's a good idea to create a
    > >>>> dummy element from the scratch. Too bad even dummy element can be "evil":

    >
    > >>>> // in Firefox 3.0.10
    > >>>> HTMLDivElement.prototype.filter = 'alpha(opacity=50)';
    > >>>> document.createElement('div').filter; // "alpha(opacity=50)"
    > >>> Simple enough.  Throw out all scripts featuring such patterns (just
    > >>> like the ones that make inferences based on navigator.userAgent.)
    > >> No doubt about that, but I was talking about an uncontrolled
    > >> environment.

    >
    > > You mean "controlled"?

    >
    > I mean "uncontrolled"; an environment where you don't "control" all (or
    > a subset) of the scripts running on a page (i.e. scripts authored by
    > someone else).
    >
    >
    >
    > >> The same way you make your scripts work with augmented `Object.prototype`

    >
    > > The same way?

    >
    > Yes.
    >
    > By using `Object.prototype.hasOwnProperty`, for example; or, more
    > likely, some form of its emulation. "My Library" uses `isOwnProperty` in
    > loops, which is implemented as -
    >
    > var isOwnProperty = function(o, p) {
    >    return typeof o.constructor.prototype[p] == 'undefined';
    >
    > };


    That's the old one. I updated it recently.

    >
    > I'm not sure if accessing a property off of `constructor` without first
    > testing for its existence (given that host objects might not implement
    > it) is the safest way to go, but apparently it works as it is.


    You definitely don't use isOwnProperty with *host* objects. Should be
    documented of course.

    >
    >
    >
    > >> (if I'm not mistaken)

    >
    > > Probably you are.

    >
    > >> even though scripts that augment it should be considered dangerous as well.

    >
    > > Not dangerous (there is no danger in a runtime error), but inappropriate

    >
    > There's no danger in runtime error? Isn't the main reason for employing
    > `isHost*` methods is to prevent runtime errors and return silently?


    Thomas is talking about augmenting the prototypes of Object objects,
    not host objects.

    >
    > > (because either it breaks for-in iteration or it makes it considerably less
    > > efficient), and therefore to be avoided.

    >
    > >>>> Yes, I often don't use "onload" at all (so body is not available), but
    > >>>> assign event handlers globally and use event delegation. This way you
    > >>>> avoid any problems that arise from load/DOMContentLoaded.
    > >>> I didn't follow that exactly.  When do you attach listeners?
    > >> To a `document.documentElement` at any time and use event delegation
    > >> (for any event that bubbles, of course).

    >
    > > I don't think that is a reasonable or compatible approach.

    >
    > Why?


    It is a bit odd.
     
    David Mark, May 7, 2009
    #15
  16. kangax wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> kangax wrote:
    >>> David Mark wrote:
    >>>> On May 3, 7:57 pm, kangax <> wrote:
    >>>>> Although the fact that some browsers allow an arbitrary property to be
    >>>>> assigned to a style object proves that it's a good idea to create a
    >>>>> dummy element from the scratch. Too bad even dummy element can be "evil":
    >>>>>
    >>>>> // in Firefox 3.0.10
    >>>>> HTMLDivElement.prototype.filter = 'alpha(opacity=50)';
    >>>>> document.createElement('div').filter; // "alpha(opacity=50)"
    >>>> Simple enough. Throw out all scripts featuring such patterns (just
    >>>> like the ones that make inferences based on navigator.userAgent.)
    >>> No doubt about that, but I was talking about an uncontrolled
    >>> environment.

    >> You mean "controlled"?

    >
    > I mean "uncontrolled"; an environment where you don't "control" all (or
    > a subset) of the scripts running on a page (i.e. scripts authored by
    > someone else).


    The cause of our misunderstanding is that you assume that this possibility
    exists. However, IMO it doesn't; neither are you required to run such
    scripts nor are you required, if you run them, to keep going with their
    augmentation should it turn out that it hinders the efficiency or
    effectiveness of your scripts. As David said, when you encounter this
    pattern (relying solely on the augmentation of the prototypes of host
    objects), you better throw the script out.

    Therefore, I understood "controlled" with regard to the user agents that may
    be used in that environment: One would use the above code (as it is) only in
    a controlled environment, if that; that is, where there are two groups of
    UAs: one group that does not support Microsoft filters but supports the
    augmentation of the prototypes of host objects, and another group that
    supports the augmentation of the prototypes of host objects *and* implements
    Microsoft filters. In an uncontrolled environment (AIUI), though, there is
    at least a third group to which none of the above applies.

    >>> The same way you make your scripts work with augmented `Object.prototype`

    >> The same way?

    >
    > Yes.
    >
    > By using `Object.prototype.hasOwnProperty`, for example;


    That is hardly "the same way" in any sense of the word. You were talking
    about the augmentation of the prototypes of host objects, not about how to
    deal with it.

    > or, more likely, some form of its emulation. "My Library" uses
    > `isOwnProperty` in loops, which is implemented as -
    >
    > var isOwnProperty = function(o, p) {
    > return typeof o.constructor.prototype[p] == 'undefined';
    > };
    >
    > I'm not sure if accessing a property off of `constructor` without first
    > testing for its existence (given that host objects might not implement
    > it) is the safest way to go, but apparently it works as it is.


    "Apparently" jQuery < 1.3 "worked" before IE 8. This should give you pause.

    >>> even though scripts that augment it should be considered dangerous as well.

    >> Not dangerous (there is no danger in a runtime error), but inappropriate

    >
    > There's no danger in runtime error?


    Mind your words. What possible *danger* is there? A runtime error is an
    avoidable inconvenience, but it poses no danger in and of itself.

    > Isn't the main reason for employing `isHost*` methods is to prevent runtime
    > errors and return silently?


    Non sequitur.

    >> (because either it breaks for-in iteration or it makes it considerably less
    >> efficient), and therefore to be avoided.
    >>
    >>>>> Yes, I often don't use "onload" at all (so body is not available), but
    >>>>> assign event handlers globally and use event delegation. This way you
    >>>>> avoid any problems that arise from load/DOMContentLoaded.
    >>>> I didn't follow that exactly. When do you attach listeners?
    >>> To a `document.documentElement` at any time and use event delegation
    >>> (for any event that bubbles, of course).

    >> I don't think that is a reasonable or compatible approach.

    >
    > Why?


    Proprietary DOM implementations may not consider the root element an event
    target for an event, and AIUI even standards-compliant DOM implementations
    do not need to. Insofar the "weirdness" of this approach constitutes an
    argument against it.

    <http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventTypes-complete>


    PointedEars
     
    Thomas 'PointedEars' Lahn, May 7, 2009
    #16
  17. Thomas 'PointedEars' Lahn wrote:
    > kangax wrote:
    >> Thomas 'PointedEars' Lahn wrote:
    >>> kangax wrote:
    >>>> even though scripts that augment it should be considered dangerous as well.
    >>> Not dangerous (there is no danger in a runtime error), but inappropriate

    >> There's no danger in runtime error?

    >
    > Mind your words. What possible *danger* is there? A runtime error is an
    > avoidable inconvenience, but it poses no danger in and of itself.


    JFTR: As I can see now that several English idioms starting with "Mind your
    ...." are intended to be rather impolite, let it be clear that no offense was
    meant. Instead, I meant to say "you should take more care of which words
    you are using, for they have a certain meaning attached."


    PointedEars
     
    Thomas 'PointedEars' Lahn, May 7, 2009
    #17
  18. garey

    David Mark Guest

    On May 7, 4:45 am, Thomas 'PointedEars' Lahn <>
    wrote:

    [snip]

    >
    > "Apparently" jQuery < 1.3 "worked" before IE 8.  This should give you pause.
    >


    I do want to point out that jQuery 1.3x (they are on the third
    iteration now) does not work in IE8, IE7, IE6, ... IE3, AOL IE, Mac
    IE, IE spoofs or anything that even looks like IE. Not any mode, not
    even close and apparently not in this lifetime. Oh well, we never
    needed it anyway.

    Mozilla could kill these miserable things off for good if they would
    just add mozTransition to Firefox. Without (bad) animations, nobody
    would have ever heard of jQuery. Somebody tell their evangelist.

    [snip]
     
    David Mark, May 7, 2009
    #18
  19. David Mark wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> "Apparently" jQuery < 1.3 "worked" before IE 8. This should give you pause.

    >
    > I do want to point out that jQuery 1.3x (they are on the third
    > iteration now) does not work in IE8, IE7, IE6, ... IE3, AOL IE, Mac
    > IE, IE spoofs or anything that even looks like IE. Not any mode, not
    > even close and apparently not in this lifetime. Oh well, we never
    > needed it anyway.


    I do know you have been posting a lot about jQuery issues, but I have not
    found the time to read all of your postings thoroughly (they are rather long
    and it is difficult to find the technical facts among the bickering, even if
    justified, now), and I certainly don't remember all of them.

    Therefore, would you be so kind to try pointing out and maybe explaining
    *concisely*, if possible, why exactly what you describe above is so? That
    could provide those who are forced by their uninitiated bosses to use jQuery
    for certain graphical gimmicks (because they "look great") a big enough LART
    to abandon jQuery eventually. Thank you very much in advance.

    > Mozilla could kill these miserable things off for good if they would
    > just add mozTransition to Firefox. Without (bad) animations, nobody
    > would have ever heard of jQuery. Somebody tell their evangelist.


    ACK :)


    PointedEars
     
    Thomas 'PointedEars' Lahn, May 7, 2009
    #19
  20. garey

    David Mark Guest

    On May 7, 12:51 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > David Mark wrote:
    > > Thomas 'PointedEars' Lahn wrote:
    > >> "Apparently" jQuery < 1.3 "worked" before IE 8.  This should give you pause.

    >
    > > I do want to point out that jQuery 1.3x (they are on the third
    > > iteration now) does not work in IE8, IE7, IE6, ... IE3, AOL IE, Mac
    > > IE, IE spoofs or anything that even looks like IE.  Not any mode, not
    > > even close and apparently not in this lifetime.  Oh well, we never
    > > needed it anyway.

    >
    > I do know you have been posting a lot about jQuery issues, but I have not
    > found the time to read all of your postings thoroughly (they are rather long
    > and it is difficult to find the technical facts among the bickering, evenif
    > justified, now), and I certainly don't remember all of them.


    Well, as for their length, there were a lot of issues. If you just
    read mine, you will skip the follow-up "bickering" which is really
    more like endless, repetitive blithering.

    >
    > Therefore, would you be so kind to try pointing out and maybe explaining
    > *concisely*, if possible, why exactly what you describe above is so?


    With respect to IE?

    There's too much to explain concisely. Suffice to say that the
    culture revolves around a method called "attr." That method's purpose
    is undocumented. The method's code is pure gibberish that adds ten
    million (approx.) additional complications to the already complicated
    task of cross-browser scripting and its behavior changes across IE
    versions (as well as jQuery versions.) That's one critical, low-level
    method (most are of similar quality.) Another observation is that
    disabling ActiveX in IE causes Ajax calls to unceremoniously throw
    exceptions.

    If that is not enough, go back and read the rest of it. I'll publish
    a summary at some point in the future.

    > That
    > could provide those who are forced by their uninitiated bosses to use jQuery
    > for certain graphical gimmicks (because they "look great") a big enough LART
    > to abandon jQuery eventually.  Thank you very much in advance.


    I've received a lot of queries for more evidence. There's only one of
    me, so I tell most of them to do their own homework.

    [snip]
     
    David Mark, May 7, 2009
    #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. Aidan
    Replies:
    4
    Views:
    522
    Neredbojias
    Jun 7, 2007
  2. APA
    Replies:
    0
    Views:
    1,320
  3. Steve Wright

    AJAX works in IE6 but not IE7 or Firefox

    Steve Wright, Mar 13, 2007, in forum: Javascript
    Replies:
    5
    Views:
    169
    Bart Lateur
    Mar 15, 2007
  4. gray_slp
    Replies:
    3
    Views:
    141
    Geoffrey Summerhayes
    Jun 27, 2007
  5. garey
    Replies:
    1
    Views:
    133
    Thomas 'PointedEars' Lahn
    Apr 30, 2009
Loading...

Share This Page