I've seen CSS styling along the following lines:
input::-webkit-input-placeholder {...}
or
input:-moz-placeholder {...}
And they raise a few questions for me:
What are these things called? (I'm having trouble googling them.)
Is there a comprehensive list somewhere of which ones are supported by which browsers?
Which meta-CSS languages (Sass, Less, Stylus, etc) have support for these, if any?
Thanks!
The thing with one colon called pseudo-classes, it is used address different states of object (like :hover and ‘active).
Shot description and list can be found there: http://reference.sitepoint.com/css/css3psuedoclasses
Description on w3.org: http://www.w3.org/TR/selectors/#pseudo-classes
The thing with 2 colons called pseudo-elements, it is used to autogenerate content or to style part of content like first letter of first line.
Description on w3.org: http://www.w3.org/TR/selectors/#pseudo-elements
There is lot of browser-specific extensions of this list through. That didn't documented in css3 standard.
You can find list for Mozilla's browsers here: https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions in the section "Pseudo-elements and pseudo-classes".
Can't find good list of Webkit pseudo-elements and -classes through.
They're called vendor specific properties, and they typically are a vendors version of a CSS3 format. Since CSS3 isn't a standard yet, technically any browser that implements them are implementing a vendor specific extension.
-moz mean Mozilla, aka firefox, etc..
-webkit means webkit based browsers, ie Safari, Chrome, Konqueror, etc..
-ms
See: http://reference.sitepoint.com/css/vendorspecific
Related
I've got this SCSS code:
.gradient-text {
color: mix(#cea427, #fbe758); // Fallback to average of 2 colors
background: -webkit-linear-gradient(0deg, #cea427, #fbe758);
-webkit-background-clip: text;
-webkit-text-fill-color: transparent;
}
Fiddle
At first I just wanted to make this code work in webkit-based browsers and then add different approach for firefox, but I've found out that at least latest nightly firefox runs this code too, even if it's vendor-prefixed for webkit.
I won't worry if there was only one property, which can be either supported by firefox or not. But having 2 properties makes me nervous about the situation where only one of them is working. For example, supported -webkit-linear-gradient and unsupported -webkit-background-clip will work vastly different from my expectations. So, is there any way I can check browser support for multiple CSS rules and gracefylly switch to fallback if at least one of them is missing?
And also, is there any list of foreign vendor prefixes support (like -webkit- prefix support in FF)?
In these sort of situations, I always find it very helpful to check MDN. In this case, you can check the articles for linear-gradient, background-clip and -webkit-text-fill-color. Near the bottom, there is always a section titled Browser compatibility. It lists, in a table, browsers that support the CSS rules and in footnotes goes into specifics. For example, about the -webkit-text-fill-color, it says that
[1] This feature is implemented behind the preference layout.css.prefixes.webkit, defaulting to false. Since Gecko 49 (Firefox 49.0 / Thunderbird 49.0 / SeaMonkey 2.46) the preference defaults to true.
This should answer your question on why the -webkit- prefixed version is supported, and since when. Also note that at the top, the article mentions
This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.
So: ye be warned.
In this particular case, you might be able to get away with what you want to do, at least in Firefox and Chrome. Other browsers... that's trickier.
Your other question is if you can gracefully switch to a fallback when a rule is not supported. Unfortunately, this is not possible in pure CSS. It is possible to write rules that specifically target Chrome or Firefox though, but I would advise against using those. You could maybe check for support using JavaScript, but that is something I wholeheartedly advise against.
Finally, "is there any list of foreign vendor prefixes support (like -webkit- prefix support in FF)?" Sort of. Again, MDN is usually very complete and up-to-date. Hope that helps.
I am running through CSS3 tutorials and I have come across these new requirements. Obviously each browser has different implementations, so you must tell your style sheets to use them. How do you know when a certain browser requires a certain prefix? Is there a single resource that tells you? Is there some sort of magical ultimate include in CSS that will take take of it for you?
On http://caniuse.com it's reported if a CSS property needs the prefix.
Example: http://caniuse.com/#feat=border-radius you can see that old versions of Safari and Android need the -webkit- prefix.
Remember also to place the prefixed properties before the unprefixed one.
The > character can be used with CSS to select an element that has a certain parent.
The benefit I see here is that I can apply styles only to a certain level of a list for example. Like menus - first level is orizontal and has different rules than 2nd level+. so i don't need to worry about resetting properties for lvl 2+
Anyway, can I depend on >? Is it supported by all browsers and without buggy behaviors?
The child selector > is fully supported by IE7 and later, and not at all in IE6 and earlier. Of course, all versions of all other major browsers in use today support it fully as well.
All CSS2.1 selectors are well-supported by IE8 and later so you can use them today, unless you're writing legacy code that needs to cater to IE6, in which case avoid them where possible.
The SitePoint Reference does mention an obscure parsing bug related to comments that affects IE7, but it only breaks the selector if a comment is there. You don't usually put comments in the middle of selectors unless you're doing so as a hack, so you don't need to worry about this bug.
Related: Are CSS child selectors a W3C standard? (Of course they are!)
It's part of the CSS2 standard: http://www.w3.org/TR/CSS2/selector.html#child-selectors so modern browsers should support it.
According to this quirksmode.org, only IE6 and earlier do not amongst major browsers. I only see IE6 used in very situational cases (like dedicated machines that don't receive software patches).
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!
Where can I find a complete "browser specific css attributes" reference?
I mean some attributes such as -moz-border-radius that is just for Firefox or -webkit-min-device-pixel-ratio. These examples work just in a specified web browser. I want a complete reference for these attributes.
Each vendor should maintain a list of custom CSS extensions. The ones I've found are linked below.
Mozilla (Firefox)
Opera
Safari (merged with standard CSS properties)
Internet Explorer (outdated)
Ones I can't find ...
Chrome (same engine as Safari, some slight differences in vendor extensions supported)
Peter Baverloo's table is the best reference I have been able to find for all browsers in one single page.
Check out css3files. It's a site that talks about all popular css3 functions, in what browsers they work and what code you need to use.
You can take a look at this page: http://caniuse.com/
It also shows most, if not all, HTML5 and CSS3 features and their support.