Trouble getting page to work in FireFox

[=?Utf-8?B?Sm9obiBCYWlsZXk=?=]

I have a ASP .Net page that allows moving around items on the page through
javascript. This page works fine in IE.

In FireFox however, I have found that if the page is using XHTML 1.0
Transitional as the doctype, you cannot set the style.left and style.top
properties of image or div tags. If you remove the doctype from the page it
works just fine, although I would rather not do this. You can work around
this by setting the cssText property directly (which works in both browsers),
but I now have the annoying issue of having to fix up the cssText.

Does anyone know if this is a feature of the XHTML 1.0 Transitional
specification or if it is an anoying bug in FireFox?

Thanks in advance.

[=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=]

John Bailey wrote:

I have a ASP .Net page that allows moving around items on the page through
javascript. This page works fine in IE.

In FireFox however, I have found that if the page is using XHTML 1.0
Transitional as the doctype, you cannot set the style.left and style.top
properties of image or div tags. If you remove the doctype from the page it
works just fine, although I would rather not do this. You can work around
this by setting the cssText property directly (which works in both browsers),
but I now have the annoying issue of having to fix up the cssText.

Does anyone know if this is a feature of the XHTML 1.0 Transitional
specification or if it is an anoying bug in FireFox?

Thanks in advance.

I use the same doctype, and have never had the problems that you describe.

There is nothing that prevents you from setting style.left and style.top
on elements, but naturally you also have to make the elements absolutely
or relatively positioned for the properties to have any effect.

The cssText property is non-standard. I would advice against using it.

--
Göran Andersson
_____
http://www.guffa.com

[=?Utf-8?B?Sm9obiBCYWlsZXk=?=]

Actually I figured it out. As it turns out, it was the placement of the
doctype tag itself. In the test page I had the doctype placed before a page
style element. Style elements cannot be inside other elements according to
the spec, which basically means they have to be the first thing on the page.
FireFox doesn't seem to like the misplacement although all other browsers did
not seem to care, and the symptom was particularly odd. Once I moved the
doctype tag to after the closing style tag the page worked without issue.

I have the two pages in a test bed:
Broken page
http://www.baileysw.com/testing/dragdroptest.htm

Working page
http://www.baileysw.com/testing/workingdragdrop.htm

You'll notice that the only difference between them is the placement of the
doctype element.

Oddly, since I only use page level style elements in test pages (as apposed
to css in production pages) I would not have seen this in production at all.

This is by far one of the weirdest behaviors I have seen though.
"Göran Andersson" wrote:

John Bailey wrote:

I have a ASP .Net page that allows moving around items on the page through
javascript. This page works fine in IE.

In FireFox however, I have found that if the page is using XHTML 1.0
Transitional as the doctype, you cannot set the style.left and style.top
properties of image or div tags. If you remove the doctype from the page it
works just fine, although I would rather not do this. You can work around
this by setting the cssText property directly (which works in both browsers),
but I now have the annoying issue of having to fix up the cssText.

Does anyone know if this is a feature of the XHTML 1.0 Transitional
specification or if it is an anoying bug in FireFox?

Thanks in advance.

I use the same doctype, and have never had the problems that you describe.

There is nothing that prevents you from setting style.left and style.top
on elements, but naturally you also have to make the elements absolutely
or relatively positioned for the properties to have any effect.

The cssText property is non-standard. I would advice against using it.

--
Göran Andersson
_____
http://www.guffa.com

[Damien]

On Mar 28, 3:07 am, John Bailey <[e-mail]>
wrote:

Actually I figured it out. As it turns out, it was the placement of the
doctype tag itself. In the test page I had the doctype placed before a page
style element. Style elements cannot be inside other elements according to
the spec, which basically means they have to be the first thing on the page.
FireFox doesn't seem to like the misplacement although all other browsers did
not seem to care, and the symptom was particularly odd. Once I moved the
doctype tag to after the closing style tag the page worked without issue.

I have the two pages in a test bed:
Broken pagehttp://www.baileysw.com/testing/dragdroptest.htm

Working pagehttp://www.baileysw.com/testing/workingdragdrop.htm

You'll notice that the only difference between them is the placement of the
doctype element.

