listing all form variables in javascript with a bookmarklet withoutxpath

Discussion in 'Javascript' started by yawnmoth, Jan 24, 2009.

  1. yawnmoth

    yawnmoth Guest

    I'm trying to make a bookmarklet that'll tell you all the variables
    associated with a particular form. XPath, unfortunately, doesn't
    work. Never mind the fact that the elements that can constitute form
    variables are varied (input, textarea, select, etc), there's also the
    fact that on malformed HTML, it's simply not going to match. For
    instance,

    <div>
    <form action="">
    <input type="text" name="a" />
    </div>
    <div>
    <input type="text" name="b" />
    </div>
    <div>
    <input type="submit" />
    </form>
    </div>

    <script>
    var headings = document.evaluate('//form//input', document, null,
    XPathResult.ANY_TYPE, null);

    var thisHeading = headings.iterateNext();
    alertText = "";
    while (thisHeading) {
    alertText += thisHeading.getAttribute("name") + "\n"
    thisHeading = headings.iterateNext();
    }
    alert(alertText);
    </script>

    If you hit the submit button, you'll get, as GET parameters, both 'a'
    and 'b'. This is true in both Internet Explorer and Firefox. In
    contrast, with XPath (the above is for Firefox, specifically; not sure
    how to do XPath in Internet Explorer), you get only 'a'.

    Any ideas?
     
    yawnmoth, Jan 24, 2009
    #1
    1. Advertising

  2. Re: listing all form variables in javascript with a bookmarklet without xpath

    yawnmoth wrote:

    > [...] there's also the fact that on malformed HTML, it's simply not going
    > to match.


    Works as designed. Behavior is not supposed to be different with other DOM
    accessors.

    > For instance,
    >
    > <div>
    > <form action="">
    > <input type="text" name="a" />


    HTML or XHTML? `type="text"' is redundant.

    > </div>
    > <div>
    > <input type="text" name="b" />
    > </div>
    > <div>
    > <input type="submit" />
    > </form>
    > </div>
    >
    > <script>


    <script type="text/javascript">

    > var headings = document.evaluate('//form//input', document, null,
    > XPathResult.ANY_TYPE, null);
    >
    > var thisHeading = headings.iterateNext();
    > alertText = "";
    > while (thisHeading) {


    Consider this instead:

    var thisHeading;
    while ((thisHeading = headings.iterateNext()))
    {

    > alertText += thisHeading.getAttribute("name") + "\n"


    Consider pushing and joining an array instead. Use .name instead
    of .getAttribute("name") to get the actual name.

    > thisHeading = headings.iterateNext();


    Unnecessary/wrong then.

    > }
    > alert(alertText);


    window.alert(alertText);

    > </script>
    >
    > If you hit the submit button, you'll get, as GET parameters, both 'a'
    > and 'b'. This is true in both Internet Explorer and Firefox. In
    > contrast, with XPath (the above is for Firefox, specifically; not sure
    > how to do XPath in Internet Explorer), you get only 'a'.
    >
    > Any ideas?


    As the underlying markup is completely invalid, you should be glad that
    XPath finds anything at all.

    BTW: <http://chrispederick.com/work/web-developer/> has this feature
    already, and IIRC it started on <https://www.squarefree.com/bookmarklets/>.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Jan 24, 2009
    #2
    1. Advertising

  3. yawnmoth

    yawnmoth Guest

    Re: listing all form variables in javascript with a bookmarkletwithout xpath

    On Jan 24, 5:52 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > yawnmoth wrote:
    > > [...] there's also the fact that on malformed HTML, it's simply not going
    > > to match.

    >
    > Works as designed.  Behavior is not supposed to be different with otherDOM
    > accessors.


    I agree - that's why I said "without xpath" in the subject line.

    > As the underlying markup is completely invalid, you should be glad that
    > XPath finds anything at all.


    Definitely. That, however, doesn't change the fact that document.form
    ['whatever'].submit() can, with malformed HTML, yield form variables
    that you'd never be able to find with XPath. That's why I'm curious
    to know if it can be done /without/ XPath. I want to see what
    document.form['whatever'].submit() thinks the form variables are for a
    given form - not what XPath thinks they are.
     
    yawnmoth, Jan 25, 2009
    #3
  4. Re: listing all form variables in javascript with a bookmarklet without xpath

    yawnmoth wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> yawnmoth wrote:
    >> > [...] there's also the fact that on malformed HTML, it's simply not
    >> > [going
    >> > to match.

    >>
    >> Works as designed.  Behavior is not supposed to be different with other
    >> DOM accessors.

    >
    > I agree - that's why I said "without xpath" in the subject line.


    "Other DOM accessors" include those not using XPath.

    >> As the underlying markup is completely invalid, you should be glad that
    >> XPath finds anything at all.

    >
    > Definitely. That, however, doesn't change the fact that document.form
    > ['whatever'].submit() can, with malformed HTML, yield form variables
    > that you'd never be able to find with XPath. That's why I'm curious
    > to know if it can be done /without/ XPath. I want to see what
    > document.form['whatever'].submit() thinks the form variables are for a
    > given form - not what XPath thinks they are.


    You are falsely ascribing thinking to XPath when it can do nothing but
    operate on the document tree for which the user agent's markup parser is
    ultimately responsible. With invalid markup, outcomes are known to be
    inconsistent among user agents, and there is no point in trying to work
    around that, given the possibilities.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Jan 25, 2009
    #4
  5. Re: listing all form variables in javascript with a bookmarkletwithout xpath

    yawnmoth <> writes:

    > Definitely. That, however, doesn't change the fact that document.form
    > ['whatever'].submit() can, with malformed HTML, yield form variables
    > that you'd never be able to find with XPath. That's why I'm curious
    > to know if it can be done /without/ XPath. I want to see what
    > document.form['whatever'].submit() thinks the form variables are for a
    > given form - not what XPath thinks they are.


    I'm not entirely sure what you mean by "form variables". I'm assuming
    you are talking about the names (and possibly values) of form controls.

    Finding those are easy:

    var elems = document.forms['myform'].elements;
    var text = "";
    for (var i = 0; i < elems.length; i++) {
    var name = elements.name;
    if (name) {
    // There can be form controls without a name. They will
    // not be submitted, but they are still there.
    text += name + "\n";
    }
    }
    alert(text);

    /L
    --
    Lasse Reichstein Holst Nielsen
    'Javascript frameworks is a disruptive technology'
     
    Lasse Reichstein Nielsen, Jan 25, 2009
    #5
  6. yawnmoth

    yawnmoth Guest

    Re: listing all form variables in javascript with a bookmarkletwithout xpath

    On Jan 24, 6:42 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > yawnmoth wrote:
    > > Thomas 'PointedEars' Lahn wrote:
    > >> yawnmoth wrote:
    > >> > [...] there's also the fact that on malformed HTML, it's simply not
    > >> > [going
    > >> > to match.

    >
    > >> Works as designed.  Behavior is not supposed to be different with other
    > >> DOM accessors.

    >
    > > I agree - that's why I said "without xpath" in the subject line.

    >
    > "Other DOM accessors" include those not using XPath.
    >
    > >> As the underlying markup is completely invalid, you should be glad that
    > >> XPath finds anything at all.

    >
    > > Definitely.  That, however, doesn't change the fact that document.form
    > > ['whatever'].submit() can, with malformed HTML, yield form variables
    > > that you'd never be able to find with XPath.  That's why I'm curious
    > > to know if it can be done /without/ XPath.  I want to see what
    > > document.form['whatever'].submit() thinks the form variables are for a
    > > given form - not what XPath thinks they are.

    >
    > You are falsely ascribing thinking to XPath when it can do nothing but
    > operate on the document tree for which the user agent's markup parser is
    > ultimately responsible.

    No shit. Describing the deterministic processes of a computer,
    metaphorically, as "thinking" is hardly without precedent. A few
    examples:

    http://www.google.com/search?q="website+think+you're"

    But what do I know? Maybe all those people really do think that
    behind every website is an AI capable of fully conscious thought.
    Maybe some of them even think that Skynet is actually a website that's
    waiting until the time is right to destroy the world!

    >  With invalid markup, outcomes are known to be
    > inconsistent among user agents, and there is no point in trying to work
    > around that, given the possibilities.


    I'm not talking about different user agents. I'm talking about the
    same user agents. /One/ user-agent will give you /two/ different
    results for the /same/ HTML. The above suggests that there's /one/
    form field. Clicking on the 'Submit' button suggests that there's /
    two/. Since document.forms[0].submit() does the same thing as
    clicking on the 'Submit' button*, replace the javascript in my first
    example with this:

    <script>
    if (window.location.search.indexOf("&") == -1) {
    document.forms[0].submit();
    } else {
    alert(window.location.search.split("&").length);
    }
    </script>

    Why do you suppose that that yields a popup showing the number 2 as
    opposed to 1, even though that's how many elements the first
    javascript suggests exist? What I suppose is this: that document.forms
    [0].submit() doesn't traverse the DOM tree to get its list of form
    fields - it does something else. I want to know what that something
    else "thinks" (<sarcasm>because, obviously, the "user agent" is
    capable of fully conscious thought</sarcasm>) the form fields are -
    not what DOM tree traversal would suggest they are.

    * Okay, okay - to satisfy you're literal mindedness, I'll concede -
    they're not EXACTLY the same thing. The onclick event doesn't fire,
    for one. However, as nitpicky as you are, I believe that for the
    purposes of this discussion, describing them as being the same is
    sufficient.
     
    yawnmoth, Jan 25, 2009
    #6
  7. yawnmoth

    yawnmoth Guest

    Re: listing all form variables in javascript with a bookmarkletwithout xpath

    On Jan 24, 7:47 pm, Lasse Reichstein Nielsen <>
    wrote:
    > yawnmoth <> writes:
    > > Definitely.  That, however, doesn't change the fact that document.form
    > > ['whatever'].submit() can, with malformed HTML, yield form variables
    > > that you'd never be able to find with XPath.  That's why I'm curious
    > > to know if it can be done /without/ XPath.  I want to see what
    > > document.form['whatever'].submit() thinks the form variables are for a
    > > given form - not what XPath thinks they are.

    >
    > I'm not entirely sure what you mean by "form variables". I'm assuming
    > you are talking about the names (and possibly values) of form controls.
    >
    > Finding those are easy:
    >
    > var elems = document.forms['myform'].elements;
    > var text = "";
    > for (var i = 0; i < elems.length; i++) {
    >   var name = elements.name;
    >   if (name) {
    >     // There can be form controls without a name. They will
    >     // not be submitted, but they are still there.
    >     text += name + "\n";
    >   }}
    >
    > alert(text);


    That's exactly what I was looking for - thanks!!
     
    yawnmoth, Jan 25, 2009
    #7
  8. Re: listing all form variables in javascript with a bookmarklet without xpath

    yawnmoth wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> yawnmoth wrote:
    >> > Thomas 'PointedEars' Lahn wrote:
    >> >> yawnmoth wrote:
    >> >> > [...] there's also the fact that on malformed HTML, it's simply not
    >> >> > [going
    >> >> > to match.

    >>
    >> >> Works as designed.  Behavior is not supposed to be different with

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >> >> other DOM accessors.

    ^^^^^^^^^^^^^^^^^^^^
    >> > I agree - that's why I said "without xpath" in the subject line.

    >>
    >> "Other DOM accessors" include those not using XPath.

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >> >> As the underlying markup is completely invalid, you should be glad
    >> >> that XPath finds anything at all.

    >>
    >> > Definitely.  That, however, doesn't change the fact that document.form
    >> > ['whatever'].submit() can, with malformed HTML, yield form variables

    ^^^^^^^^^^^^^
    >> > that you'd never be able to find with XPath.  That's why I'm curious
    >> > to know if it can be done /without/ XPath.  I want to see what
    >> > document.form['whatever'].submit() thinks the form variables are for a
    >> > given form - not what XPath thinks they are.

    >>
    >> You are falsely ascribing thinking to XPath when it can do nothing but
    >> operate on the document tree for which the user agent's markup parser is

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >> ultimately responsible.

    ^^^^^^^^^^^^^^^^^^^^^^^
    > No shit. Describing the deterministic processes of a computer,
    > metaphorically, as "thinking" is hardly without precedent. A few
    > examples:
    > [...]


    Why, why I'm even replying to anonymous googlodytes?

    *PLONK*

    PointedEars
     
    Thomas 'PointedEars' Lahn, Jan 25, 2009
    #8
  9. Re: listing all form variables in javascript with a bookmarklet without xpath

    Lasse Reichstein Nielsen wrote:

    > yawnmoth <> writes:
    >> Definitely. That, however, doesn't change the fact that document.form
    >> ['whatever'].submit() can, with malformed HTML, yield form variables
    >> that you'd never be able to find with XPath. That's why I'm curious
    >> to know if it can be done /without/ XPath. I want to see what
    >> document.form['whatever'].submit() thinks the form variables are for a
    >> given form - not what XPath thinks they are.

    >
    > I'm not entirely sure what you mean by "form variables". I'm assuming
    > you are talking about the names (and possibly values) of form controls.
    >
    > Finding those are easy:
    >
    > var elems = document.forms['myform'].elements;
    > [...]


    That *may* work if error-correction can make a form out of this mess.

    It does _not_ need to work.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Jan 25, 2009
    #9
  10. yawnmoth

    yawnmoth Guest

    Re: listing all form variables in javascript with a bookmarkletwithout xpath

    On Jan 25, 3:58 am, Thomas 'PointedEars' Lahn <>
    wrote:
    > Lasse Reichstein Nielsen wrote:
    > > yawnmoth <> writes:
    > >> Definitely. That, however, doesn't change the fact that document.form
    > >> ['whatever'].submit() can, with malformed HTML, yield form variables
    > >> that you'd never be able to find with XPath. That's why I'm curious
    > >> to know if it can be done /without/ XPath. I want to see what
    > >> document.form['whatever'].submit() thinks the form variables are for a
    > >> given form - not what XPath thinks they are.

    >
    > > I'm not entirely sure what you mean by "form variables". I'm assuming
    > > you are talking about the names (and possibly values) of form controls.

    >
    > > Finding those are easy:

    >
    > > var elems = document.forms['myform'].elements;
    > > [...]

    >
    > That *may* work if error-correction can make a form out of this mess.
    >
    > It does _not_ need to work.


    I realize I'm now in your killfile (just as well - I could do without
    your comments, anyway), but, what you've been failing to understand is
    that, although it doesn't /need/ to work to be fully compliant with
    the standards, it /does/ work.

    What's next? If someone asks for help with CSS Expressions, even
    though they only work on Internet Explorer, are you going to respond,
    to every comment, "that *may* work, but it does _not_ need to work"
    simply because the standards make no mention of them?

    To say that, even though it does work, that the browser is under no
    obligation for it to work, is rather academic and redundant. Browsers
    aren't even under any obligation to implement HTML support. They
    might not get a lot of use without implementing it, but certainly
    there's no requirement that they do so.
     
    yawnmoth, Jan 26, 2009
    #10
  11. yawnmoth

    RoLo Guest

    Re: listing all form variables in javascript with a bookmarkletwithout xpath

    > I realize I'm now in your killfile (just as well - I could do without
    > your comments, anyway), but, what you've been failing to understand is
    > that, although it doesn't /need/ to work to be fully compliant with
    > the standards, it /does/ work.
    >
    > What's next?  If someone asks for help with CSS Expressions, even
    > though they only work on Internet Explorer, are you going to respond,
    > to every comment, "that *may* work, but it does _not_ need to work"
    > simply because the standards make no mention of them?
    >
    > To say that, even though it does work, that the browser is under no
    > obligation for it to work, is rather academic and redundant.  Browsers
    > aren't even under any obligation to implement HTML support.  They
    > might not get a lot of use without implementing it, but certainly
    > there's no requirement that they do so.


    IMHO:

    yeah.. PointedEars is obsessed with standards.
    yeah.. Browser don't do standards the way they should.
    but... we need people like PointedEars to keep standards been what
    they are.. standards.
    usually people tend to go the easy (lazy) way (me included) of doing
    things and creations like IE are born.
    so enjoy and learn from everyone!

    @PointedEars, since I shined your shoes here I hope you don't correct
    my things like <script> at least for a couple of replies :p
    jk..
     
    RoLo, Jan 26, 2009
    #11
  12. Re: listing all form variables in javascript with a bookmarkletwithout xpath

    RoLo wrote:
    >> I realize I'm now in your killfile (just as well - I could do without
    >> your comments, anyway), but, what you've been failing to understand is
    >> that, although it doesn't /need/ to work to be fully compliant with
    >> the standards, it /does/ work.


    Where? When? For how long?

    >> What's next? If someone asks for help with CSS Expressions, even
    >> though they only work on Internet Explorer, are you going to respond,
    >> to every comment, "that *may* work, but it does _not_ need to work"
    >> simply because the standards make no mention of them?


    Nonsense.

    >> To say that, even though it does work, that the browser is under no
    >> obligation for it to work, is rather academic and redundant. Browsers
    >> aren't even under any obligation to implement HTML support.


    Utter nonsense.

    >> They might not get a lot of use without implementing it, but certainly
    >> there's no requirement that they do so.


    I see. A *Web* browser that doesn't support HTML, /the/ language of the
    *Web*. YMMD.

    > IMHO:
    >
    > yeah.. PointedEars is obsessed with standards.


    I'm not.

    > yeah.. Browser don't do standards the way they should.


    That's entirely beside the point in this case.

    > but... we need people like PointedEars to keep standards been what
    > they are.. standards.


    I really do not think I am *that* important.

    > usually people tend to go the easy (lazy) way (me included) of doing
    > things and creations like IE are born.
    > so enjoy and learn from everyone!


    Well said for once, although I'd go for s/creations/abominations ;-)

    However, the point here is: With (syntactically) invalid markup, especially
    with not well-formed markup (like the nesting errors in the example), error
    correction is *necessary* for the user agent to make a DOM tree (in fact, to
    make a parse tree to begin with). And (because of the Browser Wars when
    invalid markup was written on a daily basis), error correction is built into
    every HTML user agent that has a relevant market share today.

    But error correction has *never* been standardized, i.e. there is not one
    interoperable implementation of it, let alone sufficient documentation.
    (The HTML 4.01 Specification only makes some *recommendations* to
    implementors in that regard.) So the resulting parse/DOM tree of invalid
    markup is _not_ guaranteed; what may work in this document, with this
    rendering mode, this version of this user agent, or this user agent
    regarding DOM access may as well not work in another document, another
    rendering mode, another version, or another user agent.

    This applies both to rendering and scripting. With the `elements'
    collection (of which I was well aware, of course) even more than with XPath
    it is of the utmost importance where the `form' element begins in the
    resulting parse tree and where it ends. Only controls that are part of the
    `form' element's content, i.e. are descendants of its tree node, are part of
    the corresponding object's `elements' collection.

    Therefore the solution looked for the bookmarklet which is -- mind you -- to
    handle invalid markup because XPath can't, whether it is implemented using
    XPath or the `elements' collection or any other DOM accessor, is inherently
    unreliable (even `innerHTML' is but a serialization of the DOM subtree).
    And that's not at all academic, it is a fact proven numerous times by
    experience. (Years ago, I stopped counting the number of people here and
    elsewhere who complained that their script was not working, posted invalid
    markup, and when they were told to fix just that, it suddenly worked.)

    See also: <http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you>
    (The date should give you pause.)

    But apparently some people need to learn it all the hard way. (One wonders:
    Why do they even bother to ask here, then?)

    > @PointedEars, since I shined your shoes here I hope you don't correct
    > my things like <script> at least for a couple of replies :p


    Don't count on it; there's hope for you yet.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Jan 27, 2009
    #12
  13. yawnmoth

    yawnmoth Guest

    Re: listing all form variables in javascript with a bookmarkletwithout xpath

    On Jan 26, 7:04 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > <snip>
    > Therefore the solution looked for the bookmarklet which is -- mind you --to
    > handle invalid markup because XPath can't, whether it is implemented using
    > XPath or the `elements' collection or any other DOM accessor, is inherently
    > unreliable (even `innerHTML' is but a serialization of the DOM subtree).
    > And that's not at all academic, it is a fact proven numerous times by
    > experience.  (Years ago, I stopped counting the number of people here and
    > elsewhere who complained that their script was not working, posted invalid
    > markup, and when they were told to fix just that, it suddenly worked.)


    Again, even though I'm in your killfile, I do feel the need to reply.

    If I could update the HTML to make it syntactically valid, I would.
    Indeed, if I could update the HTML, I wouldn't need to write a
    bookmarklet in the first place.

    Yes, in the example I gave, I can update the HTML. The key word,
    here, however, is /example/. If I say... I'm trying to write a
    bookmarklet for, say, dstewart.com (which contains the invalid HTML
    described in my example), that doesn't really seem all that helpful
    for people trying to help me. If I can't be bothered to atleast
    isolate the problem, why should I expect anyone else to isolate the
    problem, let alone come up with a work around?

    Saying "it's impossible - update your HTML" is not helpful. What am I
    supposed to do? Commit a felony offense and hack their website?

    Saying "it's impossible - give up" is equally unhelpful, because,
    although certainly the browser is under no obligation to parse the
    HTML, in point of fact, as has already been established, it does.

    I'm sorry the world doesn't conform to standards. If it did, I
    wouldn't have had to post my question, in the first place, although as
    is, blaming me for the worlds problems, when I'm just as much a victim
    of them as anyone else, seems wantonly inappropriate.
     
    yawnmoth, Feb 1, 2009
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    4
    Views:
    287
    Jaspreet
    Jun 23, 2005
  2. =?iso-8859-1?B?QW5kcuk=?=

    listing all property variables of a class instance

    =?iso-8859-1?B?QW5kcuk=?=, Jun 25, 2007, in forum: Python
    Replies:
    5
    Views:
    298
    =?iso-8859-1?B?QW5kcuk=?=
    Jun 25, 2007
  3. Martin

    Bookmarklet for random url

    Martin, Dec 8, 2003, in forum: Javascript
    Replies:
    5
    Views:
    133
    Martin
    Dec 9, 2003
  4. Javascript Bookmarklet

    , Mar 16, 2005, in forum: Javascript
    Replies:
    0
    Views:
    99
  5. Robert Oschler
    Replies:
    1
    Views:
    124
Loading...

Share This Page