I have two issues I have ignored so far, but I will really appreciate some light shed onto them.
First: how can I solve differences between Safari, Chrome and Firefox and the various tags that their engines render differently? Should I just write down the right attribute for each in the same css rule? Is there no better way?
Is there a way to separate the CSS sheets for these browsers as I am doing for IE? Is this recommended?
Second: What about CSS3 attributes? Should I just write them again in the same rule after the CSS2 attributes?
Will this cause problems validating the CSS with WC3?
Welcome :)
If you start without the prefixes, you should write the code, generally, with all the semantically appropriate tags, first.
Then, you can decide what your goals are.
If you want W3C compliant CSS files, then you'd need to strip out the vendor specific prefixes by default. This would then allow the latest browsers to pick up the standardised CSS properties if they support them.
This will target less of your market than you might wish, so then you should ask if progressive enhancement is a possibility. If you can reasonably enhance the visuals by using css applied after the page has loaded, such as applying styles with jQuery, MooTools or Prototype libraries AND these libraries are already serving a purpose in your website, then you could apply additional styles with those libraries (and possibly use them in conjunction with Modernizr to determine which elements you may want to additionally support.
However, it's likely that a browser will skip a property it doesn't understand and will render the ones that it does, so I'd suggest that if you code it to W3C Standards first and then add in your additional vendor prefixes 'before' the final (correct) one, then you'll likely have satisfied reasonable measures to be compliant and meet design needs.
Edit:
There is a little bit of confusion between validation results from:
http://validator.w3.org/
and writing valid code related to vendor prefixes to get CSS effects cross-browser:
List of CSS vendor prefixes?
for working on some cross-browser CSS, you might find http://csspie.com, for IE compatibility with some CSS3 properties, useful along with http://www.colorzilla.com/gradient-editor/ for cross-browser gradients and http://cssplease.com for code that gives you alternative vendor prefixes, including different versions of IE support for many different properties.
In terms of validation, here's what W3C says about it: (see comments here: W3 VALID cross browser css gradient,) and official docs here: http://www.w3.org/TR/css3-syntax/#vendor-specific
If you code according to the specifications first and test your code out against that and then add in your vendor prefixes to get the same effects on the browsers you want to support (see progressive enhancement: What is Progressive Enhancement?) then you can be more confident that your code is supporting the appropriate standards, adding value to those with more advanced browsers and still useful for those without additional features (see also WAI III compliance, 508 compliance and others if you want to write a more inclusive site).
Caveat: Web Apps may not always be inclusive or follow these guidelines depending on who the audience is.
If you are using jquery on the site you may want to look into PrefixFree. It's a script that adds the vendor prefixes for you, so for example your put border-radius:6px; in yor css and it reads the browser and adds the appropriate vendor prefix for you via js. I like it cause it keeps my css docs more readable.
Related
I encountered this question while browsing the Q&A section of an online course on advanced responsive design. I found an answer for it, shared it, and decided to post it here as well in case anyone else might have the same dillema.
The dillema is that it could be a lot easier for ensuring browser compatibility if we could define a different style for certain browsers that behave differently from most, e.g. Internet Explorer and, in the case of my website at least, Safari.
So how do we go about doing that? Check out my answer below to find out, and feel free to contribute if you think you know a better way to target specific browsers for specific media queries unique to them.
Using caniuse (https://caniuse.com/), look for a specific property that is only supported by the specific browser you want to target. Then, using the #support query, target that browser with the property you've found is unique to it. Then, whatever styling you apply within that query will only apply to the browser(s) that support(s) the property by which you defined the query.
That is, the properties inside the brackets of a #support query are used to define when - for which browsers - the styling inside the curly braces will apply; they do not need to be the same, that is, you do not need to use the same property styled within the curly braces to define the query in the brackets, so you can choose any property that targets the specific browser(s) you want to display the styling for.
Update:
I found this site that seems to provide the solution to targeting specific browsers and browser versions in the caniuse style, sparing you the need to test each property by hand:
http://browserhacks.com/
This article offers a briefing on how to use it:
https://www.templatemonster.com/help/how-to-create-browser-specific-css-rules-styles.html
Update:
For Internet Explorer only, older versions only, you can create a separate stylesheet to load for them using conditional comments in your HTML. This can be a copy of your general stylesheet, tweaked to work on old IE versions, but loaded only if those versions are detected, therefore not interfering with display on other browsers. They are not, unfortunately, usable for other browsers. This article explains how to use conditional statements.
https://www.quirksmode.org/css/condcom.html
Update:
The most effective solution to this problem seems to me to be to implement some javascript that detects the browser version and then applies specific styles or even modifies the DOM based on the browser(s) you target.
This explains the principle and some applications nicely:
Is there any equivalent to IE conditional comment for chrome and safari?
This, if rather old, is still a very useful such application:
http://rafael.adm.br/css_browser_selector/
And that's it! The ability to ensure browser compatibility with most any browser!
How can i know when to use the prefix -webkit-, -moz-, -ms-, -o- in css properties? I see a lot of "inconsistency" in some attributes, in some properties the programmer only puts -moz-, in the other he puts the all 4. Is there a reason for that?
To know what prefixes to use is based on what browsers you want to support. A good place to find out what browser versions require a prefix is caniuse.com.
The variation is due to what browsers other developers have decided to support. If you see more prefixes then the developers (site owner) of the site have decided on a higher/deeper level of support for older browsers. Fewer prefixes will support fewer browsers. As to why? There could be a lot of reasons some are target audience and feature requirements (Web APIs).
You can go the manual route but a lot of developers will use tools like Autoprefixer or a CSS preprocessor like SASS or LESS. These tools give you different ways of defining what prefixes to use.
With something like AutoPrefixer there's an option to list what browsers you want to support and it figures out what prefixes etc. are required to support those browsers based on the non-prefixed version.
With a CSS preprocessor like SASS or LESS you can create a mixin (basically a function) that will add the prefixes you've defined.
I apply a simple rule of thumb: never put a vendor prefix (let user update their browser instead, and avoid non-official/non-yet-finalized CSS rules).
See http://shouldiprefix.com/ if you still want to know which prefixes are "required" (or "worth worrying about").
Last, CSS preprocessors can handle these, but it's often a useless pain to add to your development and release stack (except if you're using other stuff that vendor prefixes, or if you have to deal with old browsers like in companies intranets).
awesome question.
A lot of Programmers use CanIUse to determine if a particular CSS property is supported in all of the browsers they would like to support. If it's not fully-supported in all of the browsers they wish to support, the programmer should use the vendor prefix (i.e. -webkit-).
Example Scenario
Say the programmer wanted to use the Transform property (CanIUse#Transform). See how Android Browser 4.4 & 4.4.4 have yellow warnings in the top right? Hover over them and notice it says 'Supported with -webkit'? This is exactly. when you would add the -webkit- vendor prefix.
I disagree that you have to add them all (although, it really doesn't hurt anything). If you just do a bit of research before you use newer CSS properties, you will have cleaner CSS/SASS/LESS/etc while supporting all of the browser your heart desires. :P
I do think there are awesome tools out there to do this automatically. Xenos mentioned a few.
Best of luck in your CSS endeavors.
These different properties are termed as "vendor prefixes":
-moz- = used for Mozilla Firefox
-ms- = used for Microsoft Internet Explorer
-o- = used for Opera
-webkit- = used for Google Chrome and Apple Safari browsers.
It's always a good approach to use all the vendor prefixes for the css you're applying, in order to address to the browser compatibility of the webpage you're developing.
However, css preprocessors like LESS can handle this thing, if you happen to use them. I personally use LESS to handle all this vendor prefixing stuff and it's really simple. If I weren't using preprocessors, I would still have considered writing vendor prefix css along with the default property name.
It's always a good thing to keep addressing about the compatibility issues well in advance than to run into some and fixing them later.
Try using vendor prefixer tools like:
https://github.com/less/less-plugin-autoprefix
If you want ensure that will work on each browser you need add all of them, some websites dont support old browsers so there is no need to care about browsers which you decide to not support :)
Here is the solution I found, if you are using Visual studio code go to extension and search for css-auto-prefix
Why don't browsers autocorrect CSS3 transitions? The only difference between the Safari/Chrome and Firefox CSS transition is "moz" and "webkit". Surely firefox could just add an autocorrect feature to change every instance of "webkit" in the css to "moz" and the problem would be solved. Or is there something more?
Normally the -moz and -webkit are for CSS selctors are properties that are are specific to the the browser engine. The selector could be unstable, or act differently in each browser as they refine the behavior.
They don't want to "autocorrect" to the other implementation because the other browsers interpretation of the CSS property could be different. It could cause problems about what CSS property should "win" in the event of a conflict. Lastly, it could increase development time for each browser since they would need to figure out what the other browser engine is doing.
In the end what you want is to not use any -* prefixes at all. For that to be possible there needs to be a standard syntax and behavior defined by the, wait for it, CSS standard. Then instead of repeating *-opacity: ... several times with different prefixes, you just write opacity: ... once, like any other CSS declaration.
Vendor specific prefixes are there to allow browser specific behavior regardless of what the current standard says. It allows vendors to implement new features for which no standard exists yet, or to test the implementation of features before committing to it. The end goal is always to implement all features defined by the standard in the way the standard defines it; but you won't get there over night. New features need to be tested as widely as possible to find problems with their implementation or possible problems in the standard itself. This testing happens by making features available through vendor specific prefixes.
When you use a documented standard feature like opacity, it's pretty sure that it works consistently across browsers (*cough*letsforgetabout*cough*IE*cough*forasecond*cough*). When using a vendor specific prefix feature, it means you're using a feature at your own risk which is subject to change and/or may not work consistently (yet). Browser vendors don't touch each others prefixes for a reason, they work towards the standard and eventually make the feature available without prefix.
I am aiming to support just IE10+, and the newest versions of the most popular browsers. I am wondering if there is a css reset just for those specific browsers ignoring old IE and Moz fixes.
I couldn't find any, but perhaps I have overlooked some when I was searching on Google. I plan to create my own of course, I just don't want to redo work if there is a library out there I can utilize.
Thanks!
Modern as in HTML5 resets?
Blue Print Framework has a nice reset
http://html5reset.org/
Then there is YUI, http://code.google.com/p/reset5/...
A CSS base and reset is meant to apply to all HTML elements you use, so that the browser never has to reach into its default styles to render anything on your page. A few elements have been removed* in HTML5, so you could remove these from your reset if any are present, but that might be over-optimizing. For what it's worth, the YUI 3 CSS base and reset account well for modern browsers.
EDIT:
Correction: They have been marked obsolete; compliant browsers such as IE10 still need to support them, so unless you are sure your page/application will never use any of them, they should not be removed from your base/reset.
Normalize is worth a look as an alternative to a CSS reset. Instead of resetting all styles, it targets the ones that need to change to change to give you sane, consistent results across browsers in a smaller file size.
This means that there is not so many styles to clutter your dev tools debugging. It also fixes some common bugs. It's a mainstream project, that's well maintained, focuses on modern (ie8+) browsers and is used by some high profile sites.
Read more about it here.
As I'm sure you all know, Internet Explorer can handle simple gradients. Here is a snippet from Twitter Bootstrap, for example:
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffff', endColorstr='#e6e6e6', GradientType=0);
However, I've seen some people use two CSS rules (one for IE < 8 and one for IE 8), like so:
filter:progid:DXImageTransform.Microsoft.gradient(GradientType=0, startColorstr='#7fbf4d', endColorstr='#63a62f'); /* For Internet Explorer 5.5 - 7 */
-ms-filter: "progid:DXImageTransform.Microsoft.gradient(GradientType=0, startColorstr='#7fbf4d', endColorstr='#63a62f')"; /* For Internet Explorer 8 */
My question is, is the second rule really necessary? Twitter Bootstrap is quite thorough, yet it doesn't use any "-ms-filter" rules. According to this page, the -ms-filter attribute is an extension to CSS, and can be used as a synonym for filter in IE8 Standards mode.
My suggestion:
Use CSS3Pie -- http://css3pie.com/
This is a JavaScript library for IE6, IE7 and IE8 that patches in support for several CSS3 features, including gradients.
Yes, you can use the horrible IE-specific filter styles if you want, but CSS3Pie allows you to use standard CSS styles for these features. Much easier.
To actually answer your direct question:
Yes, the -ms-filter style is usually required. IE8 will always us it instead of filter, which is used primarily for IE6 and IE7. In some cases filter will work in IE8, but not all, so it's best to use -ms-filter to ensure IE8 compatibility.
[EDITED]
Why did they change it? Because when they released IE8, Microsoft made a big point of trying to be "standards compliant".
For a browser to be standard-compliant, it should use a vendor prefix for any CSS property it supports that is not a finalized W3C standard. So by adding the -ms- prefix, Microsoft were trying to (belatedly) undo their pollution of the global CSS namespace.
In addition, the quotes were added, because the old filter syntax without the quotes was invalid CSS (mainly because of the colon after progid), and caused issues with some browsers. (I had an instance some time ago with Firefox 3.6 where it was dropping all styles following a filter style that rotated an element - took ages to work out what was happening).
The fact that Microsoft retained backward compatibility with the original filter syntax, was largely a matter of pragmatism. MS couldn't afford to break all the sites using the old syntax. But there was a strong implication from Microsoft that developers should use both because they would drop support for the old filter style in subsequent versions of IE. As it turned out, they dropped support for both filter and -ms-filer in one fell swoop, but the implications given at the release of IE8 were sufficient for it to become recommended practice to provide both syntaxes in your stylesheet.
At the time when IE8 was released, XHTML was the new flavor of the month, and writing code that validated perfectly was top of the list for a lot of developers. This was probably a strong driving force in the change of syntax to include the quotes. Because of the stray colons, it is impossible to write CSS that validates using the old filter style. Using the new -ms-filter styles instead allowed people to write valid CSS. As good ideas go, this one didn't really work out because of course people had to keep using the old syntax anyway, but the intent was good.
It's worth pointing out that other proprietary styles were given the same treatment. For example, you can use -ms-behavior in IE8 instead of the old behavior style. No-one uses it. Why? I don't really know.
Another fact worth knowing is that the W3C are in the process of standardizing a CSS property called filter. It will do a completely different job to the Microsoft filter style, and work completely differently. If/when it is standardized and browsers start supporting it, there will be an explicit clash between the two syntaxes.
Seems like you answered your own question. Yes they're needed. Microsoft trying to get more in line with the standards means that some versions of IE have their own slightly different syntax rules for the filter property.
In IE7 just filter: followed by the progid:DXIma... etc will work. But for IE8+ there is the IE7 fallback it may use in compatibility mode, and the more proper -ms- prefixed property for filter, denoting a vendor specific css property, and its value inside qoutes.
What harm would it do to leave it in?
If the browser doesn't understand the line of CSS it will just ignore it.
Those two lines of CSS are almost identical. I would hazard a guess that Microsoft decided to change the syntax for proprietary CSS from IE8 onwards utilising the - (hyphen) prefix which other browsers have been using for yonks.
Technically the CSS isn't W3C compliant either way, so another line of proprietary CSS can do no harm.
It's not worth trying to understand IE at the best of times!