I am trying to execute a card flip animation that holds throughout IE10+, but I'm hitting a rut given that the IE has no support for transform-style: preserve-3d;. I've seen multiple "fixes" for this, but none will work with my code. I am hoping somebody from this awesome community can step in and help me figure out this hot mess!! Any and all help would be very much appreciated! Thank you so much in advance!
http://jsfiddle.net/rebeccatcook/E8mLp/
Internet Explorer supports transform-style since version 11 so you should be fine there. IE10 supports 3D transforms, but as you point out, does not support the transform-style property which specifies how nested elements are rendered in 3D space. This is why you are not seeing your "Back text".
I'm not sure what "fixes" your referring to but the common practice is to simply leverage "fall-back animations" that are supported by the specific browser version. For IE10 I would use modernizr to sniff browser features and append custom CSS classes to implement a a simple fade in/out effect.
If you absolutely have to have this effect without JavaScript, you could use IE Matrix filters but it can be a time suck getting it to act right. Here's a reference point: http://www.useragentman.com/IETransformsTranslator/
Good luck!
Related
I've got a fancy css neon effect on a navigation. This works perfectly on any major browser except on IE < version 10.
The problem is that there is no text shown on IE 8+9.
I have no Idea where to start with a fix so I would be very grateful for every tip.
It doesn't need to be working with IE8, IE9+ would be fine.
The effect can be found on the page http://www.arch-on.ch/team/philosophie/
Many thanks in advance for any helpful input
CSS property text-shadow is not supported by either browser (IE8, IE9) and box-shadow is only supported by IE9
You best solution is just not to have the glow effect in those early browsers and give users of those browsers a warning that the site looks better in a modern updated browser.
To achieve what you want in those browsers you would have to create transparent png images and swap them out on :hover. But this because real messy (especially when you have to keep adding new text or change text) and is not efficient.
Do not create more work for yourself with something that just applies to aesthetics.
Try Quirksmode for before: and after: content: http://quirksmode.org/css/user-interface/content.html
There is also a plugin called CSS3Pie that "makes Internet Explorer 6-9 capable of rendering several of the most useful CSS3 decoration features". Maybe implementing this is okay for you. http://css3pie.com/
Otherwise you have to avoid using CSS3 if you want to go down to IE8. Check this chart for browser compatibility of CSS3 statements:
http://www.normansblog.de/demos/browser-support-checklist-css3/
Cheers
Frank
I am trying to implement some css3 involving 3D transforms in a new project i am working on.Although i managed to overcome the limited InternetExplorer support i am having problems making Firefox work.
There seems to be excessive flickering when transforms take place either i use the rotateY(deg) or rotate3d(x,y,z,angle) method and only in Firefox. In Chrome or even in Internet Explorer they work fine.
You can see what i mean in the JSFiddle here.(Hover on the divs to see effect.)
Is there a way to fix and still have a 3d effect that will work in all three Firefox,Chrome and IE?
Edit2: I can confirm flickering in Firefox version 26.0.
You could look at this question Here for other possible ways to prevent flickering.
Edit: I apologize if this isn't much of an answer. I would have commented, but I'm not permitted to.
Edit3: The flickering for #test3d is extremely bad. The animation is rendered completely unviewable and seems to back-track several times before finishing.
With lots of talk and bickering among developers about how IE breaks standards, is it worth supporting mozilla and webkit CSS?
Examples
-moz-border-radius
-webkit-border-radius
Of course there are many more, but I just want to know everyone's thoughts.
Thanks
For IE, we were (are?) using proprietary features in order to eliminate rendering bugs. At least, in the case of FF and WebKit, we're using them to improve the design. It's progressive enhancement in this case. No one suffers if they have no border-radius feature, but we as developers get more satisfaction for using some CSS3 features. Our designs are more pleasing and W3C gets the feedback it needs in order to improve and then approve the CSS3 draft.
Rounded corners are proposed in the W3C CSS3 working draft. The proprietary extensions in Gecko and WebKit are already likely to conform to the working draft.
Given that rounded corners are purely aesthetic, there's no disadvantage to users with browsers who do not support rounded corners.
When the standard becomes final, it's a simple matter of replacing these proprietary rules with the standardised ones.
If you define -moz-border-radius and -webkit-border-radius, make sure and define -khtml-border-radius (Konqueror), -opera-border-radius, and plain old border-radius as well (for future-proofing purposes).
We tend to use the proprietary methods followed by the CSS3 spec version for when the method becomes more widley supported.
http://www.w3.org/TR/css3-background/#the-border-radius
If necessary (which isn't often) we use JQuery + IE conditional tags to render the same for IE.
http://malsup.com/jquery/corner/
http://www.quirksmode.org/css/condcom.html
It really all depends on your target audience, we wouldn't generally use unsupported CSS on a public facing site as 89% of our users are still using IE 6/7 so it would be useless to most of them.
We currently use it on a few admin systems and some internal systems; mostly to give the design team exposure to the new techniques.
Consider your target audience, browser specs based on analytic's and how necessary it really is first.
I'd support both, IE still has a big chunk of the user space, with Firefox and others (opera, safari etc..) occupying a smaller percentage of the browser market.
using mozilla only stuff might be ok if you can control what your clients are using, by recommending it in some way (if you're writing a web app. with a fixed user base) and even then someone will still insist on using IE.
I know its a pain in the backside supporting both, but I don't think web developers have much choice in the matter :(
In the case of border-radius, I'd say use the Mozilla/Webkit syntax if you don't mind IE/Opera users having squared corners.
If you need everyone to see the same thing, it's best to stick with the old techniques for now. Similarly, any non-universal CSS (say, using #font-face to download a custom symbol font) which is going to break the site for some people should stay out.
There's no harm in implementing CSS3 features so long as they degrade gracefully. So long as rounded corners, or what have you, aren't critical to your layout there's no harm having them there for the people who are running bleeding edge web browsers.
I know from personal experience that having those properties(specifically the corner radius ones) are very much a time-saver. Now of course it would be nice if css would just implement it into itself but right now I think that those properties are very helpful. I see no reason why we shouldn't support them. Mozilla's and Safari/Chrome's engines are just trying to make life a little easier.
I don't think this is a good practice. However you'd like that the site you're working on appears the same on every browser. That's why that's not a solution. It's not professional to have different layouts on different browser.
But if you don't care about that, or your application is based on only that browser - so it's completely fine!
I just noticed that Stack Overflow employs Firefox only CSS to round the corners of the user badges on the front page. It's an interesting idea but what would be the pitfalls and advantages of using Firefox only CSS (aside from the blatantly obvious ones)?
-moz-border-radius:6px;
-webkit-border-radius:6px;
Above: The CSS used to round corners on the Stack Overflow front page.
The main problem would be, as I see it, that your css wouldn't validate. Other than that I see no reason why not to use this type of platform specific features as they don't cause any harm to users whose browsers don't support the features.
The advantages are that it's much easier than using corner images or other tricks. The obvious disadvantage is that your page doesn't render as intended on IE, which is still used by more than half the world's web users.
Overall it's situational; I imagine SO gets a higher than usual proportion of people using Firefox, so the IE issue is not as relevant. And rounded corners are a minor visual improvement, so if some people see it and some don't, it's not that big a deal.
I agree with BeefTurkey.
I might even go further and call it a case of Progressive Enhancement with CSS. To borrow liberally from Understanding Progressive Enhancement, I'd consider rounded corners to be part of the colorful candy coating around the chocolate-covered peanut.
And eventually CSS3 will be ratified and border-radius will be standardized. -moz, -webkit and -ms prefixed styles can be removed and replaced with their standard equivalents. Your CSS will validate and people using browsers that don't support CSS3 will still have a completely acceptable experience with people using browsers that do support CSS3 will get an enhanced experience.
Alternatively you could continue to use the proprietary CSS in addition to any standards to give an enhanced experience to an even larger audience. It would really depend on how much effort maintaining all that CSS requires and how important you feel the enhanced experience is to your audience.
It works in Firefox and the Webkit-based browsers (notably Safari and Chrome). There are no alternatives for IE or Opera.
The main reason to use it is when you want to give rounded corners to elements that display on top of patterned or unpredictable backgrounds, which is not possible otherwise. Normal CSS and images can take care of other situations.
It's also ridiculously easy to implement and surely works for more than half the people on this site.
Pitfalls are of course that it's not supported in other browsers and its not in the W3C specification.
The current implementation is bad (both in firefox and webkit) since they do not share the syntax.
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.