Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problem in auto-generated HTML

0 views
Skip to first unread message

Jack Crenshaw

unread,
Jun 27, 2009, 11:41:02 AM6/27/09
to
I've encountered a problem with HTML files generated by Mathcad using
the "save as HTML" option. Among other things, Mathcad allows for text,
math, and graph objects. When I try to display the generated file in
Firefox, the equations overlay the preceding text.

The problem seems to be the use of constructs like this:

<div style="position:absolute;top:96;left:20">
<layer >
<img src="./Test File_images/IMG0003_62826203.PNG" border="0"/>
</layer>
</div>

It's the absolute address that seems to be the problem. I'd appreciate
comments and suggestions for a way to fix the problem. For example, why
not just substitute <p>...</p> blocks for the div sections?

For reasons I don't understand, Firefox and IE8 render the page
differently. IE has too much vertical space before the equation --
Firefox doesn't have enough.

Comments?

Jack

C A Upsdell

unread,
Jun 27, 2009, 1:24:21 PM6/27/09
to

One interesting aspect of the code you cite is the use of the <layer>
tag, a tag which is not HTML: it is a Netscape invention, not supported
since Netscape 4. So the code is quite archaic.

A second aspect is that the absolute block should be inside another
block that is positioned, e.g. using position:relative. The code you
cite does not indicate such an outer block exists.

A third aspect is that IE gets a lot of positioning wrong, so that
different behaviour is very possible with different versions of IE: and
if the code emitter was written when Netscape 4 was a major browser,
perhaps the other code (which you do not cite) was designed for archaic
versions of IE, and may not work with more modern, more standards
compliant versions.


David E. Ross

unread,
Jun 27, 2009, 1:36:49 PM6/27/09
to

Given Upsdell's comment on <layer>, I suggest you test the page at
<http://validator.w3.org/>. If Mathcad also creates style-sheets, that
should be tested at <http://jigsaw.w3.org/css-validator/>.

If you are getting excessive errors, you should consider a different
HTML generator. Alternatively, continue to use Mathcad, but then
manually correct the errors.

The presence of any HTML errors can cause different browsers to render a
page quite differently. Browsers are often coded to attempt to "guess"
what a Web author really meant when an error is detected, but different
browsers guess differently.

--

David E. Ross
<http://www.rossde.com/>.

Don't ask "Why is there road rage?" Instead, ask
"Why NOT Road Rage?" or "Why Is There No Such
Thing as Fast Enough?"
<http://www.rossde.com/roadrage.html>

Jack Crenshaw

unread,
Jun 27, 2009, 4:19:50 PM6/27/09
to C A Upsdell
C A Upsdell wrote:
> Jack Crenshaw wrote:
>> I've encountered a problem with HTML files generated by Mathcad using
>> the "save as HTML" option. Among other things, Mathcad allows for
>> text, math, and graph objects. When I try to display the generated
>> file in Firefox, the equations overlay the preceding text.
>>
>> The problem seems to be the use of constructs like this:
>>
>> <div style="position:absolute;top:96;left:20">
>> <layer >
>> <img src="./Test File_images/IMG0003_62826203.PNG" border="0"/>
>> </layer>
>> </div>
>>
>> It's the absolute address that seems to be the problem. I'd appreciate
>> comments and suggestions for a way to fix the problem. For example,
>> why not just substitute <p>...</p> blocks for the div sections?
>>
>> For reasons I don't understand, Firefox and IE8 render the page
>> differently. IE has too much vertical space before the equation --
>> Firefox doesn't have enough.
>>
>> Comments?
>
> One interesting aspect of the code you cite is the use of the <layer>
> tag, a tag which is not HTML: it is a Netscape invention, not supported
> since Netscape 4. So the code is quite archaic.

AHA!! That's the kind of thing I was looking for. Thanks.


>
> A second aspect is that the absolute block should be inside another
> block that is positioned, e.g. using position:relative. The code you
> cite does not indicate such an outer block exists.

Well, it's not. The hierarchy is

html/body/div/span/layer

The absolute addresses are inside the <span> tag, as I showed. And the
addresses really do seem to be absolute, not relative. As I progress
through the file, the top address continues to increase monotonically.


>
> A third aspect is that IE gets a lot of positioning wrong, so that
> different behaviour is very possible with different versions of IE: and
> if the code emitter was written when Netscape 4 was a major browser,
> perhaps the other code (which you do not cite) was designed for archaic
> versions of IE, and may not work with more modern, more standards
> compliant versions.

Ok. I think what you're telling me is, getting this file cleaned up is
going to be pert-near impossible. I was sort of hoping that I could
replace the <div> tags with <p> tags, or something equally painless.
Sounds like it's not going to happen.

Thanks very much for your input.

Jack
>
>

Jack Crenshaw

unread,
Jun 27, 2009, 4:44:22 PM6/27/09
to David E. Ross

Can't very well do that. It's built into Mathcad.

