I'm developing a 'one page' website for a customer.
The website displays as I want it in most browsers however I'm experiencing problems in a specific combination of Internet Explorer 8 installed on Windows XP.
Because of a combination of requirements from the customer and the design of the graphical designer different elements are placed on top of eachother and need to fade in or out based on navigation.
All works fine in browsers like IE9&10 (Including IE8 document property in developer tools), Chrome and also IE8 on Win2K8 server.
However in IE8 it seems like the transparency of invisible elements is inherited by 'would be' visible siblings at the same position.
I've searched for different solutions and have tried different things like:
opacity: 0;
-ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=0)";
-filter: alpha(opacity=0);
also with an additional but mostly unneccesary:
display: block;
or
zoom: 1;
But none of the above does the trick.
Has anyone experienced, or solved, this problem before.
Or is fading multiple elements at the same position in IE8 just not the right way to go.
See this fiddle for my intended functionality:
http://jsfiddle.net/6HZGw/11/
PS. I tried to post an image of what exactly was my problem but since I've just registered this is not possible as a spam prevention measure.
So here is the link to the problem:
http://img338.imageshack.us/img338/4458/ie8f.png
And the link to the expected view:
http://img255.imageshack.us/img255/8391/chromeothers.png
IE8's opacity filter is really awful. It kinda works some of the time, but it's riddled with bugs and gotchas. jQuery makes it slightly less painful, but even then it's easy to get caught out by one of the quirks.
I don't have IE8 or XP available to test it on right now, but I have been down this path myself and suffered similar results, particularly when dealing with multiple elements, and even more particularly when those elements are a mix of text and graphics.
As I say, I can't try it out for myself right now, but my guess is that you've hit one of those problems that just can't be resolved. So I would suggest looking for alternative solutions.
In our case, after a lot of work, we ended up completely abandoning the idea of fading the elements in and out because of this, and switched to a tactic of sliding them out from behind other elements. The effect was similar enough that the customer was happy, and it worked in all browsers.
Related
After some changes to our site, we are seeing that when certain pages are loaded, the page quickly changes width. This occurs every time on webkit browsers Chrome and Safair, but only rarely on some other browsers.
I have not been able to produce the effect at all on Firefox on Windows, Firefox on Mac, nor IE9 and IE11. It seems to rarely occur on IE8 and IE10. I have not found a pattern yet that causes it to appear on IE8 and IE10.
To understand what might be causing this, it would be good to know if certain styling attributes take an initial value while the page is loading but them assume some other value by the time the page is fully loaded. This could explain what is happening.
I should add that this problem developed after some changes which "should" not have caused this issue. Basically having to do with adding URL rewriting to eliminate duplicate pages. Clearly some side effect is operative.
At the moment we only have the code on development servers, so it would not be that easy to actually see it right now, although that is the obvious first question from a responder. So at this point, the question is more "what generically causes pages to reformat under Webkit."
UPDATE: the problem seems to be traced to Google Translate. When I remove that from the page, the problem goes away. Put it back; problem comes back.
Oddly, it mostly impacts Chrome! IE10 and 11 are exempt, and with even earlier IE versions the problem is much less.
I can readily demonstrate the temporary widening of the page just by reloading the page.
I experimented with trying to put the div containing the translate div instead a container div and setting some attributes on that. So far I have not found something that mitigates the problem.
We have suppressed Google Translate recently because it started adding other junk to the bottom of the page. That other junk is gone but we will continue to suppress it due to this new jumpiness.
I believe there is some clever way to contain the issue, but have no more time for it.
I have confirmed that the issue is definitely caused by Google Translate being on the page.
I've been working in this tooltip library since yesterday. I don't know if this problem is for my sleep or what, but I can't figure what's happening.
The subjacent idea about this tooltip library is simple: The user adds in any HTML element the custom data attribute (I mean data-) with the message that he wants to display in the tooltip, and it has to appear. There are some options to add, like the orientation of the tooltip and if the user wants to "cut" the words inside the tooltip.
Here's an example:
<div data-msg="Hi, I'm a tooltip with a text veeeeeeeeeeeeeeeeeeeeeeeeeeeeeeery large" data-orient="right" data-break="yes">Hover me and the tooltip will show!</div>
Everything is fine with bottom, right and left orientations, but when I add the top orientation, the browser adds a species of "border" at the bottom of the tooltip.. I don't know why, but I can't fix it.
Is strange because in the others orientations the problem don't occur.
You can see the problem in the below image (the first tooltip has data-orient="top" and the second tooltip has data-orient="right".
If anyone knows how fix this problem, I'd like to explain me what happens.
Here's the Fiddle.
Thanks,
Leo!
EDIT: I'm working with Chrome 28 version and my OS is Windows 7.
This is a workaround, not a real solution - but shouldn't have any serious side effects in this case (no guarantees, though, see below). And I have little explanation other than this appears to be a Chrome rendering bug.
Add this to [data-msg]::before:
-webkit-backface-visibility: hidden;
backface-visibility tends to fix quite a few Chrome rendering bugs, regardless of the fact that it actually has to do with 3D transforms - it appears to fix this case too.
The reason that it fixes problems possibly has to do with Chrome using a different (hardware accelerated) transition engine the moment you add anything to do with 3D transforms to your element. This may have performance penalties, which leads us to another non-sensical rule that at least used to improve performance if you run into problems:
-webkit-transform: translate3d(0,0,0);
ETA: -webkit-transform alone actually seems to be enough to fix the problem. Experiment with the two, and see if any of them cause other problems.
There have been reports of -webkit-backface-visibility crashing iOS. So do test it there, and try with translate3d instead - or disable the fix specifically on iOS (and live with the bug if it appears there).
As posted in the comments, here's a more minimal example of the problem - although it sometimes fails to... fail, it should mostly have the unwanted darker border at the bottom:
JSFiddle
The bug seems to be caused by transitions combined with border-radius and opacity. Possibly inline-block and padding have a role in the bug too, but sometimes their removal fixes the border, sometimes it doesn't. I hope the backface-visibility workaround is more consistent.
I've been developing an app specifically for modern browsers and have made very heavy use of the box-shadow property.
Until recently this has been absolutely fine on all supporting browsers. However about a month ago when testing in Chrome I noticed that scrolling was 'extremely' slow, to the point of being almost unusable.
Over the past month I have tried ripping out scripts/messing with my html structure, everything you can think of until finally today I have found the cause.
With box-shadow / webkit-box-shadow disabled on all elements that I had it set for, the problem disappears.
What strikes me as odd is that it worked fine in Chrome until around a month ago. Incidentally the scrolling on the windows version of safari is fine, albeit a little slower than IE/Opera and Firefox.
Is this a known problem? Does anyone have a workaround for this?
And most importantly, is there another method of replicating the same effect without using the CSS3 property?
There was a bug report opened and closed in Webkit last year:
CSS3 box-shadow causes scroll-lag (slow performance) on Safari 5.0.2?
It seems Chrome has an open bug on an older version:
http://code.google.com/p/chromium/issues/detail?id=95164
Airbnb discussed the problem recently, and actually changed their final design because of it:
http://nerds.airbnb.com/box-shadows-are-expensive-to-paint
There's a group of people recently gaining an interest in programmatically testing CSS performance. Here's a bookmarklet you can use to start your own testing:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
In the meantime, you're right that hacking border-image is an option. Check it out here:
Scroll Lag with CSS3 box-shadow property?
It may not be the box-shadow particularly, maybe something else in your app just consumes way too much resource and box-shadow just happens to be the cherry on top.
Nevertheless, I can confirm that box-shadow on overly long or large elements causes performance issues. I work for a certain drag'n'drop form builder and tried setting box-shadow on a 900px x 1000px div and the scrolling started lagging up immediately. Ours is a very ajax heavy web-app, so others might afford to get better results, but still, I think this is a valid example.
So I went old-school and created images instead. I think the most proper way to get image-box shadows working without too much image load is to have an element with a fixed width.
What I did was three image slices. One slice from top to just beneath top corners, one from the bottom to just above the bottom corners and one thin slice from the middle which I used on a div as background image with a repeat-y so that I can dynamically change to divs height fit the users page.
You can slice even more to fit any box but it becomes too much(at least 5 extra images and 8 extra divs to be precise) for a box-shadow imo.
I'm having some CSS issues that seem to only occur in chrome. The site in question is liveinthelead.com, and it's still being worked on so if you notice any other strange problems feel free to let me know, I won't be offended. My main problem is this though:
In all of the browsers I've tested except for chrome the site looks fine. However, in chrome, on the main page, the middle post in the three-post divs are shifted down about 20px. But when I open up the developer interface, they shift back to where they're supposed to be! Maybe it's just a local problem, but here are some pictures of what I'm talking about. If you don't experience the same issue then maybe it's just something weird going on with my computer. Cheers.
When I initially load the page
After I open the developer console
One thing that I noticed is that in your div#three-post you set float:left to div.member1 but not to the remaining div.member2 or div.member3.
That's where I would start investigating the problem. Maybe you should set the remaining two divs to also float left. You may need to clear them afterwards too.
For the sake of convention — and so that you don't encounter this confusions again — use IDs for selecting specific elements, e.g., member1, member2, member3, and use classes for selecting multiple elements that should share the same attributes.
I'm unable to replicate on Chrome 15.
=\ could be a good thing! Try another computer!
I'm writing a web app. It's only ever going to be used with IE8, so I'm not concerned with the behavior of any other browsers here.
So: I know how to custom-style a button using CSS properties e.g. background-color, border, and so on. However, when you apply styles that way, the resulting button looks like a blocky table cell, nothing like the nice, glassy-looking button that IE8 renders by default.
Is there some way to add a tint to the nice glass-looking button? I.e., it looks just like it normally does, but with a red outline instead of blue, and a red highlight on mouse-over?
Or is this something I'm going to have to do by hand with images? Again, IE8-specific methods are perfectly acceptable.
Thanks!
-dan
There isn't really a filter that will get you as close to the default in IE, though you can get pretty close using the button tag and standard css. It will not look the same in all versions of IE though.
Here's the filter reference though if you want to try other things.
Regardless of browser, one of the quickest, easiest, most widely tested methods for styling buttons via markup is Jquery UI's button It's a matter of adding a few tags to the class element, and you've got a button based on an link, button, or input field. For styling, you can handle styling via CSS, or via the very well done ThemeRoller option, where you can control everything from text size to background type via a simple gui interface--and you can change on the back end or even the user end on the blink of an eye, even via drop down.
One caveat, since IE is non-standards compliant, rounded buttons fail gracefully to square--with proper styling.
I realize that you have determined that you can use a proprietary solution for IE, and in your case it might be just fine over the long term. But in my experience, that's a really dangerous path to follow. What if the actual long term is longer than your anticipated "long term?" You're specifying that it's acceptable to be proprietary to a browser that's well behind the accepted standards, is already a version behind, and uses unsupported (by universal standards) solutions to solve problems. Conceivably, that version is going to get tougher and tougher to find, and if Microsoft holds true to their patterns, once you install IE9 it will effectively render your computer difficult of downgrading. And, I can't emphasize enough that IE's market share is dropping like a rock, which is scary considering basically 95% of the machines out there have it pre-installed. All it's going to take is one overzealous IT director with "security in mind" to render your programming efforts moot. Sorry for the rant, but IE proprietary code has bit me hard more than a few times...
I'd have to double-check, but you should be able to use a combination of a background color and use a transparent PNG or GIF as the "background image" to add the highlights.
All things being equal, I've rather embraced the flat, square button - finding ways to make it work well with the design - but then again I've always been a straight line, square edge kind of guy. :)
As others have mentioned, you do want to be mindful (within reason) of what you may have to handle. It's quite possible that before the next re-write you're going to have to deal with IE9 - writing code that works well in IE8 and IE9 would be the most prudent approach.
Have a look at http://www.webdesignerwall.com/demo/css-buttons.html and also http://css3pie.com/.
Combining those you can get nice looking buttons in IE as well..