By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,719 Members | 1,875 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,719 IT Pros & Developers. It's quick & easy.

Firefox: correct xhtml DOCTYPE tag breaks script?

P: n/a
Hi folks,

I have created an animated image gallery in dhtml. It works fine in
Internet Explorer. In Firefox, it only works if I ommit the DOCTYPE tag.
The page is valid xhtml-strict but with a xhtml1-strict DOCTYPE, I get a
dead script and dozens of error messages like "Error in parsing value in
property 'width'. Declaration dropped." on Line 0.

This page doesn't work in Firefox but is valid xhtml:
http://schorpioen.demon.nl/test/gallery.html

This page works in Firefox but has no document type so doesn't validate:
http://schorpioen.demon.nl/test/gallery_no_doctype.html

What's happening?

Thanks for any insights,

Lennart
Aug 2 '06 #1
Share this Question
Share on Google+
15 Replies


P: n/a
Lennart wrote:
I have created an animated image gallery in dhtml. It works fine in
Internet Explorer. In Firefox, it only works if I ommit the DOCTYPE tag.
The page is valid xhtml-strict but with a xhtml1-strict DOCTYPE, I get a
dead script and dozens of error messages like "Error in parsing value in
property 'width'. Declaration dropped." on Line 0.
A number of browsers look at the Doctype and use it to judge how smart you
are. If they think you are smart they are less forgiving when it comes to
errors in CSS.
This page doesn't work in Firefox but is valid xhtml:
http://schorpioen.demon.nl/test/gallery.html
p.style.width=parseInt(p.style.width)+parseInt(p.s tyle.width)*zoomfactor*p.prefix;

So you are assigning to the width property "An integer, multiplied by an
interger, multiplied by the zoom factor, multiplied by either 1 or -1"

.... but in CSS non-zero lengths require units.

width: 50; is not acceptable.

--
David Dorward <http://blog.dorward.me.uk/ <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Aug 2 '06 #2

P: n/a
On 02/08/2006 22:38, Lennart wrote:
I have created an animated image gallery in dhtml. It works fine in
Internet Explorer. In Firefox, it only works if I ommit the DOCTYPE tag.
The page is valid xhtml-strict but with a xhtml1-strict DOCTYPE, I get a
dead script and dozens of error messages like "Error in parsing value in
property 'width'. Declaration dropped." on Line 0.
Your CSS declarations are invalid; you're omitting units, which are
always required for non-zero length values.
This page doesn't work in Firefox but is valid xhtml:
http://schorpioen.demon.nl/test/gallery.html
You're also calling parseInt without specifying an explicit radix, which
isn't typically a good idea. My examination didn't stretch much further
than that.

[snip]

Mike
Aug 2 '06 #3

P: n/a

Lennart wrote:
I have created an animated image gallery in dhtml. It works fine in
Internet Explorer. In Firefox, it only works if I ommit the DOCTYPE tag.
The page is valid xhtml-strict but with a xhtml1-strict DOCTYPE, I get a
dead script and dozens of error messages like "Error in parsing value in
property 'width'. Declaration dropped." on Line 0.

This page doesn't work in Firefox but is valid xhtml:
http://schorpioen.demon.nl/test/gallery.html

This page works in Firefox but has no document type so doesn't validate:
http://schorpioen.demon.nl/test/gallery_no_doctype.html
The recent Mozilla family browsers become much more strict when you use
either xhtml 1.0 strict or html 4.01 strict. I find that the dhtml on
your page will not work either when the page is converted to html 4.01
strict. By the way, your page will work as written on Opera. If you
convert your page to html 4.01 transitional, Mozilla family browsers
become more loose and the html on your page will then validate at W3C
and work on recent versions of IE6, Opera, Firefox, Netscape, and
Mozilla. See http://www.cwdjr.info/dhtml/dhtmlPost.html .

So the easy way out is to just use html 4.01 transitional. I have seen
this same response by recent Mozilla family browsers many times for
older dhtml pages. In several cases, I have found that math is being
used to calculate some screen positions in pixels. If the numerical
result for the desired x or y position is not rounded using
Math.round(), a fractional pixel position may be calculated. IE6 and
Opera often do not mind this. However a fractional pixel position often
can completely kill the dhtml effect on recent Mozilla family browsers.
So, if you insist on code in strict html or strict xhtml, then first
start by carefully examining if any of the several calculations used in
your script can result in fractional pixel screen positions, and use
Math.round() or whatever else it may take to get rid of the fractions.
Of course the problem could be something else. Many things can kill a
dhtml script.

