listing all form variables in javascript with a bookmarklet withoutxpath

[yawnmoth]

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?

 

[Thomas 'PointedEars' Lahn]

[...] 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>

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

 

[yawnmoth]

[...] 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.

 

[Thomas 'PointedEars' Lahn]

[...] 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

 

[Lasse Reichstein Nielsen]

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

 

[yawnmoth]

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.

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]

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!!

 

[Thomas 'PointedEars' Lahn]

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]

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

 

[yawnmoth]

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.

 

[RoLo]

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
jk..

 

[Thomas 'PointedEars' Lahn]

Where? When? For how long?

Nonsense.

Utter nonsense.

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

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


PointedEars

 

[yawnmoth]

<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.