Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Trouble getting page to work in FireFox

Reply
Thread Tools

Trouble getting page to work in FireFox

 
 
=?Utf-8?B?Sm9obiBCYWlsZXk=?=
Guest
Posts: n/a
 
      03-24-2007
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.
 
Reply With Quote
 
 
 
 
=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=
Guest
Posts: n/a
 
      03-26-2007
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
 
Reply With Quote
 
 
 
 
=?Utf-8?B?Sm9obiBCYWlsZXk=?=
Guest
Posts: n/a
 
      03-28-2007
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
>

 
Reply With Quote
 
Damien
Guest
Posts: n/a
 
      03-28-2007
On Mar 28, 3:07 am, John Bailey <(E-Mail Removed)>
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

 
Reply With Quote
 
=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=
Guest
Posts: n/a
 
      03-28-2007
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
 
Reply With Quote
 
=?Utf-8?B?Sm9obiBCYWlsZXk=?=
Guest
Posts: n/a
 
      03-28-2007
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
>

 
Reply With Quote
 
=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=
Guest
Posts: n/a
 
      03-28-2007
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
 
Reply With Quote
 
=?Utf-8?B?Sm9obiBCYWlsZXk=?=
Guest
Posts: n/a
 
      03-29-2007
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
>

 
Reply With Quote
 
=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=
Guest
Posts: n/a
 
      03-29-2007
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
 
Reply With Quote
 
Damien
Guest
Posts: n/a
 
      03-29-2007
On Mar 29, 2:36 am, John Bailey <(E-Mail Removed)>
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ruby 1.9.1, rubygems, rvm. trouble getting sqlite3 to work. scott Ruby 4 03-15-2010 08:51 PM
Having trouble getting new sound card to work - had onboard sound Dora Smith Computer Information 1 11-23-2006 04:31 PM
having trouble getting the Scriptaculous effects to work Jake Barnes Javascript 2 05-27-2006 02:28 AM
Firefox gamed - Drudge getting around Firefox popup blocker Venger Firefox 10 12-22-2004 04:37 AM
Help! Newb having trouble getting a WHY'S example to work... Ruby 2 10-07-2004 01:52 AM



Advertisments