Aug 3 '06 #4

P: n/a

cwdjrxyz wrote:
[...]
So, if you insist on code in strict html or strict xhtml, then first
start by carefully examining if any of the several calculations used in
your script can result in fractional pixel screen positions, and use
Math.round() or whatever else it may take to get rid of the fractions
As a hint, one trick is to truncate the decimal part using bitwise OR:

var z = (x/y) | 0;

e.g. to get an integer random number in the range 0 to 4:

Math.random()*4 | 0;
It's often used where a function is called repeatedly at very short
intervals. It's much faster and less processor intensive than
repeatedly calling Math.round(), but of course truncation may not suit
the OP and the speed advantage may be irrelevant.

--
Rob

Aug 3 '06 #5

P: n/a
cwdjrxyz wrote:
<snip>
The recent Mozilla family browsers become much more strict
when you use either xhtml 1.0 strict or html 4.01 strict.
I find that the dhtml on your page will not work either when
the page is converted to html 4.01 strict. By the way, your
page will work as written on Opera. If you convert your page
to html 4.01 transitional, Mozilla family browsers become
more loose and the html on your page will then validate at
W3C and work on recent versions of IE6, Opera, Firefox,
Netscape, and Mozilla.
See http://www.cwdjr.info/dhtml/dhtmlPost.html .
<snip>

This is false. The distinction between (x)HTML strict and transitional
is not a factor in whether the browser renders in 'quirks' or
'standards' mode. If the page uses a formally correct (x)HTML
transitional DOCTYPE (as defined in the pertinent W3C specification)
then the browser in question will render in 'standards' mode and the
script will not work due to the absence of unit declarations in the
assigned CSS values.

Richard.
Aug 3 '06 #6

P: n/a
RobG wrote:
cwdjrxyz wrote:
[...]
>So, if you insist on code in strict html or strict xhtml,
then first start by carefully examining if any of the several
calculations used in your script can result in fractional
pixel screen positions, and use Math.round() or whatever
else it may take to get rid of the fractions

As a hint, one trick is to truncate the decimal part using
bitwise OR:

var z = (x/y) | 0;
<snip>
It's often used where a function is called repeatedly at
very short intervals. ...
<snip>

True, but CSS pixel units are not required to be integers so the
implication that the use of non-integers will influence the outcome on
Firefox is bogus.

Richard.
Aug 3 '06 #7

P: n/a
On Wed, 02 Aug 2006 23:29:47 +0100, David Dorward wrote:
>
p.style.width=parseInt(p.style.width)+parseInt(p.s tyle.width)*zoomfactor*p.prefix;

So you are assigning to the width property "An integer, multiplied by an
interger, multiplied by the zoom factor, multiplied by either 1 or -1"

... but in CSS non-zero lengths require units.

width: 50; is not acceptable.


Ok, but I also need to read out the width and height of pictures, f.e.
with:

w = p.style.width;

And I assume that I get an integer back, not a string like "200px" or
anything else I can't really do calculations with. In fact with the xhtml
doctype in place, p.style.width is always *empty*, how do I solve that??

Aug 3 '06 #8

P: n/a
On 03/08/2006 13:01, Lennart wrote:
On Wed, 02 Aug 2006 23:29:47 +0100, David Dorward wrote:
[snip]
>... but in CSS non-zero lengths require units.

width: 50; is not acceptable.

Ok, but I also need to read out the width and height of pictures, f.e.
with:

w = p.style.width;
The style object represents in-line style sheet declarations; either
those assigned via scripting using the style object itself, or those
included in a style attribute.
And I assume that I get an integer back, not a string like "200px" or
anything else I can't really do calculations with.
Your assumption is wrong. The return value should be a string and, with
the exception of a zero length value (and not necessarily then), it
should include a unit.

The parseInt function will ignore trailing characters that aren't part
of the set of digits for the specified radix. That is,

parseInt("200px", 10)

