Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > HTML > gap rendered in Firefox 3 but not in IE 7

Reply
Thread Tools

gap rendered in Firefox 3 but not in IE 7

 
 
Tarscher
Guest
Posts: n/a
 
      06-10-2008
HI all,

http://topvolleyantwerpen.be/content/project/missie renders a gap
between the menu and the content in Firefox but not in Internet
Explorer 7 .

I tried to decrease the heigth of the top div (containing the logo and
menu) but the gap is always rendered between the content and the
menu.

Someone has an idea why?

-Stijn
 
Reply With Quote
 
 
 
 
GTalbot
Guest
Posts: n/a
 
      06-13-2008
On 10 juin, 21:48, Gus Richter <gusrich...@netscape.net> wrote:

>
> The reason is due to Collapsing Margins. Google for it.
> To check if it is, place this rule into your stylesheet:
>
> * * * {margin:0 *!important;}
>
> --
> Gus


Gus,

The reason is due to incorrect implementations of adjoining margin
collapsing in Internet Explorer 7 and lower. It's very important to
state this because those incorrect implementations have been fixed in
IE 8 beta 1.

And the "solution" you offered is extremely questionable because it
abuses the CSS parser as all elements in the document, even inline
elements which ignore margin. This will lead to more bloated CSS code
as removing margin (all 4 sides) to all elements (including all those
who by default have margins) is likely to create the need to restore
some for all block-level elements. IMO, you gave a bad advice.

At the very least, a much more targeted, contextual and parcimonious
solution was to offer something like
Neredbojias proposed.

Gérard
 
Reply With Quote
 
 
 
 
GTalbot
Guest
Posts: n/a
 
      06-14-2008
On 13 juin, 15:33, Gus Richter <gusrich...@netscape.net> wrote:
> GTalbot wrote:
>
> > At the very least, a much more targeted, contextual and parcimonious
> > solution was to offer something like
> > Neredbojias proposed.

>
> > Gérard

>
> Gérard,
>
> The OP specifically asked _why_ the problem was happening.
> Neredbojias provided the _solution_ which was excellent.
> I provided the _reason why_ and _help to determine the why_.
>
> --
> Gus
> "..... but give them the tools ....."


I do not think you did not provide the reason actually.
The reason is an incorrect implementation (a bug, if you prefer) of
adjoining margin collapsing in IE 5, IE 6, IE 7.
There is no buggy implementation in Firefox 1, Firefox 2, Firefox 3,
Opera 9, Safari 3, Internet Explorer 8, Hv3 TKHTML, Icab 3+, etc..

Regards, Gérard
 
Reply With Quote
 
GTalbot
Guest
Posts: n/a
 
      06-14-2008
On 13 juin, 15:24, Gus Richter <gusrich...@netscape.net> wrote:
> GTalbot wrote:
> > On 10 juin, 21:48, Gus Richter <gusrich...@netscape.net> wrote:

>
> >> The reason is due to Collapsing Margins. Google for it.
> >> To check if it is, place this rule into your stylesheet:

>
> >> * * * {margin:0 *!important;}

>
> >> --
> >> Gus

>
> > Gus,

>
> > The reason is due to incorrect implementations of adjoining margin
> > collapsing in Internet Explorer 7 and lower. It's very important to
> > state this because those incorrect implementations have been fixed in
> > IE 8 beta 1.

>
> > And the "solution" you offered is extremely questionable because it
> > abuses the CSS parser as all elements in the document, even inline
> > elements which ignore margin. This will lead to more bloated CSS code
> > as removing margin (all 4 sides) to all elements (including all those
> > who by default have margins) is likely to create the need to restore
> > some for all block-level elements. IMO, you gave a bad advice.

>
> > At the very least, a much more targeted, contextual and parcimonious
> > solution was to offer something like
> > Neredbojias proposed.

>
> > Gérard

>
> You misunderstood my posting.
> The rule which I presented is only, as I said, a _check_ , and therefore
> only a _temporary_ thing.


Even that is not true. Your CSS rule removes all the margins on all
elements, even those which have no relation with the noticed gap. You
can easily create side effects with such kind of rule. You use the
universal selector, you know... You didn't just use a selector on an
unique DOM element.

> Not presented as a fix at all, but simply a
> diagnostic tool.


Well, that is a bad diagnostic tool. An unreliable one. A not-
trustworthy diagnostic tool.

Gérard
 
Reply With Quote
 
dorayme
Guest
Posts: n/a
 
      06-14-2008
In article
<7719daaf-6b90-4930-97d9->,
GTalbot <> wrote:

> On 13 juin, 15:24, Gus Richter <gusrich...@netscape.net> wrote:
> > GTalbot wrote:
> > > On 10 juin, 21:48, Gus Richter <gusrich...@netscape.net> wrote:

