Request for tool

ab3331

I need a tool that acts like a browser, but instead of actually
rendering a page, it explains in English exactly what rules it's
interpreting. This would make it simple to see which rules are
applied, which are ignored, which are inherited or not, which are
superceded, etc. This would be a huge aid in debugging pages. (I
currently have a page that is included by another page - it's actually
a menu - but it's rendered differently depending on which other page
includes it. I'm utterly baffled as to why.)

The input could be any type of web page, including .html, .shtml and/
or others. It would interpret SSI of course, and maybe PHP, etc.
handling included files, as well as both external & inline css
styles. Like I mentioned above - it would act like a browser, but
specify in words what it would do instead of actually doing it. It
would need to have certain options, such as whether to render or not
to render (text, images), whether to render actual positions, or
simply output numbers as to where it would print (like XY coordinates,
as well as pixel positions, and/or other units potentially). Ideally
it would be interactive so you could shut off certain portions after
you had verified the problem wasn't in that portion of the code - or
perhaps simply set markers in the code as to which part of the code to
debug with this tool; or even give it 2 regular expressions to match
as the start and stop points. Note that it would still have to read
and interpret from the true beginning so as to set things up correctly
- start and stop would simply tell it where to start and stop
printing. In addition, I should be able to set a "dump point", where
all current values are printed out as well as how they were set.

Note, that this goes way beyond simple validation, and in fact really
has nothing to do with validation whatsoever - although in an ideal
world it could provide validation too, as an option.

Example Output:
Width set to 600px from <body>
background set to "sunrise.jpg" from <body>
border set to 1 using browser built-in rules.
Encountered <table class="webHead" width="780px" border="0"
cellspacing="0" cellpadding="0" font-size="100%" height="100%" >
background from <bodynot inherited. "sunrise.jpg" may still shine
through due to transparency.
Applying class="webHead" from file /public_html/Main/stuff.css
Applying class="webHead" from file /public_html/templates/
moreStuff.css
Setting webHead (moreStuff.css) width=900px
Setting webHead (stuff.css) border=1 pixel
Ignoring <table width="780px">, width is not inherited, class webHead
takes precedence
Setting <table border="0">
Setting <table cellspacing="0">
Ignoring <table cellpadding="0" Cellpadding is not supported by XX
browser version YY
Ignoring <table font-size="100%"font-size defaults to 10px based on
built-in browser rule.
Ignoring <table height="100%" Cellpadding is not supported by XX
browser version YY
Setting margin=0px using browser built-in rules.
Setting padding=0px using browser built-in rules
Encountered <tr>
Encountered <td>
Encountered [Hello World]
Rendering Hello World <<<<< This would be in actual font-family, size,
color, etc.
Encountered </td>
Encountered <dump point 1>
Border previously set to 0 at line 21 using <table border="0">
cellspacing previously set to 0 at line 21 using <table
cellspacing="0">
etc. etc.
Encountered </tr>
Encountered </table>
Border set to 1 using browser built-in rules

and so on and so forth until the entire file has been "rendered". The
above is (obviously) not a complete nor accurate example, but
hopefully it gets the point across. The tool would let you mimic the
behavior of different browsers as an option setting. Of interest to
me personally at the moment is IE 6 and 7. You could also choose an
option setting to either isolate, or integrate browsers, so that you
can compare the differences together, or simply focus on just one
browser. The above shows the output for one isolated browser. The
below shows integrated browsers.

Example:

Width set to 600px from <body>
background set to "sunrise.jpg" from <body>
border set to 1 using browser IE 6 built-in rules.
border set to 0 using browser IE 7 built-in rules.
border not set using browser firefox 1.0 built-in rules.
border set to 1 using Netscape 8 built-in rules.

etc.

Yet another example:

The following page is an official specification as you probably know:
http://www.w3.org/TR/REC-CSS2/fonts.html
It includes the following statement:

A visual user agent must address the following issues before actually
rendering a character:

Is there, directly or by inheritance, a font specified for this
character?
Does the user agent have this font available?
If so, what glyph(s) does this character or sequence of characters map
to?
If not, what should be done? Should a different font be substituted?
Can the font be synthesized? Can it be retrieved from the Web?

I would like to see the tool answer these (and other similar)
questions in respect to how the specific browser will treat these
questions. To demonstrate, the below responses to the questions would
be integrated into the above output in a natural way:

Is there, directly or by inheritance, a font specified for this
character?
The font "Arial" was specified by inheritance from class "foobar",
defined in file /path/to/file/foo.css

Does the user agent have this font available?
Since this browser does not have this font available in c:\windows
\fonts or c:\windows\system32\fonts...

If so, what glyph(s) does this character or sequence of characters map
to?
If not, what should be done? Should a different font be substituted?
Can the font be synthesized? Can it be retrieved from the Web?

the font 'Times Roman" was substituted from c:\windows\fonts
\timesr.fon
Essentially, it would give you a complete analysis of what it's doing,
where it's looking, why it made the decisions it made and what the
ultimate outcome ended up being.

I don't suppose there's anything like this out there is there?
Personally I don't care about the integrated version as of today, I
just need the isolated version, but I figure I might as well describe
the tool as completely as I can without writing a book. If there's
nothing out there, anyone care to take up the challenge? In my
opinion, this tool would be an enormous boon to the community at
large, and would probably help browser developers clean up their
browsers as well.

Thank you

Feb 27 '07 #1

Subscribe Post Reply

2304

Ben C

On 2007-02-27, ab****@gmail.com <ab****@gmail.comwrote:

I need a tool that acts like a browser, but instead of actually
rendering a page, it explains in English exactly what rules it's
interpreting. This would make it simple to see which rules are
applied, which are ignored, which are inherited or not, which are
superceded, etc. This would be a huge aid in debugging pages. (I
currently have a page that is included by another page - it's actually
a menu - but it's rendered differently depending on which other page
includes it. I'm utterly baffled as to why.)

[...]

and so on and so forth until the entire file has been "rendered". The
above is (obviously) not a complete nor accurate example, but
hopefully it gets the point across. The tool would let you mimic the
behavior of different browsers as an option setting. Of interest to
me personally at the moment is IE 6 and 7.

This requirement would be by far the hardest-- I don't think anyone even
knows exactly what IE6 and 7 do, let alone would be able to make sense
of it in a debugging trace.

[...]

Essentially, it would give you a complete analysis of what it's doing,
where it's looking, why it made the decisions it made and what the
ultimate outcome ended up being.

I don't suppose there's anything like this out there is there?

The easiest approach would be to get an open source browser like Firefox
or Konqueror and instrument the sources with debugging statements. The
sources probably do already contain a few such things which you'd
typically enable with a preprocessor macro.

But I'm not sure how useful it would be compared to all the excellent
"Developer Extensions" for Firefox, which can show you the box(es)
generated by an element and the styles that apply to that element and
where they came from, all in an interactive/graphical way.

It is also a very difficult task to get the level of verbosity right--
what might be useful information on one occasion might just be noise on
another. You can have different levels, and switches for the kind of
information you're interested in, but it's hard to get right.

Feb 27 '07 #2

ab3331

On Feb 27, 11:59 am, Ben C <spams...@spam.eggswrote:

On 2007-02-27, ab3...@gmail.com <ab3...@gmail.comwrote:

[...]

But I'm not sure how useful it would be compared to all the excellent
"Developer Extensions" for Firefox, which can show you the box(es)
generated by an element and the styles that apply to that element and
where they came from, all in an interactive/graphical way.

It is also a very difficult task to get the level of verbosity right--
what might be useful information on one occasion might just be noise on
another. You can have different levels, and switches for the kind of
information you're interested in, but it's hard to get right.

Thanks for responding. I have no desire to start a browsers war, but
as mentioned I'm looking for something ideally IE specific - not
because I love MS, but because my target audience is most likely to be
using IE. Also, someone ran a firefox developer tool on my site in
order to help me track down the problem. While it got some things
right, it totally missed other - important - things. What it appeared
to me is that it didn't really understand either the concept of
including other files, nor the concept of multiple declarations for
the same class. And that of course is precisely the issue I'm having
and trying to resolve. It also doesn't specify when something is set
by the browser itself, rather than being declared by CSS. The problem
results from the fact that I'm trying to integrate a third party
application into my site. There must be conflicting classes and/or
missing or additional rules somehow, somewhere but I cannot for the
life of me track it down.

In any event, I'm most interested in a tool that works the way I
described, as I don't think anything less is going to resolve my
problem; though I have no objection to it working graphically if that
makes the output more clear. But I thank you again for sharing your
thoughts.

Feb 27 '07 #3

Ben C

On 2007-02-27, ab****@gmail.com <ab****@gmail.comwrote:

On Feb 27, 11:59 am, Ben C <spams...@spam.eggswrote:
>On 2007-02-27, ab3...@gmail.com <ab3...@gmail.comwrote:

[...]

>But I'm not sure how useful it would be compared to all the excellent
"Developer Extensions" for Firefox, which can show you the box(es)
generated by an element and the styles that apply to that element and
where they came from, all in an interactive/graphical way.

It is also a very difficult task to get the level of verbosity right--
what might be useful information on one occasion might just be noise on
another. You can have different levels, and switches for the kind of
information you're interested in, but it's hard to get right.

Thanks for responding. I have no desire to start a browsers war, but
as mentioned I'm looking for something ideally IE specific - not
because I love MS, but because my target audience is most likely to be
using IE. Also, someone ran a firefox developer tool on my site in
order to help me track down the problem. While it got some things
right, it totally missed other - important - things. What it appeared
to me is that it didn't really understand either the concept of
including other files, nor the concept of multiple declarations for
the same class. And that of course is precisely the issue I'm having
and trying to resolve. It also doesn't specify when something is set
by the browser itself, rather than being declared by CSS. The problem
results from the fact that I'm trying to integrate a third party
application into my site. There must be conflicting classes and/or
missing or additional rules somehow, somewhere but I cannot for the
life of me track it down.

It could be differences in the bugs in both browsers-- sometimes CSS
parsing errors are used to switch properties based on different
combinations of browser bugs. Search for "Tantek hack" for the sort of
devious things people get up to. In your case the parse errors might not
be deliberate but could still be causing different properties to get
applied.

Another thing to check in these cases is if whole stylesheets are
missing. You might even need to check the server configuration-- what do
different browsers do if a stylesheet is incorrectly delivered with a
Content-Type of text/html?

Check of course that everything (CSS and HTML) is valid, because if it
isn't you can expect to see different results on browsers. Once it's
valid then you know you're mostly looking for bugs or differences of
opinion. Figure out how it _should_ look, using the specifications, and
then it should be easier to make sense of what's going on.

If you've got part of the site rewriting itself with JavaScript you've
potentially also got lots of DOM incompatibilities to sort out. One
approach is delete all the script tags and compare how the pages look--
the same, or all wrong, and if the latter, whether wrong in the same
way.

In any event, I'm most interested in a tool that works the way I
described, as I don't think anything less is going to resolve my
problem

The tool is a good idea, but to create it would require understanding
how the browser works. I think making such a tool would actually be a
very good exercise for the IE7 development team at Microsoft. The
problem is that his summer placement is almost over and he will have to
go back to university soon.

Feb 27 '07 #4

Dudely

On Feb 27, 2:36 pm, Ben C <spams...@spam.eggswrote:

On 2007-02-27, ab3...@gmail.com <ab3...@gmail.comwrote:

On Feb 27, 11:59 am, Ben C <spams...@spam.eggswrote:
On 2007-02-27, ab3...@gmail.com <ab3...@gmail.comwrote:

[...]

Another thing to check in these cases is if whole stylesheets are
missing.

Actually at one point I did in fact have a missing stylesheet. Fixed
that problem, still have the original problem.
You might even need to check the server configuration-- what do

different browsers do if a stylesheet is incorrectly delivered with a
Content-Type of text/html?

No idea how to do that.

What I neglected to mention I think, is that the piece of the website
that displays differently is using PHP calls interspersed with HTML.
No idea if or how that affects things.

One problem I recently tracked down is that I was using a font that
didn't exist on my system. Each of the two halves of the website were
using different font-families, and so each would default to using a
different font for the same text & page. Fixing that improved things,
and yet... the problem still remains.

The tool I described would of aided me in finding that problem because
it would of clearly stated "font not found. Using Tahoma" in one
spot, and "font not found. Using Arial" in another. Bingo. Problem
isolated in seconds or minutes instead of the hours it took me.

Check of course that everything (CSS and HTML) is valid, because if it
isn't you can expect to see different results on browsers. Once it's
valid then you know you're mostly looking for bugs or differences of
opinion. Figure out how it _should_ look, using the specifications, and
then it should be easier to make sense of what's going on.

Well, that's probably always a good idea, however I know that I'm
using things that are not necessarily supported by all browsers. Being
as how I'm using only one browser to check the results it's somewhat
irrelevant. I previously mentioned firefox because someone ran the FF
development tool to try and help me find the problem.

I found yet another problem in how table elements were being defined
between the two halves of the site. After fixing that, things
improved. Yet, the problem still remains...

If you've got part of the site rewriting itself with JavaScript you've
potentially also got lots of DOM incompatibilities to sort out.

While I do, do that in my index.html file I don't think that's the
issue here. It's relatively simple what I'm doing. But good call!

One

approach is delete all the script tags and compare how the pages look--
the same, or all wrong, and if the latter, whether wrong in the same
way.

That's a great idea. I assume by "script tags" you mean element
tags? i.e. <table<h1<p>, etc. However, the menu itself is
composed of pure css with some javascript. It relies on a .htc file
which I recently heard is an MS extension.

I think at this point the only thing I still need to look closely at
is the <bodytags which differ between the two halves of the site.
I've been afraid to muck with that, because I'm assuming that the
third party application knows what it's doing for itself, whereas I'm
just guessing. Plus I resolved the issue with a workaround that seems
to be acceptable - I have two different, virtually identical css files
which differ only in respect to font size for the menu element. Seems
to work so I put the whole thing aside in order to work on other parts
of the site.

In any event, I'm most interested in a tool that works the way I
described, as I don't think anything less is going to resolve my
problem

The tool is a good idea, but to create it would require understanding
how the browser works. I think making such a tool would actually be a
very good exercise for the IE7 development team at Microsoft. The
problem is that his summer placement is almost over and he will have to
go back to university soon.- Hide quoted text

I don't know who "he" is, but at this point I think I'd settle for the
tool I described, even if it was purely standards based. In other
words, if it revealed how a browser is *expected* to render based on
the standards, rather than how the browsers are actually rendering.
That would be a good starting point for the tool, and if the author
wanted to add in actual browsers later on then the enhancements would
be welcome. However it would still be a useful tool w/out showing how
browsers actually do it. Then we'd all at least know what things
should look like, and in fact the MS and other developers could use it
to get their browsers working right! They'd have a visual benchmark
to compare their results against. That way, some manager in QA could
look at it and say "hmmm.... why is this box rendered over here to the
left and top at (0,0), when this standards checker tool thingy renders
it in the middle at (50,50)? Bzzzt. You have a bug. Back to
development you go."

Those of us not developing browsers could use the tool to find bugs in
our code, as well as the effect of changing various values and in the
process become that much more knowledgable about css and html.

Mar 9 '07 #5

Rik

Dudely <ab****@gmail.comwrote:

On Feb 27, 2:36 pm, Ben C <spams...@spam.eggswrote:
>On 2007-02-27, ab3...@gmail.com <ab3...@gmail.comwrote:
Another thing to check in these cases is if whole stylesheets are
missing.

Actually at one point I did in fact have a missing stylesheet. Fixed
that problem, still have the original problem.

Enlighten me, I seem to be missing that original question.

>You might even need to check the server configuration-- what do
different browsers do if a stylesheet is incorrectly delivered with a
Content-Type of text/html?

Some bug indeed, most just issue an error and still use the css.

No idea how to do that.

What I neglected to mention I think, is that the piece of the website
that displays differently is using PHP calls interspersed with HTML.
No idea if or how that affects things.

It should not. The browser could care less(and doesn't know) how the HTML
is created. Makes absolutely no difference.

The tool I described would of aided me in finding that problem because
it would of clearly stated "font not found. Using Tahoma" in one
spot, and "font not found. Using Arial" in another. Bingo. Problem
isolated in seconds or minutes instead of the hours it took me.

>Check of course that everything (CSS and HTML) is valid, because if it
isn't you can expect to see different results on browsers. Once it's
valid then you know you're mostly looking for bugs or differences of
opinion. Figure out how it _should_ look, using the specifications, and
then it should be easier to make sense of what's going on.

Well, that's probably always a good idea, however I know that I'm
using things that are not necessarily supported by all browsers. Being
as how I'm using only one browser to check the results it's somewhat
irrelevant. I previously mentioned firefox because someone ran the FF
development tool to try and help me find the problem.

FireFox -FireBug is great

>If you've got part of the site rewriting itself with JavaScript you've
potentially also got lots of DOM incompatibilities to sort out.

While I do, do that in my index.html file I don't think that's the
issue here. It's relatively simple what I'm doing. But good call!

FF seems also to have the ability to view Generated Source, so you can
check wether JS is behaving correctly.

Now, if someone could restate the original question?
--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel

Mar 9 '07 #6

Ben C

On 2007-03-09, Rik <lu************@hotmail.comwrote:

Dudely <ab****@gmail.comwrote:
>On Feb 27, 2:36 pm, Ben C <spams...@spam.eggswrote:

[...]

>>You might even need to check the server configuration-- what do
different browsers do if a stylesheet is incorrectly delivered with a
Content-Type of text/html?

Some bug indeed, most just issue an error and still use the css.

I think it might actually be a quirks mode switch on FF.

http://developer.mozilla.org/en/docs..._Mode_Behavior

Stylesheets linked in the document with an advisory mime type of
text/css will still be treated as CSS even if the server gives a
Content-Type header other than text/css.

[...]

Now, if someone could restate the original question?

OP had tons of merged content from different sources that was all
horribly broken, so where to start, is roughly how I remember it.

Mar 9 '07 #7

Ben C

On 2007-03-09, Dudely <ab****@gmail.comwrote:

On Feb 27, 2:36 pm, Ben C <spams...@spam.eggswrote:
>On 2007-02-27, ab3...@gmail.com <ab3...@gmail.comwrote:

On Feb 27, 11:59 am, Ben C <spams...@spam.eggswrote:
On 2007-02-27, ab3...@gmail.com <ab3...@gmail.comwrote:

[...]

>Another thing to check in these cases is if whole stylesheets are
missing.

Actually at one point I did in fact have a missing stylesheet. Fixed
that problem, still have the original problem.
You might even need to check the server configuration-- what do
>different browsers do if a stylesheet is incorrectly delivered with a
Content-Type of text/html?

No idea how to do that.

Probably doesn't matter. Dollars to donuts IE doesn't bother too much
about the Content-Type for stylesheets anyway.

[...]

>One
approach is delete all the script tags and compare how the pages look--
the same, or all wrong, and if the latter, whether wrong in the same
way.

That's a great idea. I assume by "script tags" you mean element
tags? i.e. <table<h1<p>, etc.

I meant <script>.

Mar 9 '07 #8

Similar topics