browser display differences

Hi everyone,

I'm testing a layout in a variety of browsers and I've found that some browsers aren't displaying certain elements correctly.

I have the following style for an h1 heading, in particular the background image (dotborderpurple.gif) acting as a border. This image appears in safari but in most other browsers no border appears at all. Would anyone know why this is happening?

h1 {
	font-size: 16px;
	font-weight: bold;
	color: #634A95;
	padding-bottom: 5px;
	margin: 0 10px 10px 0;
	background-image: url(../images/dotborderpurple.gif);
	background-repeat: repeat-x;
	background-position: left bottom;
}

Code (markup):

I also have been having problems with a background image that's placed in some li elements. The following is the css:

#columnLeft li a:link, #columnLeft li a:visited {
	font-size: 85%;
	display: block;
	padding: 0.6em 0 0.6em;
	background-color: #634A95;
	color: #fff;
	text-decoration: none;
	background-image: url(../images/arrow.gif);
	background-repeat: no-repeat;
	background-position: 125px center;	
}

Code (markup):

The image appears correctly positioned 125px from the left edge in all browsers except Mozilla 1.6, Netscape 6.2 and 6.2.3 where it's sitting in the top left corner. Is this a bug in these browsers and if so is there a fix?

And finally in explorer 5, there’s too much padding-bottom in the li elements, ie. it's about double or triple the size specified in the css. The following is the whole block of css code for this particular navigation list where the list element is not right in ie 5:

#columnLeft ul {
	list-style: none; 
	margin: 0; 
	padding: 0 0 30px;
}

#columnLeft li { 
	padding: 0;
	margin: 0 7px 0 7px;
	border-bottom: 1px dotted #fff;
} 

#columnLeft li a:link, #columnLeft li a:visited {
	font-size: 85%;
	display: block;
	padding: 0.6em 0 0.6em;
	background-color: #634A95;
	color: #fff;
	text-decoration: none;
	background-image: url(../images/arrow.gif);
	background-repeat: no-repeat;
	background-position: 125px center;	
}

#columnLeft li a:hover {
	background-color: #9790B9;
	color: #fff;
	background-image: url(../images/arrowrollover.gif);
}

Code (markup):

Just wondered if someone could help troubleshoot the above problems?

Thanks very much.

 

Browser differences can be very frustrating. At times they can be difficult to troubleshoot. There are many people here who would be able to point you in the right direction.

If you could post a link to your site, I may be able to help. We need to see the entire code before any troubleshooting can occur.

 

I think that if you find (which is exist for sure) tool for testing your page view in different browsers you save some time.

 

There are such tools. They're called 'browsers'.

cheers,

gary

 

Well... with the H1 up-tree relative links are usually a headache not worth dealing with.. you don't have an actual height declared on the h1 so you are guessing as to what the line-height will be... though without seeing the FULL code I'm guessing in the dark.

With the li/a pairing first you probably shouldn't be wasting time styling the :link and :visited directly and just hit A, then ONLY change the properties in psuedoclasses that are different... Though the REAL problem here is obvious - invalid CSS.

background-position: 125px center;

THAT is NOT valid CSS - as you cannot MIX property types. It's either named/named or metric/metric. Mixing a numeric metric with a named positions IS INVALID CSS. The browsers that allow that are in fact doing so incorrectly.

As to "explorer 5" - WHICH explorer 5? I'm assuming you mean 5.2 which nobody should be bothering to use anymore ANYWAYS - especially since it's rendering bears NO RESEMBLANCE to the behavior of windows versions of IE.

Though with that last example - attempting to do ANYTHING with an LI apart from setting it to display:inline is usually just ASKING for a layout to fail MISERABLY. Make the li just display:inline, move the bottom border and margins to the anchor and be done with it... In either case you may need to trip haslayout so that the entire 'block' of anchor can be clicked, not just the text area.

But I'm guessing, a URL to the complete code with images would let me give you a real diagnosis.

 

Not exactly true. See background-position, then see how to read the specs—value defs.

cheers,

gary

 

Except 2.1 isn't deployable since neither FF nor IE have proper implementations of it (hell, gecko hasn't even come close to having 2.0 complete)

