Finding line numbers of HTML elements

[e271828]

Hi,

I'm helping to work a developer tool that verifies a given HTML element
has a given attribute (e.g., that all LABEL elements have a FOR
attribute, all INPUT elements have an ID attribute, etc.). Pretty much
all of the functionality is working except a feature that shows in
which line of the HTML source a violation of the user-set rule occurs
(e.g., where a LABEL element doesn't have a FOR attribute). There
doesn't seem to be a straightforward way with Javascript to find out at
which line a piece of a page's HTML code is, so I've been reading
through the XBL/XPCOM source code of Mozilla Firefox's Javascript
Console for some insight. While I'm slowly making progress with that
method, I was wondering if I haven't overlooked some way to do what I
want with Javascript. Has anyone dealt with this kind of problem?

Thanks,
Eric

[Randy Webb]

e271828 said the following on 8/13/2006 6:18 PM:

Hi,

I'm helping to work a developer tool that verifies a given HTML element
has a given attribute (e.g., that all LABEL elements have a FOR
attribute, all INPUT elements have an ID attribute, etc.). Pretty much
all of the functionality is working except a feature that shows in
which line of the HTML source a violation of the user-set rule occurs
(e.g., where a LABEL element doesn't have a FOR attribute). There
doesn't seem to be a straightforward way with Javascript to find out at
which line a piece of a page's HTML code is, so I've been reading
through the XBL/XPCOM source code of Mozilla Firefox's Javascript
Console for some insight. While I'm slowly making progress with that
method, I was wondering if I haven't overlooked some way to do what I
want with Javascript. Has anyone dealt with this kind of problem?

How you would find that line number depends on how you read the source.
But, you could always read the entire page as a string, find the
occurrence of the offending code, get a substring from 0 to the point of
the offending code, then split that substring on \r\n and the length of
the resulting array minus one will be your line number.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[e271828]

I intially thougt of doing something along those lines as well, but the
following pieces of Javascript that I tried didn't work quite right:

alert("'" + document.toString() + "'"); returns [objectHTMLelement] --
definitely not what I'm looking for. Applying the .length method to
that returns the number of characters (21) in the document.toString()
result. I also tried alert("'" +
document.getElementsByTagName("html").toString() + "'" and
document.getElementsByTagName("html").innerHTML + "'");, but had no
luck there either. If there isn't a way to get the document as a
string, then there's little option to proceed. I think I might try my
hand at extending Firefox's Javascript Debuggers XBL bindings (which
feels like too much work for a fairly mundane feature), unless anybody
has other ideas.

Thanks for the input though.

Randy Webb wrote:

e271828 said the following on 8/13/2006 6:18 PM:

Hi,

I'm helping to work a developer tool that verifies a given HTML element
has a given attribute (e.g., that all LABEL elements have a FOR
attribute, all INPUT elements have an ID attribute, etc.). Pretty much
all of the functionality is working except a feature that shows in
which line of the HTML source a violation of the user-set rule occurs
(e.g., where a LABEL element doesn't have a FOR attribute). There
doesn't seem to be a straightforward way with Javascript to find out at
which line a piece of a page's HTML code is, so I've been reading
through the XBL/XPCOM source code of Mozilla Firefox's Javascript
Console for some insight. While I'm slowly making progress with that
method, I was wondering if I haven't overlooked some way to do what I
want with Javascript. Has anyone dealt with this kind of problem?

How you would find that line number depends on how you read the source.
But, you could always read the entire page as a string, find the
occurrence of the offending code, get a substring from 0 to the point of
the offending code, then split that substring on \r\n and the length of
the resulting array minus one will be your line number.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[e271828]

I got it. For future reference, one way to get the innerHTML source of
a page is to use the method document.documentElement.innerHTML . Since
there apparently aren't carriage returns after the page has been
rendered, the best way to split the HTML source by line number is to
put a document.documentElement.innerHTML.split("\n") onto the end.

Thanks for the suggestions Randy. I will have to postpone my suicidal
foray in Mozilla's XBL/XPCOM for another day.

-Eric

[e271828]

document.documentElement.innerHTML apparently parses the HTML into a
slightly (but significantly) different form, so it is not a solution to
finding the line numbers of a given HTML page.

The main problem with using innerHTML to find line numbers is that it
takes out any tabs and new lines between the opening and closing angle
brackets of a single tag. So the HTML source:

<div id="NavBar"
class="VerticalBarIcon"
onmouseover="document['asdf'].mouseover(this)"
onmousedown="document['fdsa'].mousedown(this)"
onmouseout="document['sdaf'].mouseout(this)" ></div>

returns, after innerHTML is applied, as:

<div id="NavBar" class="VerticalBarIcon"
onmouseover="document['asdf'].mouseover(this)"
onmousedown="document['fdsa'].mousedown(this)"
onmouseout="document['sdaf'].mouseout(this)" ></div>
This precludes the chance of breaking along the new lines of the actual
source, and presents a big problem. If anyone knows the general
direction I should go in to begin solving this, any advice would be
appreciated.

[Bart Van der Donck]

e271828 wrote:

document.documentElement.innerHTML apparently parses the HTML into a
slightly (but significantly) different form, so it is not a solution to
finding the line numbers of a given HTML page.

The main problem with using innerHTML to find line numbers is that it
takes out any tabs and new lines between the opening and closing angle
brackets of a single tag.
[...]

var file = 'e.html'; // file must exist!
var xmlhttp = false;
var counter = 0;
var theresult = '';

/*@cc_on @*/
/*@if (@_jscript_version >= 5)
try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (E) {
xmlhttp = false;
}
}
@end @*/
if (!xmlhttp && typeof XMLHttpRequest!='undefined') {
try {
xmlhttp = new XMLHttpRequest();
} catch (e) {
xmlhttp=false;
}
}
if (!xmlhttp && window.createRequest) {
try {
xmlhttp = window.createRequest();
} catch (e) {
xmlhttp=false;
}
}

xmlhttp.open('GET', file, true);
xmlhttp.onreadystatechange=function() {
if (xmlhttp.readyState==4) {
lines = (xmlhttp.responseText).split('\r\n')
for (var i=0; i<lines.length; ++i) {
++ counter
theresult = theresult + counter + ' ' + lines[i] + '\r\n'
}
alert(theresult)
}
}

xmlhttp.send(null)

--
Bart

[Richard Cornford]

Bart Van der Donck wrote:
<snip>

/*@cc_on @*/
/*@if (@_jscript_version >= 5)
try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (E) {
xmlhttp = false;
}
}
@end @*/
if (!xmlhttp && typeof XMLHttpRequest!='undefined') {
try {
xmlhttp = new XMLHttpRequest();
} catch (e) {
xmlhttp=false;
}
}
if (!xmlhttp && window.createRequest) {
try {
xmlhttp = window.createRequest();
} catch (e) {
xmlhttp=false;
}
}

xmlhttp.open('GET', file, true);

<snip>

Every one of the above branches includes the possibility that -
xmlhttp - will be set to boolean false, and as each is guarded in some
way none may be entered in some environments. Yet the call to - open -
is made on the assumption that the instantiation of the XML HTTP request
object was successful. This will have the code error-out in environments
such as IE with ActiveX disabled and any browser not supporting XML HTTP
requests in any form. Code that predictably may terminate with a runtime
error cannot be considered well designed. Partly because the in the
event that the user be shown an error message the site author's and
owners would look less than competent (so responsible, trustworthy,
reliable, etc.), but mostly because it denies the possibility of the
code failing under its own control and planned clean degradation.

Richard.

[Bart Van der Donck]

Richard Cornford wrote:

[...]
Every one of the above branches includes the possibility that -
xmlhttp - will be set to boolean false, and as each is guarded in some
way none may be entered in some environments. Yet the call to - open -
is made on the assumption that the instantiation of the XML HTTP request
object was successful. This will have the code error-out in environments
such as IE with ActiveX disabled and any browser not supporting XML HTTP
requests in any form. Code that predictably may terminate with a runtime
error cannot be considered well designed. Partly because the in the
event that the user be shown an error message the site author's and
owners would look less than competent (so responsible, trustworthy,
reliable, etc.), but mostly because it denies the possibility of the
code failing under its own control and planned clean degradation.

If this is true then the FAQ is wrong, since the routine comes straight
from http://www.jibbering.com/faq/#FAQ4_38.

--
Bart

[Michael Winter]

On 19/08/2006 14:01, Bart Van der Donck wrote:

Richard Cornford wrote:

>[...]
Every one of the above branches includes the possibility that -
xmlhttp - will be set to boolean false, and as each is guarded in some
way none may be entered in some environments. Yet the call to - open -
is made on the assumption that the instantiation of the XML HTTP request
object was successful. This will have the code error-out in environments
such as IE with ActiveX disabled and any browser not supporting XML HTTP
requests in any form. Code that predictably may terminate with a runtime
error cannot be considered well designed. Partly because the in the
event that the user be shown an error message the site author's and
owners would look less than competent (so responsible, trustworthy,
reliable, etc.), but mostly because it denies the possibility of the
code failing under its own control and planned clean degradation.

If this is true then the FAQ is wrong, since the routine comes straight
from http://www.jibbering.com/faq/#FAQ4_38.

No, /your application/ of code obtained from a resource /referenced/ by
the FAQ is wrong.

Nowhere did Jim write that the xmlhttp variable shouldn't be checked. In
fact, the paragraph that leads into the object creation code makes it
quite clear that such checks are important.

Don't blame others for your mistakes.

Mike

[Bart Van der Donck]

Michael Winter schreef:

On 19/08/2006 14:01, Bart Van der Donck wrote:

If this is true then the FAQ is wrong, since the routine comes straight
from http://www.jibbering.com/faq/#FAQ4_38.

No, /your application/ of code obtained from a resource /referenced/ by
the FAQ is wrong.

What would be this "correct application" of that code then ?

Nowhere did Jim write that the xmlhttp variable shouldn't be checked.

A little common sense, please. Why doesn't he just check it then in the
code ?

--
Bart

[Richard Cornford]

Bart Van der Donck wrote:

Richard Cornford wrote:

>[...]
Every one of the above branches includes the possibility
that - xmlhttp - will be set to boolean false, and as each
is guarded in some way none may be entered in some
environments. Yet the call to - open - is made on the
assumption that the instantiation of the XML HTTP request
object was successful. This will have the code error-out in
environments such as IE with ActiveX disabled and any
browser not supporting XML HTTP requests in any form. Code
that predictably may terminate with a runtime error cannot
be considered well designed. Partly because the in the event
that the user be shown an error message the site author's
and owners would look less than competent (so responsible,
trustworthy, reliable, etc.), but mostly because it denies
the possibility of the code failing under its own control
and planned clean degradation.

If this is true then the FAQ is wrong, since the routine
comes straight from http://www.jibbering.com/faq/#FAQ4_38.

No it doesn't. The code you posted is a concatenation of two separate
pieces of example code from a page referred to by the FAQ. The faults in
your posted code may follow from the unsuitability of 'the concatenation
of examples' as a code design strategy, but that does not mean they are
not present.

Richard.

[Michael Winter]

On 19/08/2006 15:24, Bart Van der Donck wrote:

Michael Winter schreef:

>On 19/08/2006 14:01, Bart Van der Donck wrote:

>>If this is true then the FAQ is wrong, since the routine comes straight
from http://www.jibbering.com/faq/#FAQ4_38.

No, /your application/ of code obtained from a resource /referenced/ by
the FAQ is wrong.

What would be this "correct application" of that code then ?

If an author needs to be told how to use an if statement, AJAX is far
beyond their means. That is a simplification, of course, but clean
degradation isn't a trivial implementation issue; it's a design
consideration.

>Nowhere did Jim write that the xmlhttp variable shouldn't be checked.

A little common sense, please.

A little common sense would have people read descriptions before getting
ahead of themselves and using code without thinking. Jim states that the
variable will evaluate to false if no suitable request object is
obtained. It should be clear that that is the most basic starting point.

Why doesn't he just check it then in the code ?

The code is separated by topic. The first part describes how to obtain a
request object. The following sections describe the sequence of method
calls used to perform a certain operation. It isn't meant to be taken as
a complete example, but rather separate code snippets.

Even if the code did seem "complete", that doesn't mean one should
disregard the warning to check for support first: examples are often
simplified to ensure that the operation that is demonstrated isn't
obscured by supporting code.

Mike

[Richard Cornford]

Bart Van der Donck wrote:

Michael Winter schreef:

>On 19/08/2006 14:01, Bart Van der Donck wrote:

>>If this is true then the FAQ is wrong, since the routine
comes straight from http://www.jibbering.com/faq/#FAQ4_38.

No, /your application/ of code obtained from a resource
/referenced/ by the FAQ is wrong.

What would be this "correct application" of that code then ?

There could be no single 'this "correct application" of that code', and
a comprehensive list of 'correct applications' would be an unrealistic
expectation (not least because of the subjectivity in the assessment of
correctness, but mostly because the context of application significantly
modifies the 'correct' strategy of use). However, there will not be many
contexts in which a script erroring-out at runtime would be considered
correct (intrinsic event handlers where failure in the event handler
directly results in page replacement (as a style of clean degradation)
may be the only possible exception, though I still would not encourage
the possibility of the user being shown an error message).

>Nowhere did Jim write that the xmlhttp variable shouldn't be
checked.

A little common sense, please.

Most appeals to "common sense" are made in support of bad ideas. (I am
often reminded of William Edgell's appeal to "common sense" in his 1927
defence of the idea of a flat Earth (<URL:
http://www.litotes.demon.co.uk/\dTeR...rthRotate.html >).)

Why doesn't he just check it then in the code ?

Is the subject of the page the behaviour of the XML HTTP request object
or is it general script design?

However, if the page did include specific examples of 'safe' employment
of the object those examples may be take as representing a definitive
strategy. In such small examples the tendency would be to wrap the test
around the code that actually used the object, while the bigger picture
may suggest some form of 'gateway' testing during page initialisation,
or a 'test on first use only' or 'Russian Doll' style of implementation,
particularly if multiple requests were to be expected on the same page.

Without a genuine context examples that do test for the availability of
features tend to test too far into the code (at the point where the
features is employed) and propose superficial and stupid responses to
failures (such as popping up some sort of "your browser does not support
this script" message). These examples get carried through to actual web
pages unaltered with sufficient frequency as to demonstrate that that
type of example can be as much of a hindrance to learning as an aid. In
practice designing for clean-degradation in response to negative results
from feature testing is so intimately linked to the context in which a
script is used that demonstrations of a single test and response
strategy are insufficient (even misleading).

Richard.