will return the number 200 as 'p' isn't a base-10 digit.
In fact with the xhtml doctype in place,
Serving XHTML as HTML is questionable anyway, but the issues are not
restricted to XHTML.
p.style.width is always *empty*, how do I solve that??
See above.

One alternative is to compute the value. However, that would limit
support as only a few browsers implement the getComputedStyle method
(properly; Konqueror has false support), and be awkward as IE uses a
different (and inferior) mechanism.

Mike
Aug 3 '06 #9

P: n/a

Richard Cornford wrote:
RobG wrote:
cwdjrxyz wrote:
[...]
So, if you insist on code in strict html or strict xhtml,
then first start by carefully examining if any of the several
calculations used in your script can result in fractional
pixel screen positions, and use Math.round() or whatever
else it may take to get rid of the fractions
As a hint, one trick is to truncate the decimal part using
bitwise OR:

var z = (x/y) | 0;
<snip>
It's often used where a function is called repeatedly at
very short intervals. ...
<snip>

True, but CSS pixel units are not required to be integers so the
implication that the use of non-integers will influence the outcome on
Firefox is bogus.
I have seen many cases where older dhtml scripts fail on recent Mozilla
family browsers, including Firefox, when fractional pixel positions are
calculated and html 4.01 strict is used. Making sure that intergers are
used instead corrected the problem when there were not additional
problems on the page.. It may be true that CSS pixel units may not be
required to be integrals in some official specifications. However
recent Mozilla family browsers do not seem to know this in some cases
when you use html 4.01 strict, for example. Yet it does not seem to
matter if you convert the page to html 4.01 transitional. Pages with
such problems have been written by several authors. Have you actually
tested this on working pages? If not, using the term "bogus" is not
justified, in my opinion.

Aug 3 '06 #10

P: n/a
cwdjrxyz wrote:
Richard Cornford wrote:
<snip>
>>It's often used where a function is called repeatedly
at very short intervals. ...
<snip>

True, but CSS pixel units are not required to be integers
so the implication that the use of non-integers will
influence the outcome on Firefox is bogus.

I have seen many cases
Rumours hand hearsay. Be specific.
where older dhtml scripts fail on
recent Mozilla family browsers,
So you say, but then say a great deal. If this were the case a small
test case page could be posted along with a statement as to which
Mozilla/Gecko browsers have a problem.
including Firefox, when fractional pixel
positions are calculated and html 4.01 strict is used.
The only likely issue with using non-integers with CSS assignments would
be where those vales were represented in exponential format, as CSS does
not tolerate that. However, numbers large enough to need exponential
representation when type-converted from javascript numeric type to
strings would be too large for practical application as CSS values,
leaving only numbers close to zero as potentially problematic. And of
course exponental formats being used for CSS valeus could not be an
issue related to either rendering mode or the DTD version referenced in
the DOCTYPE processing instruction.

And I will say it again as you obviously missed the point: the DTD
referenced (strict or transitional) in a DOCTYPE declaration does not
influence the behaviour of browsers. The behaviour of browsers in this
regard is influenced by the structure/format of DOCTYPE declarations,
and formally correct DOCTYPEs referencing either of the strict or
transitional DTDs will result in DOCTYPE switching browsers operating in
'standards' mode.
Making sure
that intergers are used instead corrected the problem when
there were not additional problems on the page..
Your claim here is that there is code that there is code that writes
non-integer vales to style properties which fails to work in only some
Mozilla/Gecko versions and only when a strict DTD is referenced in the
DOCTYPE. That should not be difficult claim to demonstrate, but I won't
be holding my breath.
It may be true that CSS pixel units may not be required
to be integrals in some official specifications.
It unambiguously is true.
However recent Mozilla family browsers do not seem to
know this in some cases when you use html 4.01 strict,
for example.
That statement is not any more true the second time you say it.
Yet it does not seem to matter if you convert the page to
html 4.01 transitional.
What doe not matter?
Pages with such problems have been written by several
authors.
I don't doubt that pages with problems have been written by many
authors, but I don't trust you ability to analyse their issues and
identify cause and effect relationships to the extent that what you have
said here represents actual knowledge. The absence of any demonstration
will make that point.
Have you actually tested this on working pages?
Yes, have you?
If not, using the term "bogus" is not justified,
in my opinion.
And last time we conversed you didn't think hypocrite was justified.

