For some reason IE9 renders Arial font bolder than other browsers such as: IE7, IE8, Chrome, and Firefox. I have looked for the reason in the CSS but couldn't find anything wrong.
Another thing that happened is that I had word-spacing of 1 or 2 pixels in most of my website, but IE9 showed it too wide, so I made conditional css for it with normal word-spacing.
You can see the difference in the attached screenshot, and also find it in this temporary link:
http://pat.co.il/shirg/matanuziel.com/
Any ideas will be appreciated.
Thanks
The problem is the browser, not your site.
Internet Explorer 9 uses sub-pixel positioned ClearType to render text by using DirectWrite. This can cause rendering differences compared to other browsers and is expected behavior. It can cause text to blur slightly more, just as you're seeing.
As a side note, you should consider using TypeKit if you want to use non-standard fonts and have them render (resonably) well for all users. Note that there will still be minor rendering differences across browsers, probably on the same order of magnitude as what you're experiencing here.
And as Alan stated, using normalize.css is a good idea.
It might be worth looking at normalize.css. I don't know if it'll address your specific issues, but I've found that it's a nice starting point.
Related
A button in Chrome vs Firefox:
the baseline in Firefox seems slightly higher for the text. Is there way to lower the text? Just adjusting the margins based on browser?
Chrome CSS:
Firefox CSS:
The fonts were different. Though they are the same in CSS, they weren't being loaded properly so one of the browsers was using a fallback while the other wasn't. To help debug this document.fonts.check is very useful.
Thanks Temani Afif for the pointer in the right direction.
Use normalize.css. Most differents between browser will gone https://necolas.github.io/normalize.css/
Browsers have different base settings. Probably FF default line-height smallest then chrome. Anyway, Nobody find this different in normal using ;)
I've been playing with CSS3 transforms- rotations- and embedded fonts.
Some fonts completely disappear in Chrome when I apply a rotation.
Does anyone know why chrome blows this up?
What makes a font susceptible to this behavior?
Screenshot
So maybe y'all don't think I'm crazy- The text only shows up (kind of) after I try selecting it.
You weren't including the font correctly, try it like this:
http://jsfiddle.net/DFmtJ/1/
(tested on windows XP, Chrome 11.0.696.68 and 13.0.782.220)
------Edit--------
Cried wolf, the font that was being loaded was another one :/, though it is working for me on Chrome as in your first demo.
Webkit is an awful renderer in my opinion. As a web designer/developer, I take into account how my design looks at every magnification. Webkit handles this extremely poorly. Margins, padding, and borders all get rendered extremely poorly across various magnifications and there is no CSS you can use that is "cross-zoom" compliant in WebKit. Zoom in and out of any webpage in IE, Firefox, Opera and it is consistent. Take a look at this site, for instance:
http://development.mminc.co/davidphotos/
Try using the carousel at the bottom at different magnifications in IE or Firefox. Works fine, right? Now try the same thing in Chrome or Safari. BOOM! A developer's nightmare! Please, if anyone knows of any tricks of the trade to get Webkit to behave with something that even Trident is able to successfully do I'd like to hear it. I've heard of a jQuery zoom plugin, but that is sort of a last resort. I've looked everywhere for the issue but no one even mentions Webkit zoom issues. It's like it's taboo or something. Personally I think it's one of the biggest blunders of the modern browser era, especially when such a (otherwise) great browser like Chrome is giving me more trouble with presentation issues than IE7.
EDIT: I feel I should be more general and use an example where it is obvious only HTML and CSS are implemented.
http://www.gamespot.com/
Webkit forces a line-break with the top menu w/ zoom tests, but other browsers don't. It is a major issue with the engine and if there are any concrete solutions I'd like to hear them. If there isn't then I think this issue should be addressed and resolved immediately; it is an eyesore to users and a nightmare for developers. The fact that it isn't addressed anywhere on the net is troublesome.
This isn't answering how to fix WebKit zoom issues in general, but it should help with your specific problem.
You're using jCarousel.
Even the simple demo shows the same problems you describe.
So, that plugin is simply broken when it comes to zooming with WebKit browsers.
You could either ask the author of the plugin for advice, or find a different carousel plugin.
For instance, this one doesn't seem to have any problems when you zoom in using a WebKit browser:
http://www.thomaslanciaux.pro/jquery/jquery_carousel.htm (look at the "dispItems" demo)
Should i check in all? or in any one is enough because all share same rendering engine Webkit.
My question is related to HTML CSS rendering.
I know one difference Safari for windows and MAC both have Font smoothing (anti -alisaing)
Is there any other differences?
There's definitely a difference between Chrome and Safari due to Safari's font rendering. In Safari text tend to be a bit bolder due to the anti-aliasing algorithm and can sometimes take up a few extra pixels on the screen.
Also keep in mind that Safari uses the SquirrelFish javascript engine while Chrome uses V8.
I have found a difference in the way Safari and Chrome select SELECT boxes. I think Chrome seems to ignore line-height whereas in Safari line height seems to make a difference.
Safari Windows 5.1.7 v's Chrome Windows Version 22.0.1229.94 m
I think this is to do with the default user agent style?
I would check, yes.
Whilst the browsers all use the same rendering core, they're not necessarily on the same version (and there are multiple versions of Safari out there in any case).
Also, as slebetman says, font rendering is quite different depending on OS and anti-aliasing settings too, so you need to be aware of that.
Shadows are fast&ugly in chome; slower&prettier in safari (and firefox). IIRC there was some difference in CSS3 transitions too - but really, these details are still in flux anyhow and change from version to version.
In practice, I only check one of the two regularly, which is generally fine. Before putting major changes online, it's obviously not a bad idea to check again, but during development, it's not worth the hassle; they're so similar anyhow...
There are major and minor differences. Do check!
Minor: full support for CSS3 border-radius in Chrome. I've read about, but can't find, this in Safari.
Major: zooming in Chrome zooms everything. (This is the behavior in almost every browser.) Zooming Safari zooms text but leaves other things unchanged. Your ever-so-carefully-laid-out form is highly likely to be trashed if the user zooms in. Leave lots of extra space.
I'm having major rendering issues in Safari with the web application I'm working on. Most of the design is done with divs using absolute positioning. This renders fine on Internet Explorer, Firefox, Chrome, Opera, Netscape, and konqueror. In Safari, it's just a jumbled mess.
Does Safari lack support for absolute positioning of div elements?
What is the best way to trouble shoot and find out what is going on with the safari browser?
UPDATE: I'd like to note I did find the issue, and I would like to thank everyone that gave suggestions. It was the WebKit's "Inspect Element" that gave the most useful information. It appears that their were conflicts with inline styles and styles from the CSS. While safari grabed the styles from the .css file, the rest of the browsers were using the inline styles. i was able to see those conflicts with the information in the tool that was suggested.
The problem may lie somewhere in your JavaScript; one of the most noticeable things about Safari is that it likes to stop executing JavaScript after any errors.
CSS is likely not the issue, since Safari has better standards and CSS support than any other browser out there (alright, I said it.)
Use the built-in Web Inspector in a recent nightly build of WebKit to track down your issues.
1. Safari's support?
Safari is actually a decent browser. If it has its flaws, they aren't any worse than those of any other browser, and they aren't of the class of the old IE browsers, which had very serious problems and lacked even basic support for web standards. To answer you question specifically, yes, it does support absolute positioning.
Safari can certainly render modern X/HTML CSS designs, and since your audience is largely using Safari anyway, you may as well forget the notion of dismissing the browser. It's a good browser, and in any case we're powerless to change it. We simply need to take care of these bugs, whatever they are.
2. How to go about debugging?
Without having a specific example, it's not something anyone can really help you to do. It seems fair to say that you're having some issues controlling css-based layouts. You may have some invalid markup, which in some cases could produce the kind of extreme browser-specific abnormalities you've described.
Start with the basics. Validate your markup and CSS.
Markup Validator
CSS Validator
Make sure you're rendering in standards mode.
Seek out answers to specific questions
If everything validates and you're still having problems, you'll have to track them down one by one. Even if you rebuild the page, piece by piece in Safari in order to see where things begin to unwind, it will be worth it to do. If during this process you really don't understand why a certain behavior exists, you'll at least have a specific question that you can use to poke around for answers. It may be answered already on SO, and if it isn't, you can ask it.