> >
> > >> The reason is due to Collapsing Margins. Google for it.
> > >> To check if it is, place this rule into your stylesheet:

> >
> > >> * * * {margin:0 *!important;}

> >

....
> > You misunderstood my posting.
> > The rule which I presented is only, as I said, a _check_ , and therefore
> > only a _temporary_ thing.

>
> Even that is not true.


What is not true? That Gus intended it as a temporary thing? That it
could be for temporary use?


> Your CSS rule removes all the margins on all
> elements, even those which have no relation with the noticed gap.


That does not mean it is useless as a quick check on something, to give
a clue on how to investigate further.

> You
> can easily create side effects with such kind of rule.


Like what? It is completely irrelevant to answer with cases of side
effects of the permanent use of the universal selector.

> You use the
> universal selector, you know... You didn't just use a selector on an
> unique DOM element.
>
> > Not presented as a fix at all, but simply a
> > diagnostic tool.

>
> Well, that is a bad diagnostic tool. An unreliable one. A not-
> trustworthy diagnostic tool.
>


You appear to be ignoring the distinction between permanent and
temporary that Gus has indicated. I have often used * {margin: 0;
padding: 0;" for a few minutes to give me helpful clues or to remove
irrelevant effects of margins and padding on some problem that has some
other basis.

--
dorayme
 
Reply With Quote
 
GTalbot
Guest
Posts: n/a
 
      06-15-2008
Gus Richter a écrit :
> GTalbot wrote:
> >> You misunderstood my posting.
> >> The rule which I presented is only, as I said, a _check_ , and therefore
> >> only a _temporary_ thing.

> >
> > Even that is not true. Your CSS rule removes all the margins on all
> > elements, even those which have no relation with the noticed gap. You
> > can easily create side effects with such kind of rule. You use the
> > universal selector, you know... You didn't just use a selector on an
> > unique DOM element.
> >
> >> Not presented as a fix at all, but simply a
> >> diagnostic tool.

> >
> > Well, that is a bad diagnostic tool. An unreliable one. A not-
> > trustworthy diagnostic tool.
> >
> > G�rard

>
> Too bad you haven't tried it yourself, but then even if you had, you can
> use or disregard. It works very well for me.
>
> BTW, you seem to have concern that the universal selector affects other
> "side effects". This is true, since it removes _all_ margins,


it removes _all_ margins on **each and all elements** of the document.
Not just all the margins of one element.


> but who
> cares? It is only to temporarily look at the "noticed gap" area.


You obviously don't care. Universal selector usage is highly
suspicious of over-killing and over-declaring in a stylesheet.

>
> --
> Gus


What you coded is a risky, is not recommendable, is not reliable and
is not trustworthy way to detect a problem or to propose a solution.
Again, you are removing all margins of all elements in a document. You
are not removing the margin-top of a single element. You mis-target.
You over-remove all margins on all elements, even on elements which do
not have a margin anyway.

Gérard
 
Reply With Quote
 
GTalbot
Guest
Posts: n/a
 
      06-15-2008


Gus Richter a écrit :
> GTalbot wrote:
> >
> > I do not think you did not provide the reason actually.

>
> Two negatives results in a positive.
>


I misworded that. I think you did not provide the reason actually.
The reason is an incorrect implementation (a bug, if you prefer) of
adjoining margin collapsing in IE 5, IE 6, IE 7.
There is no buggy implementation in Firefox 1, Firefox 2, Firefox 3,
Opera 9, Safari 3, Internet Explorer 8, Hv3 TKHTML, Icab 3+, etc..


> I agree that IE is the buggy culprit here.


You did not mention that.

> The fact that IE does not
> collapse margins properly


You did not provide the correct reason.

> only complicated the OPs problem in that he
> expected rendering as per IE and was therefore surprised that Firefox
> rendered with a gap. He wondered why this was so and his attempts to
> remove the gap all failed. He desired no gap. There are several
> solutions possible to removing the gap in conforming browsers (Firefox
> here) and one was proposed.
>
> I correctly answered the OPs query by informing him that the gap on his
> page as rendered by conforming browsers (Firefox here) is because of
> "Collapsing Margins".
>
> Additionally I provided a small tool


and it was a bad tool, a bad way, a bad detection method.

Gérard
 
Reply With Quote
 
GTalbot
Guest
Posts: n/a
 
      06-15-2008
dorayme a écrit :


> > Your CSS rule removes all the margins on all
> > elements, even those which have no relation with the noticed gap.

>
> That does not mean it is useless as a quick check on something, to give
> a clue on how to investigate further.


Then use a targeted, specific check on the margin-top of the targeted
element. You do not need to over-use, abuse, over-kill. By relying on
the universal selector, you still do not know which element had an
effect. You do not know what actually cause the gap to be removed.
It's very bad practice and I see this sort of zero-ing the browser
stylesheets more and more often in stylesheets which in fact is more
about overcoming the flaw and incorrect implementation of IE 5, IE 6,
IE 7 than about uniforming just a few elements that have different
defaults in browsers.

>
> > You
> > can easily create side effects with such kind of rule.

>
> Like what? It is completely irrelevant to answer with cases of side
> effects of the permanent use of the universal selector.
>


Any browser could have differences of margins and padding for
elements. Like Eric Meyer said, using the universal selector on all
elements will affect text inputs and textareas. It's besides the
point: do not use a canon when all you just need is a fly-swatter. Do
not use a class when using an id is more to the point, more targeted.

Avoid Universal Rules!
http://developer.mozilla.org/en/docs...ersal_Rules.21

because it's inefficient!


> > You use the
> > universal selector, you know... You didn't just use a selector on an
> > unique DOM element.
> >
> > > Not presented as a fix at all, but simply a
> > > diagnostic tool.

> >
> > Well, that is a bad diagnostic tool. An unreliable one. A not-
> > trustworthy diagnostic tool.
> >

>
> You appear to be ignoring the distinction between permanent and
> temporary that Gus has indicated.


Lots of people in their stylesheets are now using such "'TEMPORARY'"
solution or detection method. And that's bad programming, bad
recommendation, bad detection method.

Gérard
 
Reply With Quote
 
GTalbot
Guest
Posts: n/a
 
      06-15-2008
Gus Richter a écrit :

> I correctly answered the OPs query by informing him that the gap on his
> page as rendered by conforming browsers (Firefox here) is because of
> "Collapsing Margins".


Load these pages in IE 7, Firefox 2+, Opera 9.x, Safari 3.x, Hv3
TKHTML, Icab 3+.

http://www.gtalbot.org/BrowserBugsSe...MarginBug.html
http://www.gtalbot.org/BrowserBugsSe...arginBug2.html
http://www.gtalbot.org/BrowserBugsSe...arginBug3.html

Then apply your "detection tool" and the rendered page will be
incorrect, misrendered: removing the body and the <div>'s margins are
not justified, not correct. Adjoining margin collapsing is *not* the
same as absence of margin or margin: 0 everywhere for every element
(even inline elements!).

Your so-called detection tool can be found in many webpages'
stylesheets and in articles (by google-ing about it, I found *many* eg
http://leftjustified.net/journal/200...lobal-ws-reset) promoting
it as a way to reset just a few browser default differences.

The bottom line I am saying is that if you need to apply/set the
padding left and margin left to a few elements (like lists and list-
items), then you shouldn't use the universal selector.

> Additionally I provided a small tool to be able to quickly determine if
> a gap problem is due to collapsing margins, or not. You apparently don't
> like the tool - no problem, but it works for me.


It does not work for me and for cases involving adjoining margin
collapsing. Resetting margins to 0 and collapsing margins is *not* the
same thing.

Gérard
 
Reply With Quote
 
dorayme
Guest
Posts: n/a
 
      06-15-2008
In article
<c4913778-68f1-4e58-805d->,
GTalbot <> wrote:

> dorayme a écrit :
>
>
> > > Your CSS rule removes all the margins on all
> > > elements, even those which have no relation with the noticed gap.

> >
> > That does not mean it is useless as a quick check on something, to give
> > a clue on how to investigate further.

>
> Then use a targeted, specific check on the margin-top of the targeted
> element. You do not need to over-use, abuse, over-kill.


"Overuse, abuse, overkill" for zeroing margins and/or padding with a
universal selector for a quick check? These strong words sound more
appropriate when the target is something more substantial than a
temporary diagnostic tool of elimination.

In many cases one does not quite know what element to target. It is
hardly abusing anything if it is used to eliminate something from the
enquiring diagnostic mind.

I understand your view about the dangers of zeroing margins and paddings
by use of the universal selector. But this is not at all relevant. No
amount of describing the evils of such universal zeroing intended for
permanency will be obviously relevant to its use as a temporary measure
of diagnosis.

Sometimes, to locate some pesky problem, I have simply deleted half of a
stylesheet, or all but one of several. Ditto with HTML. It is not
something a rational person would do as a permanent fix, but it might
assist one to narrow the area to be searched for some trouble. It would
be hardly helpful for someone to be alarmed at this as if this is how
the site will end up, chopped in two somehow!

--
dorayme
 
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
Our gap: Tech jobs coming, but the labor pool is lacking. bilawal samoon Python 0 09-26-2009 05:57 PM
firefox problem, html not rendered correctly Jeff ASP .Net 1 04-20-2009 02:07 AM
backgroundcolor not rendered with Netscape, Firefox André ASP .Net 4 06-19-2008 07:30 PM
<br> not interpretered but just rendered. Louis. Javascript 5 07-22-2006 08:15 AM
Gap in IE, no gap in FF chlori HTML 1 01-19-2006 09:30 PM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57