check the 2.0 reference, and you see it's invalid there.
http://www.w3.org/TR/CSS2/colors.html#propdef-background-position

css 2.1 and 3.0 mean jack shit in terms of actual deployment for at least another five years, more likely the DECADE it has taken for 2.0 to even approach deployable (despite huge gaps in FF's implementation and IE's half-assed interpretations)

 

CSS2.1 is the current release candidate and enjoys quite good support. IE's shortcomings relate to background box model when element has layout and faulty model in tables. Opera has DOM issues with html and body elements in html and xml. The Gecko engine is fully compliant with css2.1 background properties.

I don't know where you get the idea that css2+ is not well supported, especially in Gecko. The following table shows css2.1 support levels by each of IE6, IE7, Firefox2 and Opera9.

Specifically, my personal tests show that the combo of 125px center works as expected in IE, FF, Opera and Konqueror. Please do not spread personal, unsupported opinion as fact.

                        IE6     IE7     FF      Opera
background              56%  	58%  	Y  	83%
background-attachment 	38% 	50% 	Y 	88%
background-color 	62% 	62% 	Y 	87%
background-image 	63% 	63% 	Y 	88%
background-position 	45% 	45% 	Y 	95%
background-repeat 	75% 	75% 	Y 	92%

Code (markup):

gary

 

Thanks for all the replies. I'm going to try and troubleshoot some more and if I can't find any answers soon, I'll upload.

 

Sorry, but the implementation is half-assed on the ones it does support - background for example with it's constant 'jumping' of background-position, the incomplete colgroups implementation, complete lack of support for inline-block, the use of floating point across the board for ALL calculations leading to oddball rounding errors (which causes not only the jumping centered background, but the float offset error, right absolute positioning error, etc, etc)

Quite frankly that site has a lot of balls giving a Y to the entire column of 'basic properties' for FF 2 - but it all hinges on what you are doing with it as to one's results. I've just been finding more and more it's been easier for me to get code that works in IE, Opera and Safari than it has been to get a damned thing working in Firefux the past two years... Even when I'm coding TO FF, I keep going "Why the *** doesn't this work?" - which is why the people that say "code to FF, hack for IE" are total ****ING IDIOTS in my book.

More than once now, I've ended up resorting to html:not([lang*=""]) or worse, loading down a table (of actual tabular data) with classes on every TD just because of FF's half-assed implementation of CSS2.x - which is inexcusable for ANY browser claiming CSS2 compliance since it's been a DECADE - except that prior to four years ago the only people talking about W3C compliance on code were fringe whackos since it was effectively undeployable.

Just like the fringe whackos talking about CSS3 and HTML 5 today.

 

I remember Paul O'B saying this also, that it was valid but it's just good habit to keep name/names metric/metrics "for older browsers." Before hearing that, I too thought it was actually illegal. But as far as practice, I'm going ahead and keeping them seperate, as well as always using two values even though just one is legal, because of IE.

gwh, if you really really really have to support IE5 or 5.5/5.x then you'll relaly really have to hack. A lot. Or restyle your pages to change who gets margins and padding, the parent or the child. Googling IE5 hacks css will get you a lot of them though. But I'd only do it for fun or because a client is stuck with that browser. It might also possibly be considered "accessibility" to support such browser...

 

No UA is perfectly implemented, but both subjectively and objectively, Firefox is considerably better implemented than IE. Firefox and Opera are at similar levels, the faults in each mostly lying in different areas.

That has not been an issue for me. See my comments on rounding errors.

No browser implements colgroup or col properly, if at all. That's html, not css.

Let's see, IE implements only on inline elements, by triggering hasLayout with {display: inline-block;}, then you must reset the display to inline. I haven't figured out how to make Opera work. Opera does have support, I just don't know how to use it. Firefox works as expected with -moz-inline-box.

There are always rounding errors in every UA. With non-integer results, eg. 10÷3, some round up, some round down and some round to the nearest integer. There will always be discrepancies one to another until the specs define the method. It is not defined at this time, thus variances.

That's quite the reverse of my experience. Perhaps you're coding to IE's buggy behavior rather than to the standards. I suspect you don't know how things should work as much as you think you do.

Quite a claim. Perhaps you could post a test case of a table to demonstrate the issue.

