Build web apps in Javascript - new service open for beta

Discussion in 'Javascript' started by AppPad, Feb 19, 2008.

  1. AppPad

    AppPad Guest

    Hello,
    This is a new website I am involved with, and we are seeking to open
    up to a shortlist of users.

    http://apppad.com

    The basic overview of the service is:
    - You define Object Type models & can use a Javascript API to persist
    object data.
    - You create HTML+Javascript applications (everything is provided for
    you - no hosting or DB needed)

    Hoping to find a few curious/interested Javascript gurus out there
    who'd like to try it out.
    Thanks & regards.
    AppPad, Feb 19, 2008
    #1
    1. Advertising

  2. On Feb 18, 11:38 pm, AppPad <> wrote:
    > Hello,
    > This is a new website I am involved with, and we are seeking to open
    > up to a shortlist of users.
    >
    > http://apppad.com
    >
    > The basic overview of the service is:
    > - You define Object Type models & can use a Javascript API to persist
    > object data.
    > - You create HTML+Javascript applications (everything is provided for
    > you - no hosting or DB needed)


    That is a neat idea. I'm sure there are people that know front-end
    technology but not the database side of things. Adobe Air is trying to
    leverage this knowledge to build desktop apps.

    > Hoping to find a few curious/interested Javascript gurus out there
    > who'd like to try it out.


    Unfortunately I don't have the time but good luck!

    Peter
    Peter Michaux, Feb 19, 2008
    #2
    1. Advertising

  3. AppPad

    David Mark Guest

    On Feb 19, 2:38 am, AppPad <> wrote:
    > Hello,
    > This is a new website I am involved with, and we are seeking to open
    > up to a shortlist of users.
    >
    > http://apppad.com
    >

    [snip]

    An application framework based on HTML and JavaScript will require, at
    the very least, developers who can write valid HTML and solid cross-
    browser JavaScript. Best of luck in finding some.
    David Mark, Feb 19, 2008
    #3
  4. AppPad

    rf Guest

    "David Mark" <> wrote in message
    news:...
    On Feb 19, 2:38 am, AppPad <> wrote:
    > Hello,
    > This is a new website I am involved with, and we are seeking to open
    > up to a shortlist of users.
    >
    > http://apppad.com
    >

    [snip]

    An application framework based on HTML and JavaScript will require, at
    the very least, developers who can write valid HTML and solid cross-
    browser JavaScript. Best of luck in finding some.

    They are certainly not living at the above URL :)

    Not even a bloody doctype!

    background-color: 666666; is probably why I get my shocking pink background
    :)
    rf, Feb 19, 2008
    #4
  5. AppPad

    David Mark Guest

    On Feb 19, 3:14 am, "rf" <> wrote:
    [snip]
    >
    > They are certainly not living at the above URL :)
    >
    > Not even a bloody doctype!


    Yes, it is a bizarre melange of HTML 3.2 and XHTML-style markup. No
    doctype (what would it be anyway?), no character encoding specified,
    tables-in-tables (despite the spartan layout), no top-level headline,
    &nbsp; entitities in odd places, hyperlinks that break without script,
    etc., etc. The really irony here is that the pages are clearly
    template-driven and very small, so they only had a to get a very
    limited amount of markup right once.

    Here is an interesting sample:

    <a href=""><a href="#" onClick="alert('Coming soon...')"
    fref="feedback.jsp?appid=28">[App Feedback]</a><br/>

    Then there is the script. This is a new one:

    window.onload = document.onload = appCallOnLoad;

    I can see why somebody might feel compelled to do such a thing, but at
    the very least there should be logic to account for the fact that
    appCallOnLoad might be called twice (there isn't.)

    The most shocking display of incompetence can be found on the feedback
    page, which features half a dozen lines of client-side validation,
    which require (drum roll please) Prototype. (!)

    Developing applications to run in this framework would be akin to
    developing a condo complex in a swamp.

    >
    > background-color: 666666; is probably why I get my shocking pink background
    > :)


    I didn't bother to look at the CSS, but that sample doesn't surprise
    me. Perhaps the devil made them do it (twice.)

    Back to the drawing board guys!
    David Mark, Feb 19, 2008
    #5
  6. AppPad

    AppPad Guest

    Thanks for the feedback. This definitely seems like a knowledgeable
    group.

    The goal has been to test functionality on IE6+ and Firefox2+ (will
    add that info to the docs). Prototype was used for some account areas,
    but not running the "Apps".

    Thanks for pointing out the appCallOnLoad - will give it a further
    look.


    On Feb 19, 12:57 am, David Mark <> wrote:
    > On Feb 19, 3:14 am, "rf" <> wrote:
    > [snip]
    >
    >
    >
    > > They are certainly not living at the above URL :)

    >
    > > Not even a bloody doctype!

    >
    > Yes, it is a bizarre melange of HTML 3.2 and XHTML-style markup.  No
    > doctype (what would it be anyway?), no character encoding specified,
    > tables-in-tables (despite the spartan layout), no top-level headline,
    > &nbsp; entitities in odd places, hyperlinks that break without script,
    > etc., etc.  The really irony here is that the pages are clearly
    > template-driven and very small, so they only had a to get a very
    > limited amount of markup right once.
    >
    > Here is an interesting sample:
    >
    >     <a href=""><a href="#" onClick="alert('Coming soon...')"
    > fref="feedback.jsp?appid=28">[App Feedback]</a><br/>
    >
    > Then there is the script.  This is a new one:
    >
    > window.onload = document.onload = appCallOnLoad;
    >
    > I can see why somebody might feel compelled to do such a thing, but at
    > the very least there should be logic to account for the fact that
    > appCallOnLoad might be called twice (there isn't.)
    >
    > The most shocking display of incompetence can be found on the feedback
    > page, which features half a dozen lines of client-side validation,
    > which require (drum roll please) Prototype. (!)
    >
    > Developing applications to run in this framework would be akin to
    > developing a condo complex in a swamp.
    >
    >
    >
    > > background-color: 666666; is probably why I get my shocking pink background
    > > :)

    >
    > I didn't bother to look at the CSS, but that sample doesn't surprise
    > me.  Perhaps the devil made them do it (twice.)
    >
    > Back to the drawing board guys!
    AppPad, Feb 19, 2008
    #6
  7. AppPad

    David Mark Guest

    On Feb 19, 12:40 pm, AppPad <> wrote:
    >
    > On Feb 19, 12:57 am, David Mark <> wrote:
    >
    >
    >
    > > On Feb 19, 3:14 am, "rf" <> wrote:
    > > [snip]

    >
    > > > They are certainly not living at the above URL :)

    >
    > > > Not even a bloody doctype!

    >
    > > Yes, it is a bizarre melange of HTML 3.2 and XHTML-style markup. No
    > > doctype (what would it be anyway?), no character encoding specified,
    > > tables-in-tables (despite the spartan layout), no top-level headline,
    > > &nbsp; entitities in odd places, hyperlinks that break without script,
    > > etc., etc. The really irony here is that the pages are clearly
    > > template-driven and very small, so they only had a to get a very
    > > limited amount of markup right once.

    >
    > > Here is an interesting sample:

    >
    > > <a href=""><a href="#" onClick="alert('Coming soon...')"
    > > fref="feedback.jsp?appid=28">[App Feedback]</a><br/>

    >
    > > Then there is the script. This is a new one:

    >
    > > window.onload = document.onload = appCallOnLoad;

    >
    > > I can see why somebody might feel compelled to do such a thing, but at
    > > the very least there should be logic to account for the fact that
    > > appCallOnLoad might be called twice (there isn't.)

    >
    > > The most shocking display of incompetence can be found on the feedback
    > > page, which features half a dozen lines of client-side validation,
    > > which require (drum roll please) Prototype. (!)

    >
    > > Developing applications to run in this framework would be akin to
    > > developing a condo complex in a swamp.

    >
    > > > background-color: 666666; is probably why I get my shocking pink background
    > > > :)

    >
    > > I didn't bother to look at the CSS, but that sample doesn't surprise
    > > me. Perhaps the devil made them do it (twice.)

    >
    > > Back to the drawing board guys!


    [Post order restored]

    Please do not top-post. It makes it difficult to follow the
    conversation.

    > Thanks for the feedback. This definitely seems like a knowledgeable
    > group.


    Nice attitude. There may be hope for your app yet.

    >
    > The goal has been to test functionality on IE6+ and Firefox2+ (will


    Realize you are testing in quirks mode due to the lack of a doctype.
    Of course, before you add a doctype, you need to decide what flavor of
    markup is appropriate for your needs (HTML 4.01 strict) and change the
    existing markup so it will validate according to the chosen schema.

    > add that info to the docs). Prototype was used for some account areas,
    > but not running the "Apps".


    Get rid of Prototype. You certainly don't need it.

    >
    > Thanks for pointing out the appCallOnLoad - will give it a further
    > look.


    Just lose the document.onload part. You don't need it.
    David Mark, Feb 19, 2008
    #7
  8. AppPad

    AppPad Guest

    On Feb 19, 11:48 am, David Mark <> wrote:
    > On Feb 19, 12:40 pm, AppPad <> wrote:
    >
    >
    >
    >
    >
    > > On Feb 19, 12:57 am, David Mark <> wrote:

    >
    > > > On Feb 19, 3:14 am, "rf" <> wrote:
    > > > [snip]

    >
    > > > > They are certainly not living at the above URL :)

    >
    > > > > Not even a bloody doctype!

    >
    > > > Yes, it is a bizarre melange of HTML 3.2 and XHTML-style markup. No
    > > > doctype (what would it be anyway?), no character encoding specified,
    > > > tables-in-tables (despite the spartan layout), no top-level headline,
    > > > &nbsp; entitities in odd places, hyperlinks that break without script,
    > > > etc., etc. The really irony here is that the pages are clearly
    > > > template-driven and very small, so they only had a to get a very
    > > > limited amount of markup right once.

    >
    > > > Here is an interesting sample:

    >
    > > > <a href=""><a href="#" onClick="alert('Coming soon...')"
    > > > fref="feedback.jsp?appid=28">[App Feedback]</a><br/>

    >
    > > > Then there is the script. This is a new one:

    >
    > > > window.onload = document.onload = appCallOnLoad;

    >
    > > > I can see why somebody might feel compelled to do such a thing, but at
    > > > the very least there should be logic to account for the fact that
    > > > appCallOnLoad might be called twice (there isn't.)

    >
    > > > The most shocking display of incompetence can be found on the feedback
    > > > page, which features half a dozen lines of client-side validation,
    > > > which require (drum roll please) Prototype. (!)

    >
    > > > Developing applications to run in this framework would be akin to
    > > > developing a condo complex in a swamp.

    >
    > > > > background-color: 666666; is probably why I get my shocking pink background
    > > > > :)

    >
    > > > I didn't bother to look at the CSS, but that sample doesn't surprise
    > > > me. Perhaps the devil made them do it (twice.)

    >
    > > > Back to the drawing board guys!

    >
    > [Post order restored]
    >
    > Please do not top-post. It makes it difficult to follow the
    > conversation.
    >
    > > Thanks for the feedback. This definitely seems like a knowledgeable
    > > group.

    >
    > Nice attitude. There may be hope for your app yet.
    >
    >
    >
    > > The goal has been to test functionality on IE6+ and Firefox2+ (will

    >
    > Realize you are testing in quirks mode due to the lack of a doctype.
    > Of course, before you add a doctype, you need to decide what flavor of
    > markup is appropriate for your needs (HTML 4.01 strict) and change the
    > existing markup so it will validate according to the chosen schema.
    >
    > > add that info to the docs). Prototype was used for some account areas,
    > > but not running the "Apps".

    >
    > Get rid of Prototype. You certainly don't need it.
    >
    >
    >
    > > Thanks for pointing out the appCallOnLoad - will give it a further
    > > look.

    >
    > Just lose the document.onload part. You don't need it.


    Thanks again for the feedback. You are right about Prototype... it was
    minimally used, so stripped it out. The doctype seems to be validating
    alright as well.

    Still have on the (fairly long) to-do list the onload calls. IE &
    firefox didn't seem to play nicely on the same onload calls, so that
    will take a bit more research on the best way to do it.

    In case anyone is interested, there is now a Demo account you can try
    from the AppPad homepage (which should give you a better idea what
    this tool is about). The goal is to create a service that DHTML savvy
    folks could use so they don't need to hassle with hosting for small
    simple apps. It's true - not your everyday Joe knows this stuff, but
    if it eventually helps a few folks out... then mission accomplished.

    Regards, Steve
    AppPad, Feb 21, 2008
    #8
  9. AppPad

    David Mark Guest

    On Feb 21, 12:19 am, AppPad <> wrote:
    > Thanks again for the feedback. You are right about Prototype... it was


    Good riddance to bad baggage.

    > minimally used, so stripped it out. The doctype seems to be validating
    > alright as well.
    >


    You should really use HTML strict. The steps required to make your
    document validate against that doctype will be well worth it. You
    will need to replace the old-fashioned presentational markup
    attributes and elements with CSS.

    > Still have on the (fairly long) to-do list the onload calls. IE &
    > firefox didn't seem to play nicely on the same onload calls, so that


    How so? Removing the document.onload bit shouldn't have any effect on
    any browser that I know of (certainly not IE or FF.)

    > will take a bit more research on the best way to do it.


    Not really.

    window.onload = myfunction;

    >
    > In case anyone is interested, there is now a Demo account you can try
    > from the AppPad homepage (which should give you a better idea what
    > this tool is about). The goal is to create a service that DHTML savvy
    > folks could use so they don't need to hassle with hosting for small
    > simple apps. It's true - not your everyday Joe knows this stuff, but


    Well, savvy Web developers probably already have hosting accounts.
    You will need to add more value. The Flickr mashup demo is a step in
    the right direction. Provide a "gallery" of mashup tools and perhaps
    you will have something, but the idea isn't new.

    > if it eventually helps a few folks out... then mission accomplished.
    >


    Best of luck.
    David Mark, Feb 21, 2008
    #9
  10. AppPad

    David Mark Guest

    On Feb 21, 4:19 am, Randy Webb <> wrote:
    > David Mark said the following on 2/21/2008 3:00 AM:
    >
    > > On Feb 21, 12:19 am, AppPad <> wrote:

    >
    > <snip>
    >
    > >> will take a bit more research on the best way to do it.

    >
    > > Not really.

    >
    > > window.onload = myfunction;

    >
    > Don't let Thomas know that :)
    >


    Proprietary and error-prone approach. I know.

    BTW, based on a recent post of yours, I take it that you now consider
    this inferior to an onload attribute in the body tag. Something about
    unobtrusive JS being a joke. Granted, it is a fairly ambiguous term
    and the techniques associated with it are often misused, but I fail to
    see the humor in it.
    David Mark, Feb 21, 2008
    #10
  11. AppPad

    David Mark Guest

    On Feb 21, 6:14 am, Randy Webb <> wrote:
    > David Mark said the following on 2/21/2008 4:31 AM:
    >
    > > On Feb 21, 4:19 am, Randy Webb <> wrote:
    > >> David Mark said the following on 2/21/2008 3:00 AM:

    >
    > >>> On Feb 21, 12:19 am, AppPad <> wrote:
    > >> <snip>

    >
    > >>>> will take a bit more research on the best way to do it.
    > >>> Not really.
    > >>> window.onload = myfunction;
    > >> Don't let Thomas know that :)

    >
    > > Proprietary and error-prone approach.  I know.

    >
    > Only in Thomas' warped mind is it.


    Agreed.

    >
    > > BTW, based on a recent post of yours, I take it that you now consider
    > > this inferior to an onload attribute in the body tag.  

    >
    > No. I don't. You are using the onload event of two entirely different
    > objects. One is the body element, the other is the window.


    However, in some browsers they amount to the same thing. For example,
    setting window.onload cancels out the listener created in the body's
    onload attribute.

    >
    > > Something about unobtrusive JS being a joke.  

    >
    > In the context and post that I made that statement, it was a script that
    > was attempting to add an event handler to a single element. There are
    > three reasons I can think of, easily, for doing it that way:
    >
    > 1) An exercise in trying to dynamically add event handlers.
    > 2) Lack of knowing better.
    > 3) The guise of "unobtrusive javascript".
    >
    > If you are adding multiple, duplicated, event handlers, then by all
    > means do it by script. Make it simpler on yourself. Then put the JS code
    > in an external file so that non script UA's don't have to download a lot
    > of code it will never use.


    Right. It makes maintenance easier and is a more flexible structure
    as well.

    >
    > When people take it too far then it becomes a joke to me. I find it
    > humorous in a strange kind of way. Dynamically adding an event handler
    > to a single element instead of just coding it? Yeah, it is humorous to me.


    I don't know. I don't like to mix script in with the markup.

    >
    > > Granted, it is a fairly ambiguous term and the techniques associated
    > > with it are often misused, but I fail to see the humor in it.

    >
    > It didn't help matters for me to have my weekly Monday meeting at work,
    > leave, open up my Intranet site Wednesday morning last week, encounter
    > error messages. Right Click>View Source, lets find the problem. What I
    > found was these two lines:
    >
    > <script type="text/javascript" src="prototype-1.6.0.2"></script>
    > <script type="text/javascript" src="jquery-1.2.3"></script>


    As Thomas would say: OMG.

    >
    > A call to one of my senior programmers let me know they had spent the
    > afternoon Monday and all day Tuesday re-doing my Intranet so that it
    > would be "Unobtrusive Javascript to get the scripts out of the HTML
    > file" and the only way to do that was to "use jQuery and Prototype". No,


    LOL. Where did you find this "senior programmer?" A soup kitchen?

    > it didn't put me in a good frame of mind about unobtrusive javascript.


    Certainly unobtrusive JavaScript via Prototype *and* jQuery is
    madness. Your "senior programmer" should be demoted to junior
    janitor.

    >
    > The other "defense" of it is to have "clean HTML". And that is also
    > humorous to me. People doing things that are good but they don't even
    > have the first clue *why* they are doing it that makes it unobtrusive.


    That's the way of the Web currently.

    >
    > And, no, he doesn't work for me anymore.
    >


    I imagine not. Clean HTML indeed. Simply add 200K of incompetent
    script and just look at the difference!

    One can only wonder where this "senior programmer" got his
    information. Clearly he doesn't read this group.
    David Mark, Feb 21, 2008
    #11
  12. AppPad

    David Mark Guest

    On Feb 21, 6:19 am, Randy Webb <> wrote:
    > Randy Webb said the following on 2/21/2008 6:14 AM:
    >
    > <snip>
    >
    > > <script type="text/javascript" src="prototype-1.6.0.2"></script>
    > > <script type="text/javascript" src="jquery-1.2.3"></script>

    >
    > With the .js extension of course. It is what happens when I think ahead
    > of myself. They had installed jQuery and Prototype on the server and had
    > put it in every single page on my server and "fixing" code so that it
    > was "unobtrusive". No, I was not happy. They spent Thursday, Friday and
    > part of this last Monday fixing it.
    >


    And Tuesday looking for new jobs?
    David Mark, Feb 21, 2008
    #12
  13. David Mark meinte:

    > Certainly unobtrusive JavaScript via Prototype *and* jQuery is
    > madness. Your "senior programmer" should be demoted to junior
    > janitor.


    Come off it! Janitors can save the universe.
    <http://en.wikipedia.org/wiki/Space_Quest>

    Gregor


    --
    http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
    http://web.gregorkofler.com ::: meine JS-Spielwiese
    http://www.image2d.com ::: Bildagentur für den alpinen Raum
    Gregor Kofler, Feb 21, 2008
    #13
  14. David Mark wrote:
    > On Feb 21, 6:14 am, Randy Webb <> wrote:
    >> David Mark said the following on 2/21/2008 4:31 AM:
    >>> On Feb 21, 4:19 am, Randy Webb <> wrote:
    >>>> David Mark said the following on 2/21/2008 3:00 AM:
    >>>>> On Feb 21, 12:19 am, AppPad <> wrote:
    >>>> <snip>
    >>>>>> will take a bit more research on the best way to do it.
    >>>>> Not really.
    >>>>> window.onload = myfunction;
    >>>> Don't let Thomas know that :)
    >>> Proprietary and error-prone approach. I know.

    >> Only in Thomas' warped mind is it.

    >
    > Agreed.


    Once you recognized that there is inherent truth in the statement that your
    favorite (collection of) browser(s) is not the standard for every user agent
    out there, you will see how mistaken you really are here.

    >> <script type="text/javascript" src="prototype-1.6.0.2"></script>
    >> <script type="text/javascript" src="jquery-1.2.3"></script>

    >
    > As Thomas would say: OMG.


    Don't quote me unless you mean it.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Feb 23, 2008
    #14
  15. Gregor Kofler wrote:
    > David Mark meinte:
    >> Certainly unobtrusive JavaScript via Prototype *and* jQuery is
    >> madness. Your "senior programmer" should be demoted to junior
    >> janitor.

    >
    > Come off it! Janitors can save the universe.
    > <http://en.wikipedia.org/wiki/Space_Quest>


    YMMD :)

    \\// PointedEars, adding a "find my SQ6 game box" reminder
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
    Thomas 'PointedEars' Lahn, Feb 23, 2008
    #15
  16. On Feb 22, 5:07 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > David Mark wrote:
    > > On Feb 21, 6:14 am, Randy Webb <> wrote:
    > >> David Mark said the following on 2/21/2008 4:31 AM:
    > >>> On Feb 21, 4:19 am, Randy Webb <> wrote:
    > >>>> David Mark said the following on 2/21/2008 3:00 AM:
    > >>>>> On Feb 21, 12:19 am, AppPad <> wrote:
    > >>>> <snip>
    > >>>>>> will take a bit more research on the best way to do it.
    > >>>>> Not really.
    > >>>>> window.onload = myfunction;
    > >>>> Don't let Thomas know that :)
    > >>> Proprietary and error-prone approach. I know.
    > >> Only in Thomas' warped mind is it.

    >
    > > Agreed.

    >
    > Once you recognized that there is inherent truth in the statement that your
    > favorite (collection of) browser(s) is not the standard for every user agent
    > out there, you will see how mistaken you really are here.


    Please explain.

    Peter
    Peter Michaux, Feb 23, 2008
    #16
  17. Peter Michaux wrote:
    > [...] Thomas 'PointedEars' Lahn [...] wrote:
    >> David Mark wrote:
    >>> On Feb 21, 6:14 am, Randy Webb <> wrote:
    >>>> David Mark said the following on 2/21/2008 4:31 AM:
    >>>>> On Feb 21, 4:19 am, Randy Webb <> wrote:
    >>>>>> David Mark said the following on 2/21/2008 3:00 AM:
    >>>>>>> On Feb 21, 12:19 am, AppPad <> wrote:
    >>>>>> <snip>
    >>>>>>>> will take a bit more research on the best way to do it.
    >>>>>>> Not really.
    >>>>>>> window.onload = myfunction;
    >>>>>> Don't let Thomas know that :)
    >>>>> Proprietary and error-prone approach. I know.
    >>>> Only in Thomas' warped mind is it.
    >>> Agreed.

    >> Once you recognized that there is inherent truth in the statement that your
    >> favorite (collection of) browser(s) is not the standard for every user agent
    >> out there, you will see how mistaken you really are here.

    >
    > Please explain.


    There really is not much to explain. Assuming a proprietary feature to be
    universally available is a jump to conclusions; a common fallacy, though.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Feb 23, 2008
    #17
  18. AppPad

    David Mark Guest

    On Feb 23, 4:41 am, Thomas 'PointedEars' Lahn <>
    wrote:
    > Peter Michaux wrote:
    > > [...] Thomas 'PointedEars' Lahn [...] wrote:
    > >> David Mark wrote:
    > >>> On Feb 21, 6:14 am, Randy Webb <> wrote:
    > >>>> David Mark said the following on 2/21/2008 4:31 AM:
    > >>>>> On Feb 21, 4:19 am, Randy Webb <> wrote:
    > >>>>>> David Mark said the following on 2/21/2008 3:00 AM:
    > >>>>>>> On Feb 21, 12:19 am, AppPad <> wrote:
    > >>>>>> <snip>
    > >>>>>>>> will take a bit more research on the best way to do it.
    > >>>>>>> Not really.
    > >>>>>>> window.onload = myfunction;
    > >>>>>> Don't let Thomas know that :)
    > >>>>> Proprietary and error-prone approach.  I know.
    > >>>> Only in Thomas' warped mind is it.
    > >>> Agreed.
    > >> Once you recognized that there is inherent truth in the statement that your
    > >> favorite (collection of) browser(s) is not the standard for every user agent
    > >> out there, you will see how mistaken you really are here.

    >
    > > Please explain.

    >
    > There really is not much to explain.  Assuming a proprietary feature to be
    > universally available is a jump to conclusions; a common fallacy, though.
    >


    Oh for the love of God. How many times are you going to dump on
    window.onload without naming a single case where it might be
    considered harmful? Assuming an agent does not support DOM2 (or
    attachEvent), it is perfectly reasonable to use window.onload as a
    fallback. As discussed in a recent thread, there is a way to detect
    support for it, but most scripted enhancements have no need to do so.
    David Mark, Feb 23, 2008
    #18
  19. David Mark wrote:
    > [...] Thomas 'PointedEars' Lahn [...] wrote:
    >> Peter Michaux wrote:
    >>> [...] Thomas 'PointedEars' Lahn [...] wrote:
    >>>> David Mark wrote:
    >>>>> On Feb 21, 6:14 am, Randy Webb <> wrote:
    >>>>>> David Mark said the following on 2/21/2008 4:31 AM:
    >>>>>>> On Feb 21, 4:19 am, Randy Webb <> wrote:
    >>>>>>>> David Mark said the following on 2/21/2008 3:00 AM:
    >>>>>>>>> On Feb 21, 12:19 am, AppPad <> wrote:
    >>>>>>>> <snip>
    >>>>>>>>>> will take a bit more research on the best way to do it.
    >>>>>>>>> Not really.
    >>>>>>>>> window.onload = myfunction;
    >>>>>>>> Don't let Thomas know that :)
    >>>>>>> Proprietary and error-prone approach. I know.
    >>>>>> Only in Thomas' warped mind is it.
    >>>>> Agreed.
    >>>> Once you recognized that there is inherent truth in the statement that your
    >>>> favorite (collection of) browser(s) is not the standard for every user agent
    >>>> out there, you will see how mistaken you really are here.
    >>> Please explain.

    >> There really is not much to explain. Assuming a proprietary feature to be
    >> universally available is a jump to conclusions; a common fallacy, though.

    >
    > Oh for the love of God. How many times are you going to dump on
    > window.onload without naming a single case where it might be
    > considered harmful?


    As many times as I want to without running the risk of losing credibility
    among those who still can think clearly. You instead, have already/just
    become the victim of another logical fallacy known as "shifting the burden
    of proof":

    It is _not_ up to me to prove that I am correct, because the statement is
    true by itself, the very meaning of the word "proprietary" in this context
    and the truth of the fact that it applies to this situation (the "inherent
    truth" I was talking about earlier). It is instead up to those who have
    been jumping to the conclusion to prove that they are not incorrect (i.e.
    that "proprietary" does not apply here), by providing proof that it works
    for *each and every* user agent out there, present and future. As that is
    (currently) impossible, their argument, if there ever was one, is rendered
    irrelevant in the end.


    HTH

    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Feb 23, 2008
    #19
  20. AppPad

    David Mark Guest

    On Feb 23, 12:55 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > David Mark wrote:
    > > [...] Thomas 'PointedEars' Lahn [...] wrote:
    > >> Peter Michaux wrote:
    > >>> [...] Thomas 'PointedEars' Lahn [...] wrote:
    > >>>> David Mark wrote:
    > >>>>> On Feb 21, 6:14 am, Randy Webb <> wrote:
    > >>>>>> David Mark said the following on 2/21/2008 4:31 AM:
    > >>>>>>> On Feb 21, 4:19 am, Randy Webb <> wrote:
    > >>>>>>>> David Mark said the following on 2/21/2008 3:00 AM:
    > >>>>>>>>> On Feb 21, 12:19 am, AppPad <> wrote:
    > >>>>>>>> <snip>
    > >>>>>>>>>> will take a bit more research on the best way to do it.
    > >>>>>>>>> Not really.
    > >>>>>>>>> window.onload = myfunction;
    > >>>>>>>> Don't let Thomas know that :)
    > >>>>>>> Proprietary and error-prone approach.  I know.
    > >>>>>> Only in Thomas' warped mind is it.
    > >>>>> Agreed.
    > >>>> Once you recognized that there is inherent truth in the statement that your
    > >>>> favorite (collection of) browser(s) is not the standard for every user agent
    > >>>> out there, you will see how mistaken you really are here.
    > >>> Please explain.
    > >> There really is not much to explain.  Assuming a proprietary feature to be
    > >> universally available is a jump to conclusions; a common fallacy, though.

    >
    > > Oh for the love of God.  How many times are you going to dump on
    > > window.onload without naming a single case where it might be
    > > considered harmful?

    >
    > As many times as I want to without running the risk of losing credibility


    Too late.

    > among those who still can think clearly.  You instead, have already/just
    > become the victim of another logical fallacy known as "shifting the burden
    > of proof":


    Hardly.

    >
    > It is _not_ up to me to prove that I am correct, because the statement is


    I didn't say it was, just that it would be nice if you presented some
    tiny shred of evidence to support your oft-repeated position that
    window.onload is inherently error-prone. It would be more accurate to
    say that assuming the window.onload property is supported is
    inherently error-prone (as are all assumptions about host objects.)
    You often suggest that an intrinsic body onload handler is a better
    approach, yet assuming support for intrinsic handlers is no less error-
    prone. In fact, in some browsers, it amounts to the same thing
    (that's why assigning to window.onload can wipe out the body's
    intrinsic handler.)

    > true by itself, the very meaning of the word "proprietary" in this context


    We all know it is proprietary. The window object is not part of the
    DOM. But in reality (as opposed to the specs), the window.onload
    property is extremely reliable. I am just curious if you actually
    know of a situation where using it (as opposed to relying on it to
    make a page usable) could cause a problem that would not have occurred
    had an intrinsic handler been used.

    [snip]
    David Mark, Feb 23, 2008
    #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. Michael Averstegge
    Replies:
    0
    Views:
    4,217
    Michael Averstegge
    Jan 10, 2006
  2. anonymous

    Call windows apps from web apps

    anonymous, Feb 22, 2005, in forum: ASP .Net Datagrid Control
    Replies:
    4
    Views:
    210
    anonymous
    Feb 28, 2005
  3. Scott Baierl
    Replies:
    1
    Views:
    278
    Scott Baierl
    Jul 29, 2006
  4. Richard Choate

    Web enabled apps/Thin client apps

    Richard Choate, Jul 23, 2003, in forum: ASP General
    Replies:
    2
    Views:
    294
    Chris Barber
    Jul 23, 2003
  5. Replies:
    2
    Views:
    448
    Thomas 'PointedEars' Lahn
    Mar 11, 2008
Loading...

Share This Page