Firefox: correct xhtml DOCTYPE tag breaks script?

[Lennart]

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

[David Dorward]

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=p arseInt(p.style .width)+parseIn t(p.style.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

[Michael Winter]

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

[cwdjrxyz]

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.

[RobG]

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

[Richard Cornford]

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.

[Richard Cornford]

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.

[Lennart]

On Wed, 02 Aug 2006 23:29:47 +0100, David Dorward wrote:

>
p.style.width=p arseInt(p.style .width)+parseIn t(p.style.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??

[Michael Winter]

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 getComputedStyl e method
(properly; Konqueror has false support), and be awkward as IE uses a
different (and inferior) mechanism.

Mike

[cwdjrxyz]

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.