Forum: Ruby on Rails [MacOSX] Firefox Not Diplaying Images

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
C4edcb52652d2b17fe2b38ef13bae729?d=identicon&s=25 D'Andrew "Dave" Thompson (Guest)
on 2006-01-24 05:37
(Received via mailing list)
Forgive the random question, but for those of you Mac OS X users...

Does anyone else have a problem with Firefox 1.5 not displaying
pictures/graphics embedded on web pages. Safari doesn't seem to have a
problem with them.

For example, my blog appears correctly in Safari, however Firefox
drops background images.

Clues? Thanks.

--
~~~~~~~~~~~~~~~~~~~
D'Andrew "Dave" Thompson
http://dathompson.blogspot.com
5d78134cb16847bbfad9e03afe5aa0a8?d=identicon&s=25 Benoit Gagnon (Guest)
on 2006-01-24 06:32
(Received via mailing list)
On 2006-01-23 23:36:12 -0500, "D'Andrew \"Dave\" Thompson"
<dandrew.thompson@gmail.com> said:

> Forgive the random question, but for those of you Mac OS X users...
>
> Does anyone else have a problem with Firefox 1.5 not displaying
> pictures/graphics embedded on web pages. Safari doesn't seem to have a
> problem with them.
>
> For example, my blog appears correctly in Safari, however Firefox
> drops background images.
>
> Clues? Thanks.

I had a similar issue... turned out I was using a baseref tag in the
<head> section of my layout. Safari was ignoring this for CSS
stylesheets, which appear higher in the <head> tag, but Firefox was
applying the baseref to everything, including CSS. You shouldn't use
baseref anyway, but check it out to make sure :)

Ben
C4edcb52652d2b17fe2b38ef13bae729?d=identicon&s=25 D'Andrew "Dave" Thompson (Guest)
on 2006-01-24 07:21
(Received via mailing list)
It seems that the default setting for Firefox 1.5 is to only allow the
display of images from the originating website. Hmm, with the advent
of Web 2.0 and the potential for many more elements to be called in
from other locations, it would seem more reasonable to make the
default to except them. But that's just me.

Thanks guys. Dave

On 1/23/06, Benoit Gagnon <b.gagnon@gmail.com> wrote:
> > drops background images.
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
~~~~~~~~~~~~~~~~~~~
D'Andrew "Dave" Thompson
http://dathompson.blogspot.com
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-01-24 09:41
(Received via mailing list)
Benoit Gagnon wrote:
> I had a similar issue... turned out I was using a baseref tag in the
>  <head> section of my layout. Safari was ignoring this for CSS
> stylesheets, which appear higher in the <head> tag, but Firefox was
> applying the baseref to everything, including CSS. You shouldn't use
>  baseref anyway, but check it out to make sure :)

That's actually invalid HTML, which would explain why the browsers
handle it differently.  From the spec:

> When present, the BASE element must appear in the HEAD section of an
> HTML document, before any element that refers to an external source.
> The path information specified by the BASE element only affects URIs
> in the document where the element appears.

(http://www.w3.org/TR/html401/struct/links.html#edef-BASE)

Why do you say it shouldn't be used?
5d78134cb16847bbfad9e03afe5aa0a8?d=identicon&s=25 Benoit Gagnon (Guest)
on 2006-01-24 13:44
(Received via mailing list)
On 2006-01-24 03:38:34 -0500, Alex Young
<alex@blackkettle.org> said:

>> When present, the BASE element must appear in the HEAD section of an
>> HTML document, before any element that refers to an external source.
>> The path information specified by the BASE element only affects URIs
>> in the document where the element appears.
>
> (http://www.w3.org/TR/html401/struct/links.html#edef-BASE)

I don't remember the W3C validator catching this... maybe it doesn't
check the element's position ?

>
> Why do you say it shouldn't be used?

Because Rails takes care of the fancy URL rewriting for you, it will
most certainly fail with rails helpers unless your app is really on
"app.server.com/" and not something like
"www.server.com/more/complicated/url". Even more cumbersome if the
location of the app changes from development to production.
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-01-24 13:50
(Received via mailing list)
Benoit Gagnon wrote:
>> (http://www.w3.org/TR/html401/struct/links.html#edef-BASE)
>
> I don't remember the W3C validator catching this... maybe it doesn't
> check the element's position ?
Quite possibly.  In any event, the validator's not the browser or the
spec :-)

>> Why do you say it shouldn't be used?
>
> Because Rails takes care of the fancy URL rewriting for you, it will
> most certainly fail with rails helpers unless your app is really on
> "app.server.com/" and not something like
> "www.server.com/more/complicated/url". Even more cumbersome if the
> location of the app changes from development to production.

Oh, I see what you mean.  I thought you meant in general.
5d78134cb16847bbfad9e03afe5aa0a8?d=identicon&s=25 Benoit Gagnon (Guest)
on 2006-01-24 20:22
(Received via mailing list)
On 2006-01-24 07:52:50 -0500, Alex Young
<alex@blackkettle.org> said:

> Benoit Gagnon wrote:
>>> (http://www.w3.org/TR/html401/struct/links.html#edef-BASE)
>>
>> I don't remember the W3C validator catching this... maybe it doesn't
>> check the element's position ?
> Quite possibly.  In any event, the validator's not the browser or the spec :-)

Nope. But it is much more enjoyable than reading W3C spec documents :-)
This topic is locked and can not be replied to.