> Alternatively, continue to use Mathcad, but then
> manually correct the errors.

Thanks. For the record, I tried the simple expedient of replacing a few
of the <div> tags with <p> tags, and deleting the <layer> tags
completely. It "sorta" worked, in the sense that the elements now no
longer overlap each other. But the original file has multiple items on
the same line, so I've got to figure out how to do that.

Many thanks for the advice.

Jack

Jonathan N. Little

unread,
Jun 27, 2009, 4:48:53 PM6/27/09
to
Jack Crenshaw wrote:
> I've encountered a problem with HTML files generated by Mathcad using
> the "save as HTML" option. Among other things, Mathcad allows for text,
> math, and graph objects. When I try to display the generated file in
> Firefox, the equations overlay the preceding text.

Also not mentioned is that "style" properties created by this Mathcad
are invalid as well

>
> The problem seems to be the use of constructs like this:
>
> <div style="position:absolute;top:96;left:20">

^^ ^^
Position 96 what? Bananas? Left what?

If this snippet is any indication of the overall quality of the *whole*
page you may be lucky that it displays at all. Consistency would be just
luck.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Jukka K. Korpela

unread,
Jun 27, 2009, 5:07:17 PM6/27/09
to
Jonathan N. Little wrote:

>> The problem seems to be the use of constructs like this:
>>
>> <div style="position:absolute;top:96;left:20">
> ^^ ^^
> Position 96 what? Bananas? Left what?

The tricky part is that such CSS code "works" on some browsers in some
circumstances. That is, it has the effect that the author meant, even though
such behavior violates CSS specifications.

More exactly, some browsers (e.g., IE 8 in "quirks" mode) interpret the
numbers as numbers of pixels. More correct browsers (e.g., IE 7 in
"standards" mode) ignore the declarations top:96 and left:20 as required by
the specs.

> If this snippet is any indication of the overall quality of the
> *whole* page you may be lucky that it displays at all.

Indeed.

(I'd like to trim followups, as crossposting to three groups is seldom a
good idea. However, as usual in crossposted threads, _none_ of the groups is
the right one...)

--
Yucca, http://www.cs.tut.fi/~jkorpela/

Jack Crenshaw

unread,
Jun 27, 2009, 11:07:27 PM6/27/09
to Jonathan N. Little
Jonathan N. Little wrote:
> Jack Crenshaw wrote:
>> I've encountered a problem with HTML files generated by Mathcad using
>> the "save as HTML" option. Among other things, Mathcad allows for
>> text, math, and graph objects. When I try to display the generated
>> file in Firefox, the equations overlay the preceding text.
>
> Also not mentioned is that "style" properties created by this Mathcad
> are invalid as well
>
>>
>> The problem seems to be the use of constructs like this:
>>
>> <div style="position:absolute;top:96;left:20">
> ^^ ^^
> Position 96 what? Bananas? Left what?

Pixels. Which right off the bat seems like a Bad Idea, right?


>
> If this snippet is any indication of the overall quality of the *whole*
> page you may be lucky that it displays at all. Consistency would be just
> luck.

Yeah, this situation seems to be unsalvageable.

Thanks

Jack
>

Jack Crenshaw

unread,
Jun 27, 2009, 11:09:34 PM6/27/09
to Jukka K. Korpela

Sigh. What would we do without etiquette police?

Jack
>

C A Upsdell

unread,
Jun 28, 2009, 12:01:38 AM6/28/09
to
Jack Crenshaw wrote:
> Jonathan N. Little wrote:
>> Jack Crenshaw wrote:
>>> I've encountered a problem with HTML files generated by Mathcad using
>>> the "save as HTML" option. Among other things, Mathcad allows for
>>> text, math, and graph objects. When I try to display the generated
>>> file in Firefox, the equations overlay the preceding text.
>>
>> Also not mentioned is that "style" properties created by this Mathcad
>> are invalid as well
>>
>>>
>>> The problem seems to be the use of constructs like this:
>>>
>>> <div style="position:absolute;top:96;left:20">
>> ^^ ^^
>> Position 96 what? Bananas? Left what?
>
> Pixels. Which right off the bat seems like a Bad Idea, right?

NOT pixels. This is a absolutely crucial point: with CSS, the units
*must* be specified unless the value is zero, and if the units are
omitted with a non-zero value, the CSS is invalid, and should (according
to the standards) be ignored.

The problem is that IE traditionally does NOT ignore such CSS:
traditionally IE has assumed that the units are pixels if the units are
not specified, but this is simply wrong, and has resulted in IE
*apparently* displaying pages correctly when standards compliant
browsers do not.

The bottom line here is that MathCAD is apparently emitting seriously
defective code: code that will, in reality, appear to work only with
old versions of IE, or with modern versions of IE when quirks mode is
enabled.

You have every right to go back to MathCAD and to give them hell for
being so incompetent that it emits such terrible, defective code.