Richard.
Aug 3 '06 #11

P: n/a

cwdjrxyz wrote:
I have seen many cases where older dhtml scripts fail on recent Mozilla
family browsers, including Firefox, when fractional pixel positions are
calculated and html 4.01 strict is used. Making sure that intergers are
used instead corrected the problem when there were not additional
problems on the page.. It may be true that CSS pixel units may not be
required to be integrals in some official specifications. However
recent Mozilla family browsers do not seem to know this in some cases
when you use html 4.01 strict, for example. Yet it does not seem to
matter if you convert the page to html 4.01 transitional. Pages with
such problems have been written by several authors.
I believe you can find a few such pages at Dynamic drive. However, I
have found something even more interesting. Compare my two pages at
http://www.cwdjr.net/geometricDraw/r..._gradient.html and
http://www.cwdjr.net/geometricDraw/r...ient_test.html .

In brief, if you do not round calculated rgb color values and get
fractions, then the script is completely killed on recent Mozilla
family browsers(I used Firerfox that just downloaded a new update last
night.) However IE6, and the most recent version of Opera had no
problem with the fractional color values. In this case you get the
problem on html 4.01 strict as used here and on a html 4.01
transitional page.

Aug 4 '06 #12

P: n/a
cwdjrxyz wrote:
cwdjrxyz wrote:
>I have seen many cases where older dhtml scripts fail on
recent Mozilla family browsers, including Firefox, when
fractional pixel positions are calculated and html 4.01
strict is used. ...
<snip>
I believe you can find a few such pages at Dynamic drive.
You believe? Post actual code that backs up the bogus claim you make
above and state the Mozilla/Gecko versions that exhibit the issue and it
stops being a question of belief and becomes a matter of fact.
However, I
have found something even more interesting. ...
<snip>
In brief, if you do not round calculated rgb color ...
Unlike pixel Number values, CSS defines RGB values as "either three
integer values or three percentage values" so finding a browser that is
expecting non-percentage value to be integers is not much of an
achevement.

Your claim was that some Mozilla/Gecko versions would not cope with
non-integer pixel values, rgb color values are an attempt at
misdirection, but irrelevant as they are specified as integers.

<snip>
... . In this case you get the problem on html 4.01
strict as used here and on a html 4.01
transitional page.
That would be the case as the DTD referred to in a DOCTYPE declaration
is not a factor effecting the behaviour of web browsers.

Richard.
Aug 4 '06 #13

P: n/a

cwdjrxyz wrote:
cwdjrxyz wrote:
I believe you can find a few such pages at Dynamic drive. However, I
have found something even more interesting. Compare my two pages at
http://www.cwdjr.net/geometricDraw/r..._gradient.html and
http://www.cwdjr.net/geometricDraw/r...ient_test.html .

In brief, if you do not round calculated rgb color values and get
fractions, then the script is completely killed on recent Mozilla
family browsers(I used Firerfox that just downloaded a new update last
night.) However IE6, and the most recent version of Opera had no
problem with the fractional color values. In this case you get the
problem on html 4.01 strict as used here and on a html 4.01
transitional page.
It should be noted that positions for display on a screen must use
ordinary Cartesian coordinates in a non-standard system(the left
position corresponds to the usual x direction, but the top position
points down from the top and is in the negative direction to the usual
y). However for many calculations are best done in another coordinate
system, which was the case in my example. Since a gradient of color was
desired as a function of radius only of a circle, the natural
coordinate system is polar coordinates with the origin at the center of
the circle, with a radius coordinate and an angular coordinate, so
calculations are done in polar coordinates. The red and blue values as
a function of radius to be used in rgb colors can turn out to be
fractional in the most convenient coordinate system used for the
calculations. Hence they should be rounded and the script fails for
recent Mozilla family browsers if this is not done. Also x and y
positions that must be used in the Cartesian system that the browser
understands for screen display will be fractional when convereted from
polar to Cartesian. In brief, if you are calcuating some function of
position that can result in in fractional x,y coordinates and
fractional values for the calculated function, you must round the
calculated function values if some browser does not take kindly to
fractions for something such as rgb color. If you have trouble with
this sort of page inspection for fractional function value and
coordinate outputs is a good place to start.