I've found css-p to be usably deployable since late 2001 or early 2002, though IE5.x would make you crazy. Phoenix0.5 (now Firefox), even then, was the more compliant UA.

The Moz family, Opera and Konqueror/Safari are already starting to incorporate css3 and html5 bits and pieces. Firefox, Opera and Safari have working alpha and beta versions for testing the proposed specs.

If there is a holdup, it will continue to be IE.

gary

 

If I recall, it was that the css styling that you could do with <col /> didn't work in FF (in case you wanted the columns to have different colours instead of the rows). Wherever I ran across this (I forget but it must be pretty high up in teh googles) said the other browsers were okay with this.

I find myself simply not using stuff because someone somewhere doens't implement it. So, I've never seen the benefits of inline-block, or display:table (until recently and required nasty IE hacks) or some other things... and sometimes I run across stuff in the specs or on some CSS3 page and I'm like, wow, you can do that? And the answer usually is, well, not really.

My lists could completely eliminate all classes except "current" for breadcrumbing f the other browsers supported first-child and last-child (I don't think anyone BUT FF does last-child). I'd love to use all that neat stuff that's sitting unimplemented in CSS2.1 and 3... or Xforms... drool... but that's mostly because I don't Javascript and a lot of this stuff just moves the scripting from JS to CSS : )

Why can't it be the obscure browsers who don't support stuff?

 

Uhm, since when? IE 5 and Later FULLY support it, as does Safari. Opera supports it just in HTML, while FF doesn't support it apart from FAC.
-- EDIT -- Huh, my bad, I never tried assigning it to a block-level element before. Doesn't work with a DIV or other block levels- though if it's going to be an inline-block, it should be semantically incorrect to use a block level I'd think (since we don't want a block section, we want an inline to which dimensions can be applied)

http://battletech.hopto.org/html_tutorials/tableAlign/tableTest.html

Which shows that at least opera lets me do it in the HTML, FF doesn't let you use it for align at all and will only apply FAC via colgroups. 2.0.12 at LEAST appears to now apply width properly, I know 1.x did not.

Of course, want a laugh? Last time I posted on this subject I had some dillwad saying "You shouldn't use tables ever! Don't use a table for that!" - RIGHT.

Uhm, since when? IE has had a 100% working inline-block since IE 5 that requires no haslayout or display:inline tricks.

display:inline-block; - that's it. Just like safari it supports it 100%, as does IE.

No, no it doesn't, you usually have to add display:-moz-inline-block; AS WELL (which apparantly stacks instead of overrides???) and even then you cannot rely on it positioning it properly leaving you to play with vertical-align until you get all four major browser engines 'on the same page'.

- yet Gecko is the only one that keeps a rolling tally, making it's rendering WILDLY off from everyone else.
http://battletech.hopto.org/for_others/font_test.html
Notice who the odd man out is. This also is a BIG problem if you are trying to just center a background, or have a image float:right or absolute positioned right since you get a 1px 'jog' that appears/dissapears as you change screen width - it can't even CENTER consistantly - even once you are inside a fixed width container!

I'd suspect that too, if the same code didn't work fine in Opera and Safari AND follow the published spec too. I think part of the issue is that IE's 'quirks' away from the standard are just better documented, while FF's are swept under the rug - much akin to the memory leak that makes me have to kill that steaming pile of crap every 20 minutes is a 'feature' (which BTW looks to still be alive and well in the 3.x beta).

Which is my biggest problem with browser development - MAYBE they should work on finishing off the decade old specifications BEFORE starting in on specifications that aren't even out of draft yet?

 

I thought 5x didn't do it at all, while 6 and 7 need the thing to be inline at the start (though if I set it to display: inline first, and then later say display: inline-block it works)?
True it doesn't require Haslayout--- it triggers Haslayout. The only time I've really used it was when I was running out of Haslayout triggers and the nice thing about this one is you can undo it by setting something back to display: block and you get to keep your Haslayout.

 

Some folks just don't get the difference between a table layout and a table data structure.

