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

Is this a bug in IE or a feature in Gecko? :^)

P: n/a
When www.geoceanis.com is sent to the print preview or alternatively the
printer, the second page is displayed or printed by IE, but lost to Gecko
(Netscape, Firefox, Moxilla, etc...). NOTE: Both fixed and scrolling divs
are present on this page...

Is this a bug in IE or Gecko? What does the CSS/HTML need to get Gecko to
send the second page to the printer...?

Thanks in Advance...

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.biz 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
Discover valid interoperable web menus, IE security, TSR Control,
& the most advanced speed reading application @ www.fieldcraft.biz
Aug 8 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Number 11950 - GPEMC! Replace number with 11950 wrote:
When www.geoceanis.com is sent to the print preview or alternatively the
printer, the second page is displayed or printed by IE, but lost to Gecko
(Netscape, Firefox, Moxilla, etc...). NOTE: Both fixed and scrolling divs
are present on this page...
One html error, lots of css errors.
The latest firefox puts it on one (A4) page for me - although "Freeing
the truth..." loses its descenders - I'm guessing that's css, not Fx.
ie needs two pages because it has unnecessarily wide margins.

I see no browser misbehaviour.

Chris
Is this a bug in IE or Gecko? What does the CSS/HTML need to get Gecko to
send the second page to the printer...?

Thanks in Advance...
Aug 8 '06 #2

P: n/a
"Chris Sharman" <ch***********@sorry.nospamwrote in message
news:eb*******************@news.demon.co.uk...
Number 11950 - GPEMC! Replace number with 11950 wrote:
When www.geoceanis.com is sent to the print preview or alternatively the
printer, the second page is displayed or printed by IE, but lost to
Gecko
(Netscape, Firefox, Moxilla, etc...). NOTE: Both fixed and scrolling
divs
are present on this page...

One html error, lots of css errors.
Thanks for your speedy response Chris. I should have checked!

HTML error fixed (link outside a text element) & the one non-color CSS
error. For now, my colors (CSS 3.0) are in English which seems to work as
far as color interpretation goes in the target UAs. In any case, Gecko still
cuts off the second page (1024x768) while IE still recognises both first and
second page as far as printing go. This problem also translates from
www.fieldcraft.biz, where the colors are specified according to the
standard - so I doubt that the CSS 3.0 color usage is the problem.

The latest firefox puts it on one (A4) page for me - although "Freeing
the truth..." loses its descenders - I'm guessing that's css, not Fx.
Actually, in print-preview, under "page setup", tick the "background colors"
checkbox and this little problem goes away. Setting the scale to 100% should
show the second page cutoff problem fairly well. My version of Gecko is not
quite so adept at shrinking the print output to fit the page - good for you!
:^)
ie needs two pages because it has unnecessarily wide margins.
Are you referring to my sidebars or to something IE does all by itself?
>
I see no browser misbehaviour.
[SNIP]

However, there is still a difference across UAs in the way the CSS/HTML is
interpreted for the purpose of printing - and I am wondering if there is
something missing in my coding... ...perhaps something that might see
Gecko include the second page...

Thanks in Advance...

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.biz 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
Discover valid interoperable web menus, IE security, TSR Control,
& the most advanced speed reading application @ www.fieldcraft.biz
Aug 8 '06 #3

P: n/a
Number 11950 - GPEMC! Replace number with 11950 wrote:
"Chris Sharman" <ch***********@sorry.nospamwrote in message
news:eb*******************@news.demon.co.uk...
>Number 11950 - GPEMC! Replace number with 11950 wrote:
>>When www.geoceanis.com is sent to the print preview or alternatively the
printer, the second page is displayed or printed by IE, but lost to
Gecko
>>(Netscape, Firefox, Moxilla, etc...). NOTE: Both fixed and scrolling
divs
>>are present on this page...
One html error, lots of css errors.

Thanks for your speedy response Chris. I should have checked!

HTML error fixed (link outside a text element) & the one non-color CSS
error. For now, my colors (CSS 3.0) are in English which seems to work as
far as color interpretation goes in the target UAs. In any case, Gecko still
cuts off the second page (1024x768) while IE still recognises both first and
second page as far as printing go. This problem also translates from
www.fieldcraft.biz, where the colors are specified according to the
standard - so I doubt that the CSS 3.0 color usage is the problem.

>The latest firefox puts it on one (A4) page for me - although "Freeing
the truth..." loses its descenders - I'm guessing that's css, not Fx.

Actually, in print-preview, under "page setup", tick the "background colors"
checkbox and this little problem goes away. Setting the scale to 100% should
show the second page cutoff problem fairly well. My version of Gecko is not
quite so adept at shrinking the print output to fit the page - good for you!
:^)
>ie needs two pages because it has unnecessarily wide margins.

Are you referring to my sidebars or to something IE does all by itself?
>I see no browser misbehaviour.
[SNIP]

However, there is still a difference across UAs in the way the CSS/HTML is
interpreted for the purpose of printing - and I am wondering if there is
something missing in my coding... ...perhaps something that might see
Gecko include the second page...