In the case of rgb colors, of course fractions are not used. However a
real world browser must be prepared to handle things without undue
problems if it does get a fraction. Apparently for r,g,b color values,
IE6 and Opera default to a rounded off value which saves the
calculation. However recent Mozilla family browsers apparently do
something else that kills the script, but at least it does not cause a
crash. How to handle this sort of thing is a choice that each browser
vendor must make. In other words, for most ordinary PC users, a very
user friendly approach is more likely to win in the market. I know that
a major petroleum company where I live used Netscape 4 browsers several
years ago. Their non-technical users complained how easily the Netscape
browsers hung up, crashed, etc. The company replaced the Netscape
browsers with IE(probably 5 at that time). The computer department got
many favorable responses from non-technical users. Present day Mozilla
family browsers comply with standards better than many other browsers.
They dropped document.layers. Microsoft and Opera still support
document.all. However, Mozilla family still supports embed that never
was an offical W3C tag. I suspect that if they booted embed that they
would lose a lot of users of their browsers, so they are just being
practical. I have heard that dropping document.layers caused quite a
few complaints from people who did not want to rewrite code in the
modern document.getElementById manner.

Aug 4 '06 #14

P: n/a
JRS: In article <11**********************@s13g2000cwa.googlegroups .com>
, dated Wed, 2 Aug 2006 20:52:48 remote, seen in
news:comp.lang.javascript, RobG <rg***@iinet.net.auposted :
>
As a hint, one trick is to truncate the decimal part using bitwise OR:

var z = (x/y) | 0;

e.g. to get an integer random number in the range 0 to 4:

Math.random()*4 | 0;
Range 0 to 3 (inclusive), except in some versions of Opera where AIUI 4
may occasionally occur.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.
Aug 4 '06 #15

P: n/a
cwdjrxyz wrote:
<snip>
It should be noted that positions for display on a screen
must use ordinary Cartesian coordinates in a non-standard
system(the left position corresponds to the usual x direction,
but the top position points down from the top and is in the
negative direction to the usual y).
CSS positioning does not use a Cartesian co-ordinate system at all (even
a vertically flipped one). CSS positions elements with values for -
top -, - left -, - right - and - bottom -. The choice of which set of
values re used to position an element is essentially arbitrary, with -
top - and - left - the sensible choice for scripts when you don't want
to be worrying about how tall or wide a document, or window, is
(particularly as both are variable).

<snip>
In the case of rgb colors, of course fractions are not used.
However a real world browser must be prepared to handle things
without undue problems if it does get a fraction. Apparently
for r,g,b color values, IE6 and Opera default to a rounded off
value which saves the calculation. However recent Mozilla
family browsers apparently do something else that kills the
script,
Yes, they expect the values provided for rgb color CSS vales to be in
the form specified in CSS.
but at least it does not cause a crash. How to handle this
sort of thing is a choice that each browser vendor must
make.
The general axiom 'be strict in what you send and tolerant of what you
accept' is perhaps applicable. Opera and IE are more tolerant than
Mozilla, that is hardly a new observtion.
In other words, for most ordinary PC users,
"Users"? How many PC 'users' set CSS values in any browsers? If there is
an issue here it is an issue for web develpers/designers.
a very user friendly approach is more likely to win in
the market.
The axiom cuts both ways. The web developer is creating what is sent so
(s)he should be being strict, and so know what types of values should be
sent so they can ensure that they re only sending those values.

<snip>
Present day Mozilla family browsers comply with standards
better than many other browsers. They dropped document.layers.
Microsoft and Opera still support document.all.
<snip>

Mozilla now also supports - document.all - as a concession to IE centric
web developers who where not willing to learn to move to cross-browser
scripting.

I assume that no scripts are going to be presented that will support
your "I have seen many cases where older dhtml scripts fail on recent
Mozilla family browsers, including Firefox, when fractional pixel
positions are calculated and html 4.01 strict is used", and that you
will not be admitting that you were mistaken. This misdirection into
areas not even vaguely connected with the original question is not
fooling anyone.

Richard.
Aug 7 '06 #16

This discussion thread is closed

Replies have been disabled for this discussion.