Forum Moderators: open
I really like the help firefox gives in showing parse errors on CSS and everything else. My site works better everywhere because of Firefox's really helpful tools
TD.list a {
text-transform: uppercase; font-size: 11px;
line-height: 22px;
font-weight: bold;
text-decoration: none;
font-family: verdana;
color: #FF5B00;
border-bottom: 1px solid #ACA899;
border-left: 3px solid #ACA899;
padding-left: 5px;
height: 18px;
width: 195px;
}
TD.list a:hover {
background: #ACA899 ;
color: #2F2F2F ;
text-decoration: none;
border-bottom: 1px solid #000000;
border-left: 3px solid #3c3c3c;
IE gets it; Moz doesn't.
Easiest solution: a link on "Use FireFox?" and take them to an IE download page. I think the sooner that the FF-faithful stop being apologists for Moz browsers and demand some performance on their claims, the better FF will get as well as the experience FF browser users enjoy.
For now, I'm calling a turd and turd.
My $0.02,
Jim
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"><html>
<head>
<title>Test Case</title>
<style type="text/css">TD.list a {
text-transform: uppercase; font-size: 11px;
line-height: 22px;
font-weight: bold;
text-decoration: none;
font-family: verdana;
color: #FF5B00;
border-bottom: 1px solid #ACA899;
border-left: 3px solid #ACA899;
padding-left: 5px;
height: 18px;
width: 195px;
}
TD.list a:hover {
background: #ACA899 ;
color: #2F2F2F ;
text-decoration: none;
border-bottom: 1px solid #000000;
border-left: 3px solid #3c3c3c;</style>
</head>
<body>
<table>
<tr>
<td class="list">
<a href="#">Go Home</a>
<br><a href="#">Stay Here</a>
<br><a href="#">Third Option</a>
</td></tr></table>
</body>
</html>
The two page renderings look identical to me and the hover behavior seems to be the same. Are other style rules in your case that are adding to the situation?
What is it that Firefox doesn't "get"?
What is it that Firefox doesn't "get"?
Width and height. It only applies it to the 'a' tag, not the 'TD.' Perhaps IE8 not getting it, either, if you're seeing the identical thing in both IE and FF. I have IE7 since I prefer XP to Vista.
<url removed> in IE7 looks as I intend it to look.
Thanks,
Jim
[edited by: tedster at 7:31 pm (utc) on May 17, 2009]
Let's hear you out first: name instances of where Firefox is not compliant with the CSS2.1 standard, where IE6 and IE7 are.
As a matter of experience, whenever legacy IE versions and FireFox disagree on how to render something it's virtually always IE that's in defiance of the standard, and other standard compliant browsers such as Safari, Opera etc will agree to that.
Also Microsoft has seen the error of their ways of the past and made IE8 far more standards complaint that any of its predecessors.
Finally know that most of your visitors avoiding IE do so consciously, pushing them to is is like pushing them away from your site.
So my position is fully opposite of yours: It's the legacy IE versions that are the problem for it's non-adherence to established standards.
It only applies it to the 'a' tag, not the 'TD.'
Moreover tables get a lot of freedom from the standard, better not use them for layout purposes.
I have IE7 since I prefer XP to Vista.
Your sample code doesn't tell the TD to have ...
It does in fact:
height: 18px;
width: 195px;
If FF can't parse tables, then "turd" is an understatement. They're used in about every e-commerce app of which I'm aware.
Anyway ...
IE7, looks as it should.
FF3 looks like junk.
Another fix would be to open in IE7, do captures and then have mouseover images ... but if you gotta add a bunch of everhead so a "faster" browser can handle it, what good is the "faster" part?
Sorry, gang. Moz is junk until it can do some pretty simple stuff, IMO.
Jim
[edited by: tedster at 7:45 pm (utc) on May 17, 2009]
[edit reason] personal urls removed [/edit]
W3C Validator - HTML [validator.w3.org]
W3C Validator - CSS [jigsaw.w3.org]
Your sample code doesn't tell the TD to have ...It does in fact:
height: 18px;
width: 195px;
if you refer to:
TD.list a {
[...]
height: 18px;
width: 195px;
}
Anyway ...IE7, looks as it should.
FF3 looks like junk.
Ah intend.
- It's not cause your code validates that it is saying what you think it is saying.
- It's not cause legacy IE versions render your code as intended that your code is saying what you think it is saying.
I'm not sure you're going to be convinced here, but once you cool down, hopefully you'll reread what's below and reconsider.
Do try to this approach next time:
- Do not look at what you create in IE at all
- Make it in your choice of browsers that are standards compliant (Opera, Safari, -yes= Firefox, ...)
- when it's done in one of them, test it in the others of that list, just to meake sure you're not abusing a feature in the one of your choice.
- now declare your code finished, don't change it anymore.
- test it in IE8: you'll see it render it properly in virtually all cases
- test it in IE7: you'll see some minor problems if you're lucky, some major ones all too often. Correct them using a conditional comment (so you don't have to worry messing it up again in the other browsers)
- test it in IE6: you'll see mostly the same issues as in IE7 and a bunch more. If it's holding you back by it's lack of support for e.g. selectors that you used, consider IE7.js as a solution to a bunch of it's issues, and add the rest in conditional comments.
This is the fastest way I know of making CSS backwards compatible with legacy IE versions.
... well then no: it tells the <a> inside the <td> to have a certain size.
Yep; already tried breaking them up. Still good in IE7, not FF3. So that should address the other request: an example of where CSS2 works in IE but not FF. Plus, I've even gone in and added additional W/H attributes in the TD tags as well. If the fix were that easy, I'd never have taken time to vent here. (read: still nada in FF/Moz; AOK in IE7).
I think I'll add "This site best viewed in Internet Explorer." And then move on.
Meanwhile, I'll query: is the CSS, inline or separated, 2 compliant? Follow on: does it work in FF?
My quick-capsule review stands. FF is a turd.
Jim
to vent here
I fully agree dealing with differences in browsers is one of the most frustrating aspects, but you're pointing your finger at the wrong target.
First look at your own code.
tedser gave you a few URLs above, I strongly suggest you let it loose on your code. (I got 45 HTML errors and 29 CSS errors when I checked it, the CSS included some parsing errors.)
Next reread what it means -according to the standard- to assign width and height on an inline element.
Then read what tables should do when faces with content too large to fit according to the standard.
BTW: the standard is CSS2.1 not CSS2, that one is replaced long ago.
You can find the standard here:
[w3.org...]
E.g.: width is here:
[w3.org...]
note it says:
Applies to: all elements but non-replaced inline elements, table rows, and row groups
If a width (if you would set the <a> to display: block), is applied to the content area, the padding goes around that, hence setting your table cell to the same width will yield a content that's too wide for the cell.
Take a look at how tables are supposed to get width according to the standard:
[w3.org...]
Note there are two modes, which are you using ?
Proving that a browser does something wrong involves:
- reference to the standard
- code that proves it
and then review by others ...
It's pretty easy to do that for IE6 and IE7, and it's been done hundreds of times already. Many of the bugs even got names assigned to them. There are few instances against all other still in use browsers that remain unfixed.
To state something -that's not even valid code- renders as intended in legacy IE versions and not in other browsers means that the other browsers are wrong, is plainly absurd to me.
But I'm more than happy to let you disagree with me.
Venting, I'll admit solves nothing; albeit my home town is Seattle, serial murder capital of the world, I think. So we consider venting a healthy exercise :^)
Griping, however, can affect change. (companies are not deaf to the vox populi; very-mcu the contrary)
But I followed your steps and have about a 90% fix .. FF still has some alignment issues ... and IE7 is still perfect, as it has been, in every solution I've tried. I will further follow your advice and whack the TD in lieu of DIVs or whatever. Eventually, I'll get it (note: I wouldn't have without your superb help. MANY THANKS.)
But am I alone in thinking that what's seemingly obvious is IE works better? Is that truly counter to what most think as Tangor noted? Essentially I'm being told, 'Don't view in IE 'cause it's just too dang intuitive?' If the others only work in a VERY TIGHT box, would that not make them lesser solutions? I'm no Redmondinsta, but I gotta tip my hat to the kids at the Microsoft campus when it comes to browsers. IE interprets what the others do not, in spades.
Just my opinion,
Jim
PS (Tangor): the majority opinion can be flawed. Most believe in a creation theory of some sort; most voted for GW Bush, twice; and most use IE. One can agree with all or any part of those majority-held choices/beliefs/feelings. I prefer more indepence in my thinking ;^) Cheers, Jim.
Also see threads for "browser corrections" wherein ALL the browser companies are equally guilty of interpreting what the page should look like rather than returning errors for non-compliant code in the interest of "user experience". That's what keeps tag soup in business.
Me? I use the KISS method. Tables if necessary, though rarely these days, CSS for appearance of FONTS (very minimal layout). My sitewide CSS is pretty short compared to many.
(added) I'm ignoring religion and politics... neither of which can be found in the WC3 Standards. :)
(added again) The EU is unhappy with MSIE already and seeks to kill it, so you'll be looking at Opera, Safari and Firefox as your browser of choice... just a different kind of politics.
KISS I save for fans of oddly-dressed rockers ... and of course for when the girlfriend appears to be in a generous mood. ;^)
OK; now I've added sex to the religion and politics :^)
Cheers, y'all ... now a Texan ... too many serial killers in Seattle:^)
Jim
Kidding, no hard feelings. To the contrary. With help from folks here 90% is now closer to 99%.
But if sloppy code looks great in IE, I gotta say, it's more intuitive than Moz-stuff by a long shot. In my book, that's better. To heck with compliance standards (now I'm really sounding Texan. Rules?).
Best,
Jim ... time to hog hog wild on Shiner Bocks, the best beer ever put in a keg. That's beyond debate :^)
In fact, if you code according how ANY browser renders your maqrk-up but you ignore validation, then you can often tie yourself into knots that cannot easily be resolved. That's because each browser has its own unique set of error-recovery routines.
The motive of the browser developer in doing that is to be user-friendly - but those error recovery routines do not align with each other cross-browser. To get a sense of just how far browsers go in trying to accomodate non-valid code, see the thread Modern Browsers Actively Patch Broken Website Code [webmasterworld.com].
So you can have non-valid code that looks great in your preferred browser and is hopeless in other browsers.
Swa gave you good advice. for lower frustration levels, develop your pages with validated code and monitor their look frequently during development, using one of the more standards compliant browsers. Then patching up any oddities for other browsers at the end of development is usually straightforward. And the most common problems are also well documented around the web if you need to do research. But if you start by assuming that standard behavior is actually a bug, then help will not be easy to find.
I can't speak to IE8, but I'll take your word for it that it too is opting to follow the path others are setting: we adapt; they do not. I don't see that as evolutionary by any stretch of logic.
Sorry. But it's what I believe.
Best,
Jim
Or, as I really do, code compliant, code simple and clean, and let the content rule the roost. Life is too short to swim upstream. And that stream is getting muddied these days as IE slips closer to 50% market. Nose cutting to spite face just doesn't make sense. Attempting to get code to do something it is not designed to do will only result in heartburn.
Us Texas boys know there's only so many kinds of ponies and they all ride a bit different, but we have to ride any of the broncs in the remuda if we're gettin' the herd to market.
And hopefully I'm not alone in seeing the irony that while I'm told the problems are more intrinsic to IE I'm at the same time told to never develop for it first insofar as it's too forgiving. Huh? *Too* forgiving?
