I've been enjoying using these effects and I don't mind them gracefully degrading in older browsers, but Internet Explorer 11 and Edge 12 still don't support them.
This isn't the first time Microsoft avoids adopting specifications that are widely in use everywhere else.
I understand Edge was a big project and the IE browser was also re-worked from the ground up in IE8/9, but it sometimes almost seems like IE/Edge deliberately makes things difficult for designers and developers in the lack of continuity between it and what other browsers like Firefox, Chrome and Safari are adopting.
Are there reasons for this that I'm failing to recognize?
CSS Filter effects are supported as per https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/dev-guide/css/filter-effects/
I have seen them on my own website https://trajano.net/ except for one scenario that is Do CSS Filter Effects work when position:absolute in Edge?
Related
I need to get the effect of -webkit-mask-image in Internet Explorer 10.
Unfortunately, the only way I found with google is putting all the contents into an SVG, which is not applicable.
Experimental masking features in Webkit browsers are just that, experimental. Until they gain more wide-spread adoption, or are officially adopted by the W3C, we shouldn't expect to see other browsers implement the same feature.
Consider an alternative solution. For instance, Martin Beeby was able to accomplish a "masking" effect simply by using 2D Transformations, meaning his solution is supported as far back as IE9.
Good morning all.
Today I'm struggling with the following code: source on jsFiddle
What I have been trying to achieve is a seemingly simple image rollover effect where 'a mirror' of an image covers the original one using some css3 effects.
Chrome 12 transforms the image perfectly
Firefox 5 stops transformation when the image runs into mouse cursor
IE9 - there is no transformation at all, the image is just shaking
Opera - not checked
How do I do this cross-browser compatible?
I think I got it to work in Firefox 5 the way you want. See http://jsfiddle.net/X2eN6/7/
According to CanIUse.com, IE9 doesn't support CSS3 Transitions, so I guess that's why it's not working for you in IE9.
The browsers that support the feature are Firefox (from v4), Chrome, Safari and Opera. But it's worth pointing out that transitions currently require a vendor prefix in all browsers that support them.
A vendor prefix means one of two things: either the spec is not finalised yet, so the feature is subject to possible change in syntax, or else the browser's own support for the feature is not yet considered complete.
Chrome has been supporting transitions for ages, so it's no surprise that everything works there. Firefox has only recently added it, so since they require a vendor prefix, you should take that as a warning that things may not be guaranteed to work 100%.
I'm unsure which browser is the best for a web development. I know that Firefox is the most favoured for the common but it also does tolerate programming failures, so it is not 100% strict.
With what browser should I develop my website to have the best result on all other browsers, so I don't have to fix too much in the CSS?
From personal experience.
I use chrome. For me 100% fine on chrome is like 70% on IE, so I switch between the two a lot.
Chrome 100% = 98% FF , 99.9% Safari and 70% IE.
This is what I've noticed from my experience.
I personally use Chrome, as its built-in developer tools work great, and it has the widest HTML5 support. However, that's not necessarily a good thing because even if your website works 100% with the better browsers, it will probably break with IE.
If you need your website to work with IE, you should constantly test with it. Use the lowest common denominator.
At this point, all of the major browsers implement a lot of CSS3 features a little differently (box-shadow vs -moz-box-shadow vs -webkit-box-shadow for instance). Honestly, your best bet is to use IE, Opera, Firefox and Chrome (I'm pretty sure Safari and Chrome both run off of webkit, so they should be the same). As for what to use as your primary browser, it all depends on what you're looking for really. I enjoy using Chrome, but others swear by Firefox (I find it too clunky).
Now as for older browser support, well that's just an entirely different discussion ;)
Simple answer, all the major ones.
When you develop for the web it's best to think from the view point of the user viewing the site. The main issue is that each browser will render a webpage a little different and that is the main problem you need to solve.
To help with this issue, you'll need to work with some cross-browser rending web-apps such as http://browsershots.org/
To more directly answer your question, I'd go with Chrome with Firebug. Asides from that, you should be able to create CSS browser-compliant sites with practice.
Good luck!
Develop in the browser of YOUR choice with the best development tools for YOU (e.g. Firebug, FirePHP in FF or the Developer Tools for Chrome). Try to use standard, crossbrowser compatible framworks for JS, CSS and available templates for HTML like "Boilerplate" HTML 5. And then test everything continously on the mainstream browsers (IE, FF, Chrome, Opera, Safari).
This way you won't waste your time afterwards fixing browser specific bugs...
I prefer using Firefox, simply because there are so many useful tools for it - Firebug, Web Developer's Toolbar and so on - but really it doesn't matter as long as it's not Internet Explorer.
This is because IE has so many quirks that it's best to get it right in all other browsers, then worry about adding workarounds or other fixes to make it look right in IE (getting things right in IE can take a very long time).
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 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.