John Hosking

unread,
Jun 28, 2009, 4:14:15 AM6/28/09
to
F'up set to comp.infosystems.www.authoring.html

On Sat, 27 Jun 2009 16:19:50 -0400, Jack Crenshaw wrote:

> C A Upsdell wrote:
>> Jack Crenshaw wrote:
>>> I've encountered a problem with HTML files generated by Mathcad using
>>> the "save as HTML" option. Among other things, Mathcad allows for
>>> text, math, and graph objects. When I try to display the generated
>>> file in Firefox, the equations overlay the preceding text.
>>>
>>> The problem seems to be the use of constructs like this:
>>>
>>> <div style="position:absolute;top:96;left:20">
>>> <layer >
>>> <img src="./Test File_images/IMG0003_62826203.PNG" border="0"/>
>>> </layer>
>>> </div>
>>>
>>> It's the absolute address that seems to be the problem.

Do you mean that the img you've mentioned is the "equations," or "the
preceding text?" Is it overlapping by 20px? Where's the URL? Etc.

And I wouldn't call that an absolute address. Hmm, but see my comment at
the end about nomenclature.

>>> I'd appreciate
>>> comments and suggestions for a way to fix the problem. For example,
>>> why not just substitute <p>...</p> blocks for the div sections?
>>>
>>> For reasons I don't understand, Firefox and IE8 render the page
>>> differently.

I don't fully understand it either, because you haven't provided a sample
page. My bet is on the missing units, as mentioned by Jonathan, but it
could be other things, or some combination thereof.

...

>>
>> A second aspect is that the absolute block should be inside another
>> block that is positioned, e.g. using position:relative. The code you
>> cite does not indicate such an outer block exists.
>
> Well, it's not. The hierarchy is
>
> html/body/div/span/layer
>
> The absolute addresses are inside the <span> tag, as I showed.

Actually, you've shown that there *isn't* a span element. (I know you meant
"element" even though you said "tag.")

> And the
> addresses really do seem to be absolute, not relative. As I progress
> through the file, the top address continues to increase monotonically.

After spending some time studying your posts and replies, I now think
there's a bit of a nomenclature problem. You keep talking about "absolute
addresses" as opposed to "relative addresses." Such terms seem to me to
have to do with URIs, like your "./Test File_images/IMG0003_62826203.PNG"
in the pasted code snipplet above. (That'd be a relative address, AFAIAC,
since it's relative to whatever domain the page is in.)

The *addresses* are however different from *positioning*, which Mr. Upsdell
is trying to point you to. The div you've shown us is claiming to be
absolutely positioned (you've declared position:absolute; inline), but as
Brother Upsdell says, that'll only have an effect if the absolutely
positioned block is inside a relatively positioned block. Based on your
statements about hierarchy, that'd mean you want to declare

body {position:relative;}

in the CSS.

Does any of that help?

--
John

Ben C

unread,
Jun 28, 2009, 4:41:54 AM6/28/09
to
On 2009-06-28, C A Upsdell <cups...@nospam.not> wrote:
> Jack Crenshaw wrote:
>> Jonathan N. Little wrote:
>>> Jack Crenshaw wrote:
>>>> I've encountered a problem with HTML files generated by Mathcad using
>>>> the "save as HTML" option. Among other things, Mathcad allows for
>>>> text, math, and graph objects. When I try to display the generated
>>>> file in Firefox, the equations overlay the preceding text.
>>>
>>> Also not mentioned is that "style" properties created by this Mathcad
>>> are invalid as well
>>>
>>>>
>>>> The problem seems to be the use of constructs like this:
>>>>
>>>> <div style="position:absolute;top:96;left:20">
>>> ^^ ^^
>>> Position 96 what? Bananas? Left what?
>>
>> Pixels. Which right off the bat seems like a Bad Idea, right?
>
> NOT pixels. This is a absolutely crucial point: with CSS, the units
> *must* be specified unless the value is zero, and if the units are
> omitted with a non-zero value, the CSS is invalid, and should (according
> to the standards) be ignored.
>
> The problem is that IE traditionally does NOT ignore such CSS:
> traditionally IE has assumed that the units are pixels if the units are
> not specified, but this is simply wrong, and has resulted in IE
> *apparently* displaying pages correctly when standards compliant
> browsers do not.

I think they mostly allow that to mean pixels in quirks mode, which my
guess is this content is going to be in (if you're clueless enough to
emit crap like that you probably don't emit a DOCTYPE at all).

So although it's wrong, my money is on it not being the cause of the
problem here.

Jukka K. Korpela

unread,
Jun 28, 2009, 6:39:25 AM6/28/09
to
Jack Crenshaw wrote:

> Sigh. What would we do without etiquette police?

We could surely do without a [censored] who fullquotes and then adds an
AOL-class one-liner pointless stupidity, and both posts and emails without
saying that.

F'ups set.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

0 new messages