Oddly, since I only use page level style elements in test pages (as apposed
to css in production pages) I would not have seen this in production at all.

This is by far one of the weirdest behaviors I have seen though.

Um, shouldn't the style element be inside the head element?

Certainly this part of the XHTML transitional DTD:

<!ELEMENT html (head, body)>
<!ATTLIST html
%i18n;
id ID #IMPLIED
xmlns %URI; #FIXED 'http://www.w3.org/1999/xhtml'

>

<!--================ Document Head
=======================================-->

<!ENTITY % head.misc "(script|style|meta|link|object|isindex)*">

<!-- content model is %head.misc; combined with a single
title and an optional base element in any order -->

<!ELEMENT head (%head.misc;,
((title, %head.misc;, (base, %head.misc;)?) |
(base, %head.misc;, (title, %head.misc;))))>

says that style is an optional element within head.

Damien

[=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=]

Actually both your pages are broken.

The doctype tag has to be the first tag in the page, or it will be
ignored. If you check the page information (in Firefox) of the page that
you called "Working page", it's displayed using Quirks mode. This
basically means that the browser reverts to a behaviour that tries to do
the best out of badly formed markup.

In Internet Explorer the Quirks mode can be rather devestationg. It
throws the browser in a kind of version 4 compatible mode, which messes
up the box model (padding, margin and size in css) as that version badly
misinterpreted it.

The style tag should be inside the head tag. I think that you have
confused "elements" with "tags". The head tag is not an element in the
page, the elements are inside the body tag.

John Bailey wrote:

Actually I figured it out. As it turns out, it was the placement of the
doctype tag itself. In the test page I had the doctype placed before a page
style element. Style elements cannot be inside other elements according to
the spec, which basically means they have to be the first thing on the page.
FireFox doesn't seem to like the misplacement although all other browsers did
not seem to care, and the symptom was particularly odd. Once I moved the
doctype tag to after the closing style tag the page worked without issue.

I have the two pages in a test bed:
Broken page
http://www.baileysw.com/testing/dragdroptest.htm

Working page
http://www.baileysw.com/testing/workingdragdrop.htm

You'll notice that the only difference between them is the placement of the
doctype element.

Oddly, since I only use page level style elements in test pages (as apposed
to css in production pages) I would not have seen this in production at all.

This is by far one of the weirdest behaviors I have seen though.
"Göran Andersson" wrote:

>John Bailey wrote:

>>I have a ASP .Net page that allows moving around items on the page through
javascript. This page works fine in IE.

In FireFox however, I have found that if the page is using XHTML 1.0
Transitional as the doctype, you cannot set the style.left and style.top
properties of image or div tags. If you remove the doctype from the page it
works just fine, although I would rather not do this. You can work around
this by setting the cssText property directly (which works in both browsers),
but I now have the annoying issue of having to fix up the cssText.

Does anyone know if this is a feature of the XHTML 1.0 Transitional
specification or if it is an anoying bug in FireFox?

Thanks in advance.

I use the same doctype, and have never had the problems that you describe.

There is nothing that prevents you from setting style.left and style.top
on elements, but naturally you also have to make the elements absolutely
or relatively positioned for the properties to have any effect.

The cssText property is non-standard. I would advice against using it.

--
Göran Andersson
_____
http://www.guffa.com

--
Göran Andersson
_____
http://www.guffa.com

[=?Utf-8?B?Sm9obiBCYWlsZXk=?=]

Yes, you're absolutely correct, the style element should go inside the head
element. A fact which I picked up on later (I don't use the in page style
tag very often).

The error as it turns out is that FireFox does not support setting the
style.left and style.top to numbers and defaulting to pixels. Apparently you
have to specifically specify "123 px" when specifying the position
properties. None of the other browsers I tested (IE and Opera) had this
restriction.

The "Quirks" mode in FireFox is more of a joke than anything else, as
FireFox is completely unforgiving with errors in markup (which is why I check
in it in the first place), but I do need to remember to check for the page
mode in the future. For some reason I thought you had to enable the Quirks
mode and that it gave an error by default, but I'm obviously mistaken.
Apparently FireFox does support defaulting to pixels in this mode, but not in
standards compliance mode.

Thanks for you help.

"Göran Andersson" wrote:

