I've recently came across a project with css rules like this:
#media screen and (-webkit-min-device-pixel-ratio: 0) {
#header .searchform input:-moz-placeholder, #header .searchform textarea:-moz-placeholder {
line-height: 140%;
}
}
In my opinion this is kinda weird, as I know vendor prefixes are used to target different browsers. What about a situation like this then, when you use a different vendor prefix compared to the parent? Is it just a typo from a previous programmer? Or is it a perfectly valid rule that would apply in certain scenarios? If yes, what would the scenario be when this rule gets applied?
Looks like a careless mistake. There are no known implementations of Gecko that recognize -webkit-min-device-pixel-ratio — the prefix that Gecko uses is min--moz-device-pixel-ratio1 instead, which has since been deprecated in favor of the standardized resolution. And there are no known implementations of WebKit or Blink that recognize :-moz-placeholder.
Either way, this snippet of CSS is meaningless to both engines. At best, in WebKit/Blink, you get an empty #media screen and (...) {} rule, and in Gecko, you theoretically get #media not all { ... }, which means "this rule will never be applied in any situation".
1 Unlike the code in the question, this is not a typo.
-webkit-min-device-pixel-ratio:0 Is a browser hack to target Safari 3+ and Chrome 1+.
input:-moz-placeholder Is a pseudo-class that has been deprecated in Firefox 19 in favor of the ::-moz-placeholder pseudo-element and only targets Firefox browsers.
Given your code that your code is asking to target Safari and Chrome only to then run code for FireFox only; it's ultimately code that will never run under any circumstances and is likely a mistake.
Additional information can be read on the Safari 3+ / Chrome 1+ hack here:
https://css-tricks.com/snippets/css/browser-specific-hacks/
and more information on -moz-placeholder can be found here:
https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-placeholder
and more information on style placeholder text in general can be found here:
https://css-tricks.com/snippets/css/style-placeholder-text/
Related
I am playing around with CSS-animated SVG elements and came across the problem that even though all technologies, which are used, are supported by some browsers the combination is not, i.e. CSS-animated DIVs work but SVG elements don't. I am wondering if there is a way to detect if a browser is capable of animating SVG elements using CSS.
Here is a jsFiddle with an example. It works in the latest versions of Chrome, Firefox and Safari. But when opening it with e.g. Firefox 5 only the div rotates while the rect doesn't.
You can add an event listener to check for the completion of an animation iteration, and within the corresponding event handler set a flag like supportsSVGKeyFramedAnimatedProps = true (if the iteration never completes then it is not animating).
elem.addEventListener('animationiteration', eventHandler, false)
This would allow you to 'fall forward' to your SVG animation, instead of providing a fallback.
I am wondering if there is a way to detect if a browser is capable of
animating SVG elements using CSS
Simple Answer: Yes you can as stated by #jhpratt.
You can detect if a browser supports CSS-Functionality with only CSS.
The #supports CSS at-rule lets you specify declarations that depend on a browser's support for one or more specific CSS features. This is called a feature query.
Example:
#supports (display: flex) {
div {
display: flex;
}
}
#supports not (display: flex) {
div {
float: right;
}
}
MDN Link: https://developer.mozilla.org/de/docs/Web/CSS/#supports
Long Answer:
You will always have some cross-browser issues.
The problem you have encountered is bothering every Webdeveloper. Still there are ways to get around with this Browser-Support-Problem:
1. You can check "can I use" for compatibility:
Link: http://caniuse.com/
It is recommend to look up any functionality which is questionable like animations.
2. Use an autoprefixer in your workflow:
With the help of an autoprefixer you don't have to worry most of the time about using CSS with a prefix like -moz-, -webkit-, etc. This tiny helper will do the trick for you, you can even tell some autoprefixers which browsers you want to support.
3. User 3rd - Party libraries:
There are many libraries out there which you can use to detect the browser and version. If you want to be sure that your animation is secure to use, you can simply use the provided animation from the libraries and of course look the compatibility up before on their respective websites.
Some Big Names:
Angular: https://angularjs.org/ (use ng-Animate)
JQuery: https://jquery.com/
Greensock: https://greensock.com/
there are many more, jsut search the world wide web.
4. Use CSS Hacks to detect specific Browsers:
It is possible to use so called CSS-Hacks. They are specific CSS calls, which only apply on certain browsers.
Some examples:
Internet Explorer/Edge 8 only: #media \0screen {}
firefox ≥ 3.6 only: #media screen and (-moz-images-in-menus:0) {}
Opera ≤ 9.27 AND Safari 2: html:first-child .selector {}
You can look up more Browserhacks here: http://browserhacks.com/
Conclusion:
It is possible to detect specific browsers, but it is not possible to detect if the brwoser is supporting the given feature with only CSS. That is why you will always have some hard times with browser support.
Hope this helps.
Regards
I believe that the SMIL animations detections in modernizr should do it. https://modernizr.com/download?smil-setclasses
I'm using it in a pretty involved set of css/SVG chart animations. Just wrap a fallback in the following tag:
.no-smil{ }
http://codepen.io/msbtterswrth/pen/greWzy
I haven't done exactly what you're looking for, but something similar (providing an animated clip-path as defined by SVG when the browser supports it and falling back when it doesn't). You can use media queries looking for pixel ratios to determine if a broswer is moz or webkit and provide the fallback animation outside the media query and provide the preferred animation in media queries that indicate a browser that will support it.
//fallback animation here
#media (-webkit-min-device-pixel-ratio: 0) {
// webkit animation here
}
As for older versions of Firefox? I don't know how to do that in CSS, but I'm not sure going back more than a few versions of Firefox or Chrome is a common use case.
Vaguely related to this question, but not quite the same. I'd like to target Chrome ONLY, without targeting Safari.
I used the following media query, but it targets both Chrome and Safari:
#media screen and (-webkit-min-device-pixel-ratio: 0) {
h1, h2 {
font-weight: bold;
}
}
Chrome does a great job at rendering the header elements in bold even though a bold version of the font I'm using doesn't exist. Safari... not so much. Hence the super specific targeting. For reference, the font is Cody Star.
There are browser-specific CSS hacks that might work for this problem now, but they certainly aren't supported.
IMHO, your best bet is to add a class to the body tag using JavaScript that reads your navigator.userAgent and use that class (body.chrome for example) to target Chrome.
Safari,Chrome,Opera all of them are Web-kit browsers, so it's very difficult to find a CSS or media query hack to target this browsers specifically,
but here is a JavaScript code that will target the Google Chrome,
not all the versions of Google Chrome,But Chrome 14 and later.
var isChrome = !!window.chrome && !!window.chrome.webstore;
if you want to know more information,please refer to my answer,for this question
can you please let me know how to write single statement to with specific for IE, Mozilla, Chrome.
Whether using this approach to target browsers specifically is a good idea or not is a seperate question in itself. However, assuming you have a legitimate reason to target browsers as you asked, there are couple of ways you can achieve your goal
CSS Browser Specific Selector Hacks
browserhacks.com has an exhaustive list of browser specific selector based hacks that will apply to only specific browsers. Also, as Mr. Alien suggests, this question details browser hacks well too.
CSS Browser Selector JS Library
This library will add classes to the root html tag that indicate browsers and more other potentially useful info: https://github.com/ridjohansen/css_browser_selector/
Once you've included the library, it . You can use those classes to target specific browsers in css similar to this:
.chrome .some-class { } /* Will only apply in chrome (all versions) */
.ie .some-class { } /* Will only apply in IE (all versions) */
.ie7 .some-class { } /* Will only apply in IE7 */
.opera .some-class { } /* Will only apply in Opera (all versions) */
The library will add a bunch of classes that can be used to target based on browser, browser version, platform, platform version, device, device version etc. Check the documentation in the github link for full details.
Is it necessary to have valid CSS? I am using Twitter Bootstrap for rapid web development and after running the two main Bootstrap style sheets through the W3C CSS Validator, I noticed about 600 errors.
My question is, my site looks good so why is it so important for the CSS to be valid?
Yes, it is absolutely necessary to have valid CSS. CSS is a programming language and as such, you must follow its language rules. Just because browsers tend to accept invalid HTML and try to render it, it doesn't make generating ill-formatted HTML a good practice. The same is true to CSS, although - fortunately - CSS rules are quite a bit stricter than HTML rules.
Another reason is that valid CSS has guaranteed behavior - if you write a rule, you can expect that rule to behave a certain way. (Buggy browsers, like all versions of IE aside.) If your CSS is invalid, any behavior you get is undefined and it may break when a patch release is issued for any of the browsers that you use for testing. Your CSS won't necessarily break but when you write invalid CSS, you get no guarantees of any behavior - you simply get some behavior that may seem correct to you but that may change any time.
If you have correct CSS mixed in with incorrect CSS, browsers tend to ignore the invalid parts (just how the specification tells them to) but each browser does it slightly differently. Similarly, while many people advise to use CSS hacks, I'd say not to, for the above reasons.
The CSS doesn't have to be valid to work. Browsers simply ignore the CSS that they don't understand.
Validating the CSS is a method to test if it follows the specification. If it does, any browser that is up to date with the specification used will understand the CSS.
It's somewhat of a debated topic really. The W3C tools are certainly good to use, but they tend to not account for a lot of modern code. Naturally, it's difficult for them to not only advance standards, but also make sure the tools they offer are accountable to new and inventive code.
In order to get websites to look good in all browser and across all platforms requires people to maybe stretch outside of the norms that otherwise would be "valid". It's tough to argue against a site that works perfect cross browser and platform even if the CSS isn't 100% spotless. That's my two cents.
Your CSS doesn't need to be valid (depending on who you ask), but if it is invalid, you should have a reason for the invalidity:
audio,
canvas,
video {
display: inline-block;
*display: inline;
*zoom: 1;
}
The validator has a parse error here because of the asterisk at the beginning of property. This is a obscure but recognized hack for targeting Internet Explorer. Other browsers will ignore the properties that it won't recognize but IE6/7 will read properties with asterisks.
input:-moz-placeholder,
textarea:-moz-placeholder {
color: #999999;
}
input:-ms-input-placeholder,
textarea:-ms-input-placeholder {
color: #999999;
}
input::-webkit-input-placeholder,
textarea::-webkit-input-placeholder {
color: #999999;
}
The validator error here is a result of vendor-specific pseudo-classes. Note than unlike unrecognized properties, if a browser doesn't recognize the selector the entire rule will be ignored so the vendor placeholder extensions need to be separate rules. This happens even when using the comma operator so:
input::-moz-placeholder,
input::-ms-input-placeholder,
input::-webkit-input-placeholder, {
color: #999999;
}
would be ignored in all browsers unless they recognized all three vendor prefixes.
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#fffbb450', endColorstr='#fff89406', GradientType=0);
This is the old-style IE extension for gradients. It ripples and causes a number of errors in the validator even though IE follows it and other browsers will not quietly ignore it.
width: auto\9;
The \9 is another IE hack that targets IE<=8
The bottom line is that if you are doing something non-standard, make sure you know why you are doing it.
Now a days there are different number of browsers with different number of versions.Some supports lot but some are not.So when you include styles it is always not possible to fit 100 % perfect.If your style works without any problem ok.But when it goes to different browsers if you get problem related CSS , You have to take care otherwise no problem.
yes its important, most of browsers follows the w3c standard when they load the html page. if your page don't have the valid css, in different browser it might appear different ways. Old internet explorers didn't followed the W3c standards which cost alot to the developers result in developer need always extra css for the IE to display page properly.
This question already has answers here:
How to make CSS visible only for Opera
(13 answers)
Closed 5 months ago.
The community reviewed whether to reopen this question 5 months ago and left it closed:
Original close reason(s) were not resolved
Is there a way to make some CSS rules apply only for Opera (11)?
body {background:0} /* default */
#media not screen and (1) {
body {background:red} /* OP 11 */
}
#media not screen and (orientation) {
body {background:green} /* for the earlier versions of Opera that pick the first media query's rule + chrome/safari */
}
Browsers tested:
red: Opera 11
green: Opera 10 and 10.5 + WebKit browsers
none: Opera 9.26 + Firefox 3.6 + IE9
It's related to the error-handling and also the fact that NOT negates the global result (WebKit browsers don't evaluate orientation correctly without a valid value). Since orientation is supported in presto 2.7 the second media query is FALSE.
The false orientation hack sounds like a good name to me.
Is there a good reason you want to do this?
I'd always recommend against doing browser detection. In almost every case where people want to use it, it's a better idea to use feature detection instead. If you find out if the feature you want is supported, then you'll automatically start supporting new versions of other browsers when they catch up, without having to constantly work to keep your site up to date as you would with browser detection scripts.
For feature detection, one of the best tools I can suggest is to use Modernizr.
For browser detection - especially brand a new browser like Opera11 - I can't really suggest anything that will be foolproof. The correct answer is to look at the User Agent string, but that can easily be changed by the user to spoof another browser (and often is, especially by Opera users, as they're the one most often trying to get around sites that do browser detection and try to block them)
You could try using http://www.headjs.com/
I don't know of a CSS-only way as Opera 11 is still VERY new.
You can either use server-side languages like PHP to detect the User Agent of the browser or you can use the freely available Javascript solution CSS Browser Selector.
The above solution does not yet include Opera 11, so let's check Opera 11's User Agent string by checking their references. (Actually they have their own article on how to detect opera)
Opera/9.80 (Windows NT 5.1; U; en) Presto/2.7.39 Version/11.00
When you now look at the Javascript of the above mentioned CSS Browser selector you can see it is just reading out the navigator.userAgent and comparing it to many variations - just add your Opera 11 variation and you are good to go (or wait until the developer updates the javascript - or even better, update the script and tell the author about it!).
Here you go......
/* Opera */
#media all and (-webkit-min-device-pixel-ratio:10000), not all and (-webkit-min-device-pixel-ratio:0)
{
here you can display anything you want just for opera
}
The following style would indeed only get rendered in Opera. See Webmonkeys blog post for details:
#media all and (-webkit-min-device-pixel-ratio:10000), not all and (-webkit-min-device-pixel-ratio:0) {
#myid { background-color: #F00; }
}
But keep in mind, that all sort of CSS hacks might not work anymore in the future.
So I would strongly recommend you to add the styles dynamic only for Opera with jQuery (jQuery.browser).
The read-only pseudo-class is a simple filter for Opera:
#foo:read-only { overflow: auto; }