I was a bit hasty regarding IE and tables. Still, col and colgroup do have some DOM issues in IE (to be expected, td and th do not descend from either—glad I'm not having to implement them). Using your own demo, the others each have serious shortcomings to the point I've given up on them. It hasn't been that much of an issue, since I can't recall a non-trivial table that wasn't a product of a db query and PHP construction. For example:

Assuming $test[] holds the query result:

$smarty->assign('comp', $test);
$smarty->display('table.tpl');

Where table.tpl contains:

    <table summary="test">
      <thead>
        <!-- ... -->
      </thead>
      <tbody>
      {section name=mysec.loop=$comp}
        <tr>
          <td class="name">{$comp[mysec].name}</td>
          <td class="spectxt">{$comp[mysec].direction}</td>
          <td class="num">{$comp[mysec].amount}</td>
          <td class="num">{$comp[mysec].total}</td>
        </tr>
      {/section}
      </tbody>
    </table>

Code (markup):

See my example, below. Remove the Tan hack to get IE6 back to inline and it breaks. No tests run on IE7.

[moved here to more closely match the comments]

I take it as we want a block element to render inline. A thumbnail gallery, pic plus caption, is a common need.

I played some more. Not sure where the problem has been. IE still needs to be reset to inline, per your edit.

-moz-inline-block not helpful for me. IE, Opera and Konqueror seem to apply vertical-align baseline or bottom. Firefox defaults to top (which in a gallery would probably be my preference). Explicitly setting vertical-align to either top or bottom matches up the browsers. Firefox seems to ignore baseline.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xml:lang="en"
      xmlns="http://www.w3.org/1999/xhtml"
      lang="en">
<head>
  <title></title>
  <meta name="generator"
        content=
        "HTML Tidy for Linux/x86 (vers 6 November 2007), see www.w3.org" />
  <meta http-equiv="content-type"
        content="text/html; charset=utf-8" />
  <meta name="editor"
        content="Emacs 21" />
  <meta name="author"
        content="Gary Turner" />
  <style type="text/css">
/*<![CDATA[*/

  #gallery {
  text-align: center;
  }

  .lineblock {
  width: 75px;
  border: 1px solid black;
  text-align: center;
  display: -moz-inline-box;
  display: inline-block;
  vertical-align: top;
  }

  .lineblock p {
  text-align: center;
  width: 75px;
  }

  * html .lineblock {
  display: inline;
  }

  /*]]>*/
  </style>

</head>

<body>
  <div id="gallery">
    <div class="lineblock">
      <p><img src="bullseye.jpg"
           alt="" />
      <br />
      caption</p>
    </div>

    <div class="lineblock">
      <p><img src="bullseye.jpg"
           alt="" />
      <br />
      caption</p>
    </div>

    <div class="lineblock">
      <p><img src="bullseye.jpg"
           alt="" />
      <br />
      caption and more and more</p>
    </div>

    <div class="lineblock">
      <p><img src="bullseye.jpg"
           alt="" />
      <br />
      caption</p>
    </div>
  </div><!-- end gallery -->
</body>
</html>

Code (markup):

Don't understand your example link.

<snip>

It's called advancing the art, something IE hasn't done in seven years.

cheers,

gary

 

Well, first you've got a block level inside a inline for no reason, that paragraph should REALLY get the axe (and I still say unless it's an inline image like a smiley, images have no ****ing place in paragraphs), since you are displaying them as inline elements DIV is completely improper in the first place, and you know your comment placement could cause IE to trip a double render bug AND a dissapearing content bug, right?

Though I will say that pretty print makes an excellent example of why I'd never let any automated tool mangle code that badly.

It also appears your example does NOT format consistantly cross-browser, since IE, Opera and Safari are treating the white-space as... white space, putting spaces between the items, while FF is collapsing them.

Though I just tried it how I'd code it, and it works great in every browser except FF - I'm shocked, REALLY. Fun part is, it shows a HUGE rendering bug in FF as well - try setting the height of #gallery span to say... 250 px for a laugh.

Again, this should work in all browsers, but fails miserably in FF.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html 
	xmlns="http://www.w3.org/1999/xhtml"
	xml:lang="en"
	lang="en"
><head>

<meta 
	http-equiv="Content-Type"
	content="text/html; charset=iso-8859-1" 
/>



 <title></title>