Actually both your pages are broken.

The doctype tag has to be the first tag in the page, or it will be
ignored. If you check the page information (in Firefox) of the page that
you called "Working page", it's displayed using Quirks mode. This
basically means that the browser reverts to a behaviour that tries to do
the best out of badly formed markup.

In Internet Explorer the Quirks mode can be rather devestationg. It
throws the browser in a kind of version 4 compatible mode, which messes
up the box model (padding, margin and size in css) as that version badly
misinterpreted it.

The style tag should be inside the head tag. I think that you have
confused "elements" with "tags". The head tag is not an element in the
page, the elements are inside the body tag.

John Bailey wrote:

Actually I figured it out. As it turns out, it was the placement of the
doctype tag itself. In the test page I had the doctype placed before a page
style element. Style elements cannot be inside other elements according to
the spec, which basically means they have to be the first thing on the page.
FireFox doesn't seem to like the misplacement although all other browsers did
not seem to care, and the symptom was particularly odd. Once I moved the
doctype tag to after the closing style tag the page worked without issue.

I have the two pages in a test bed:
Broken page
http://www.baileysw.com/testing/dragdroptest.htm

Working page
http://www.baileysw.com/testing/workingdragdrop.htm

You'll notice that the only difference between them is the placement of the
doctype element.

Oddly, since I only use page level style elements in test pages (as apposed
to css in production pages) I would not have seen this in production at all.

This is by far one of the weirdest behaviors I have seen though.
"Göran Andersson" wrote:

John Bailey wrote:
I have a ASP .Net page that allows moving around items on the page through
javascript. This page works fine in IE.

In FireFox however, I have found that if the page is using XHTML 1.0
Transitional as the doctype, you cannot set the style.left and style.top
properties of image or div tags. If you remove the doctype from the page it
works just fine, although I would rather not do this. You can work around
this by setting the cssText property directly (which works in both browsers),
but I now have the annoying issue of having to fix up the cssText.

Does anyone know if this is a feature of the XHTML 1.0 Transitional
specification or if it is an anoying bug in FireFox?

Thanks in advance.
I use the same doctype, and have never had the problems that you describe.

There is nothing that prevents you from setting style.left and style.top
on elements, but naturally you also have to make the elements absolutely
or relatively positioned for the properties to have any effect.

The cssText property is non-standard. I would advice against using it.

--
Göran Andersson
_____
http://www.guffa.com

--
Göran Andersson
_____
http://www.guffa.com

[=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=]

John Bailey wrote:

The error as it turns out is that FireFox does not support setting the
style.left and style.top to numbers and defaulting to pixels. Apparently you
have to specifically specify "123 px" when specifying the position
properties. None of the other browsers I tested (IE and Opera) had this
restriction.

The standard says that all measurements needs to have a specified unit,
unless the value is zero. If you omit the unit, the code is invalid, and
the browser may handle it as such.

If a browser adds a default unit to properties, it's adding non-standard
behaviour. As the units may not be omitted according to the standard,
there are no default unit specified for different properties, and pixels
is not the logical default for all properties. The font-size property
for example has no singe unit that clearly would be the preferred
default, and it's quite a big difference between 10px and 10em. If you
write code relying on the chosen default in one browser, another browser
may display the page in a completely different way, and neither of them
is more right than the other.

If you keep to the standards, the page stands a better chance at
displaying the same way in other browsers. After all, you can't try it
in all versions of all browsers, especially as the versions of the
browsers that will be used to view the page in months or years from now
doesn't even exist yet.

--
Göran Andersson
_____
http://www.guffa.com

[=?Utf-8?B?Sm9obiBCYWlsZXk=?=]

The missing unit was an oversight, but either way everyone makes mistakes
including the people writing the browsers. FireFox does use the default unit
when it is in "Quirks" mode, which is why it worked in that instance.

FireFox should either ALWAYS ignore the setting if it is in error or ALWAYS
use it. It is the fact that it switched back and forth that made this so
hard to track down. When I've made a coding mistake, its usually pretty easy
to track down in IE or Opera, but FireFox tends to be the hardest one to find
errors in.