Thanks in Advance...
At best, CSS3 is only partially implemented in only a few browsers. I
would avoid using it for now.

If the problem persists in Firefox after the page passes the W3C CSS
validator, I would submit a bug report to Mozilla at
<https://bugzilla.mozilla.org/query.cgi?GoAheadAndLogIn=1>.

There are some design problems with your page:

"Lateral Information Servic" is cut off at the right edge. This
indicates the page is so wide as to require horizontal scrolling.
However, the horizontal scrollbar is ineffective. Perhaps, it is
applied only to the body with the green background.

Similarly, the bottom half of the "Science" button is cut off. However,
the vertical scrollbar is indeed applied only to the body with the green
background.

I noticed these two with my browser window maximized but with my desktop
having a single toolbar at the bottom and a single toolbar at the right.
You should consider making the page suitable for users who might not
even want to maximize their browser windows.

Having such fixed page sizes that require a maximized window without any
encroaching toolbars makes me question your WAI-AAA logo. In any case,
Watchfire XACT indicated 1 Priority 2 and 2 Priority 3 errors.

--

David E. Ross
<http://www.rossde.com/>

Concerned about someone (e.g., Pres. Bush) snooping
into your E-mail? Use PGP.
See my <http://www.rossde.com/PGP/>
Aug 8 '06 #4

P: n/a
"David E. Ross" <no****@nowhere.notwrote in message
news:qP******************************@iswest.net.. .
[SNIP]
>
At best, CSS3 is only partially implemented in only a few browsers. I
would avoid using it for now.

If the problem persists in Firefox after the page passes the W3C CSS
validator, I would submit a bug report to Mozilla at
<https://bugzilla.mozilla.org/query.cgi?GoAheadAndLogIn=1>.

There are some design problems with your page:

"Lateral Information Servic" is cut off at the right edge. This
indicates the page is so wide as to require horizontal scrolling.
However, the horizontal scrollbar is ineffective. Perhaps, it is
applied only to the body with the green background.
Web area identifier too long. Still under consideration, but this will
revert back to a single word identifier that is more appropriate to the
function and position in the site hierarchy.
Similarly, the bottom half of the "Science" button is cut off. However,
the vertical scrollbar is indeed applied only to the body with the green
background.

I noticed these two with my browser window maximized but with my desktop
having a single toolbar at the bottom and a single toolbar at the right.
You should consider making the page suitable for users who might not
even want to maximize their browser windows.
There is a problem in that if I loosen up the sidebars to scroll with the
rest of the content, the "height: 100%;" setting is ignored and I'd prefer
to "frame" the page appearance to visually separate branding and navigation
from content. Reversing the position values with respect to the inheritance
of the sidebar div class only makes a dogs breakfast of everything because
the UA inserts space between the bottom of the sidebars and the footer.
Having such fixed page sizes that require a maximized window without any
encroaching toolbars makes me question your WAI-AAA logo.
I am glad you are questioning my WAI-AAA logo. I am keen to get away from
fixed page sizes as well, but seek a means of setting a sidebar that scrolls
with the rest of the content but has 100% of the content height - more room
= more possible links and a more liberated navigational architecture...
In any case,
Watchfire XACT indicated 1 Priority 2 and 2 Priority 3 errors.
Thanks for the WAI-AAA validation tip. Thanks to you, I've just found:
http://webxact.watchfire.com and it is a fantastic tool. It identified one
instance of a priority 2 error and thirteen instances of two Priority 3
errors. The priority 2 error (Guideline 13.1) is intentional; the
<A HREF="http://www.monkeys.com/spammers-are-leeches/"</A>
link is an eMail Harvestor trap and is not intended for human visitors.
Perhaps I should use an invisible <divclass and use some text
like, "If you advertise through eMail, click HERE for the eMail
directory"... ...and it generates no error when CSSed out of the display!

The rest were "only" warnings, most of which would be made anyway - but all
great ideas. I've been taking lots of notes because this is the kind of
additional functionality that I want on my web site. Hence the WAI-AAA badge
on a developmental page...

The guideline 4.3 error is a testament to my leaky memory (fixed), but the
guideline 10.5 error is sourced to a sidebar and raises a question: With
toolbars and particularly sidebars, is it enough to separate the links by
placing each in its own <divelement as opposed to cluttering up the
visuals with non-whitespace characters between each button? I could place a
full stop outside each link but inside the <div>, but the effect on
formatting doubles the button size by introducing a carriage return! -
unless I use a SPAN class to write out the visibility of the separation
characters but even then, this affects button size...? So I return to the
question of giving each button its own <div>...?

Thank you very much for taking the time to write down some suggestions for
me. I might not have asked for some of what you have said (if only because I
didn't think to ask!), but I really do appreciate it. I particularly liked
the anybrowser campaign, which I only found through your website!

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.biz 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
Discover valid interoperable web menus, IE security, TSR Control,
& the most advanced speed reading application @ www.fieldcraft.biz
Aug 9 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.