<style type="text/css">
* {
	margin:0;
	padding:0;
}

#gallery {
	text-align:center;
}

#gallery span {
	display:-moz-inline-block;
	display:-moz-inline-box;
  display:inline-block;
  width:75px;
  height:200px;
  border:1px solid black;
  text-align:center;
  vertical-align:top;
}

#gallery img {
	width:48px;
	height:48px;
	border:0;
	background:#CCC;
}

</style>

</head><body>

<div id="gallery">
	<span>
    <img src="bullseye.jpg" alt="" />
    <br />
    caption
  </span><span>
		<img src="bullseye.jpg" alt="" />
    <br />
		caption
  </span><span>
		<img src="bullseye.jpg" alt="" />
    <br />
		caption and more and more
  </span><span>
		<img src="bullseye.jpg" alt="" />
    <br />
		caption
	</span>
</div>

</body></html>

Code (markup):

Note I added a background and dimensions to the image to make it appear consistant in all browsers without the actual image present. I really love how badly FF mangles this one.

Oh, and as to 'advancing the art' - We're talking about the same type of bullshit that resulted in the bloated messes that are leoptard in vista. Goofy eye candy bullshit we don't need - and if all that effort was being put towards actually fix the existing problems most of that extra crap isn't needed. **** flip 3d, **** aero, **** expose, **** reskinning every time you release a new version... or as it applies to CSS3/HTML5 - **** new attributes, **** new properties, **** new tags, for **** sake just CLEAN UP THE EXISTING SPECIFICATIONS, and browser makers for **** SAKE GET ON THE SAME PAGE ON IMPLEMENTING IT.

Instead of dicking around with bullshit like border-radius or adding a tag 'columns' that works like a table but "Isn't actually a table so it's ok" MAYBE JUST ****ING MAYBE CLEAN UP THE GOD **** MOTHER ****ING SPECIFICATION so that JUST MAYBE we'd have consistant line-heights, rounding, and a host of other technical bullshit inconsistancies the browser makers aren't going to bother with until it's shoved down their mother ****ING THROATS.

Innovation is cutesy bullshit when the decade old shit doesn't even work yet.

Sorry for the rant, but this is my biggest pet peeve of software development - just keep tacking on more tacky rubbish eye-candy bullshit, devoting endless hours and resources on garbage that does NOT increase productivity and does NOT make our lives easier - instead of devoting those resources where they belong, fixing EXISTING problems before tacking on that rubbish.

 

The div is a block level container that we're displaying in an inline box. As I described the example, the image is content. It would likely be be a link, and as such, it needs its own container.

I know no such thing. There is one comment and it is not sandwiched between float elements, anyway.

The formatting is sane. Nested elements are set off by indention and sibling elements are separated by a blank line. You don't like it, don't use it.

My experience is that Firefox, Opera and Konqueror collapse white space to a single space. IE removes all white space. That's not what I would expect of IE, but that's what I got.

No way would I use such non-semantic markup. Further, I code to make things work, not break them. It is IE that, on the whole, causes the most grief.

Stuff is improving steadily. Even IE has, after six or seven years, managed to implement some hacks internally for its more egregious bugs. As for the new stuff, don't use it.

BTW, the columns thing is not at all like tables. It's about flowed columnar text. Lots of possibilities, both good and bad.

Could you possibly eschew the screaming and expletives? It certainly lowers your credibility. If a congenital defect prevents calm and reasonable discourse on your part, we'll try to get past it.

gary

 

deathshadow, even allowing for the fact that you're obviously passionate about your craft, and that certain derogatory terms can be overlooked as a "turn of phrase", the shouting and swearing is making me glaze over.. which is a shame because this looks like an interesting discussion

Gary I admire your patience, it's always a shame when some folks feel the need to shout so loud it drowns out whatever good things they may have to say?

oh well am going to try again to read this thread

 

This is a damn important discussion if the style of coding (which varies from coder to coder) can make the otherwise same page react so differently between browsers... collapsing whitespace or not, for instance, is a big deal with set up... who would want this sort of page? A photographer? A designer? Graphic artist? Those are the people who want pixel-perfect web design, and if browser behaviour varies so much depending on how you code the same content...

Wtf? So which is it and why?