There is no browser that 100% follows the standards, although FireFox is the
one that does the best job. Even if you do a page to standards, you had
better make sure it looks correct in the browsers you are planning to
support, because it is likely that they will not support the standards. If
your page follows the standard, but does not look correct in IE for example,
you have just lost 80% of the general audience.

You also do need to test your pages as new versions of the browsers come
out. If you have needed to do workarounds in your pages to make the page
work with a browser, these workarounds may very well need to be tweaked when
a new version of the browser comes out (look at the last version of Safari
and IE for example).

John Bailey

"Göran Andersson" wrote:

John Bailey wrote:

The error as it turns out is that FireFox does not support setting the
style.left and style.top to numbers and defaulting to pixels. Apparently you
have to specifically specify "123 px" when specifying the position
properties. None of the other browsers I tested (IE and Opera) had this
restriction.

The standard says that all measurements needs to have a specified unit,
unless the value is zero. If you omit the unit, the code is invalid, and
the browser may handle it as such.

If a browser adds a default unit to properties, it's adding non-standard
behaviour. As the units may not be omitted according to the standard,
there are no default unit specified for different properties, and pixels
is not the logical default for all properties. The font-size property
for example has no singe unit that clearly would be the preferred
default, and it's quite a big difference between 10px and 10em. If you
write code relying on the chosen default in one browser, another browser
may display the page in a completely different way, and neither of them
is more right than the other.

If you keep to the standards, the page stands a better chance at
displaying the same way in other browsers. After all, you can't try it
in all versions of all browsers, especially as the versions of the
browsers that will be used to view the page in months or years from now
doesn't even exist yet.

--
Göran Andersson
_____
http://www.guffa.com

[=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=]

John Bailey wrote:

The missing unit was an oversight, but either way everyone makes mistakes
including the people writing the browsers. FireFox does use the default unit
when it is in "Quirks" mode, which is why it worked in that instance.

FireFox should either ALWAYS ignore the setting if it is in error or ALWAYS
use it. It is the fact that it switched back and forth that made this so
hard to track down.

I think not. In quirks mode it can use non-standard ways of interpreting
the code, but in standards compliant mode it should follow the
standards, and that is exactly what it is doing in this case.

Internet Explorer on the other hand is not following the standards in
standards compliant mode, which causes probems from time to time.

When I've made a coding mistake, its usually pretty easy
to track down in IE or Opera, but FireFox tends to be the hardest one to find
errors in.

My experience is the opposite. Building for Firefox rarely causes any
problems, but Internet Explorer have caused many hours of trying to find
ways to circumvent the bugs.

There is no browser that 100% follows the standards, although FireFox is the
one that does the best job. Even if you do a page to standards, you had
better make sure it looks correct in the browsers you are planning to
support, because it is likely that they will not support the standards.

True. I have recently had some experiences with Internet Explorer, where
it would just hide parts of the page. The solution is often to add some
weird combination of styles that shouldn't have any effect at all, like
adding display:inline to a floating elements.

If
your page follows the standard, but does not look correct in IE for example,
you have just lost 80% of the general audience.

You also do need to test your pages as new versions of the browsers come
out. If you have needed to do workarounds in your pages to make the page
work with a browser, these workarounds may very well need to be tweaked when
a new version of the browser comes out (look at the last version of Safari
and IE for example).

Yes, but you can greatly reduce the risk for newer browser versions to
break your pages by sticking to standard ways of doing things. When
there is rendering problems in some browsers, I always try to find a
more stable way of using the standards instead of adding browser
specific hacks.

--
Göran Andersson
_____
http://www.guffa.com

[Damien]

On Mar 29, 2:36 am, John Bailey <[e-mail]>
wrote:

The missing unit was an oversight, but either way everyone makes mistakes
including the people writing the browsers. FireFox does use the default unit
when it is in "Quirks" mode, which is why it worked in that instance.

FireFox should either ALWAYS ignore the setting if it is in error or ALWAYS
use it. It is the fact that it switched back and forth that made this so
hard to track down. When I've made a coding mistake, its usually pretty easy
to track down in IE or Opera, but FireFox tends to be the hardest one to find
errors in.

If Firefox always applied the same behaviour, whether it was in quirks
mode or not, what would be the point in it having a quirks mode? You
again refered to the "default unit", when no such thing exists.

Damien