I am going to be remodeling a website and will be using the -prefix-free script to eliminate my prefixes in the CSS. However, some of the CSS I will not be editing. This CSS does contain some prefixes. If I leave those prefixes in the CSS will -prefix-free still work correctly or are there reasons I should go through the CSS files and eliminate all prefixes?
In other words: Will prefixes in the CSS break or cause weird functionality in conjunction with the -prefix-free script?
-prefix-free will leave any properties already prefixed in your stylesheet alone. In fact, it will not add other prefixes for the same property or rule if you specify at least one individual prefix for it.
For example, if you have
-webkit-border-radius: 10px;
Then -prefix-free will not add -moz-border-radius for Firefox versions older than 4.0, nor will it add an unprefixed border-radius for any browser. WebKit browsers will apply the border radius as usual, since they understand -webkit-border-radius.
If you want -prefix-free to add prefixes for other browsers, you will need to change that to
border-radius: 10px;
So, it depends on which properties you want it to apply all the necessary prefixes for. If you want -prefix-free to apply prefixes everywhere that is necessary, you'll need to go through your stylesheet and remove any prefixes that were already there.
Of course, keep in mind that you may want to keep prefixes hardcoded for certain properties, such as WebKit-specific pseudo-elements, -webkit-appearance and -webkit-text-size-adjust. Again, this depends on the property; you may have to research and decide based on your layout needs.
The script's homepage contains a test drive which you can use to preview the results for prefixed and unprefixed properties. Bear in mind that the results are tailored to the browser you use to run the test drive, so if you add border-radius and run it in Firefox 4 or later, you won't see any changes. However, if you place a -webkit-border-radius declaration instead, you'll still see that -prefix-free leaves it untouched in the preview pane, without even adding the unprefixed property, regardless of the browser you use.
The -prefixes are only for supporting features that are present in the browser, but have not been standardized yet, or have not complete implementation.
Since a lot of spec has been standardized, the requirement of prefixes for certain properties are no longer required, and have been present since a lot of versions. example : border-radius.
You can have a look here, to see which properties still require the prefix.
There will be no effect when using a CSS, with prefixes for some elements, while no prefixes for the others.
Related
I am finding that styles are being applied in a different order in IE edge compared to chrome.
Example
on this site http://videojs.com/ inspecting this element
<div poster="http://vjs.zencdn.net/v/oceans.png" preload="auto" class="video-js vjs-fluid vjs-paused preview-player-dimensions vjs-controls-enabled vjs-workinghover vjs-v6 vjs-mux vjs-user-inactive" id="preview-player" lang="en-us" role="region" aria-label="Video Player"><video id="preview-player_html5_api" class="vjs-tech" preload="auto" poster="http://vjs.zencdn.net/v/oceans.png" tabindex="-1">
...
</div>
IE
Chrome
what is the reason for the difference?
The order that each browser lists the styles in is not the order that they are actually applied to the element. This can be easily seen by comparing the two lists. Although they may list certain selectors in a different order, both are applying them equally (neither browser is applying something that the other browser isn't). Each browser vendor is free to set up their development tools in whatever way they like - there are no standards to follow on that. So, it's perfectly reasonable to expect differences in how various browsers report information in their tools.
There are specific rules about CSS selector "specificity" and what selectors will override others. Both of those browsers are standards complaint and apply the specificity rules equally.
Only when two selectors have identical specificity, and when the properties set in those selectors conflict with each other, will the location of the selectors (relative to each other) in the overall CSS be a factor.
Both your div and your video elements have ids as well as classes applied to them, so there are multiple styles being applied with different specificity. Also, the video element is nested within the div, so inherited CSS properties come into play.
Understanding CSS specificity is the key to solving your issue.
I have a website which I support as far as IE8, no further.
When I first launched the site, I decided to use CSS vendor prefixes for CSSs elements such as border-radius, box-shadow etc. I did this from a complete noob standpoint.
However, is a better approach not to use them and simply let browsers catch up rather than patch up for the sake of uniformity?
No, you shouldn't remove all of them, however you may as well remove the ones which are no longer required.
How can I find out which prefixes are no longer required?
Can I use... is a great resource for checking browser support for various CSS, HTML and JavaScript features. If you perform a search for box-sizing, for instance, it will tell you that all modern browsers have partial support for this and that Firefox requires the -moz- prefix. You can also view all of the CSS support tables on just one page here.
How can I clarify that the prefixes are no longer required?
There are a couple of online resources which display information about browser usage. An example of this is StatCounter. StatCounter offers browser version statistics which can be filtered on time. If we look at the last 3 months, we can guestimate that we should still aim to support Firefox 20+, Chrome 25+, IE 8+ and Safari 5.1+.
Personally, I would just keep your vendor prefixes for now - this still remains professional practice - those browsers who don't need them, will simply ignore them anyway.
Our approach is to drop those which aren't needed.
border-radius
box-shadow
box-sizing (soon? firefox still uses it. Noted by #James Donnelly)
opacity (not a prefix, but no need for the ms-filter thingie)
inline-block (same here, no need for inline+zoom fix)
If you really want to get rid of prefixes, one of the solutions you can try is -prefix-free. It's a javascript plugin which loops through your stylesheets and, according to current browser removes the unused ones.
Although I didn't test it, I think it will definetely lower the performance.
You can also remove prefixes for properties which doesn't have a signifact meaning for functionality and/or user experience, like border-radius, box-shadow etc. You would have to test each element how it behaves without these properties. E.g. you have a button with border-radius: 4px. In a browser which doesn't support border-radius it will simply have rough corners. You must only consider if its worth sacrificing.
I'm working on a site that primarily uses the background-size:cover property for the background. However I'd like to support IE 7/8, I'm aware I could use IE conditional comments but checking for the property support would be more useful since it could support other old browsers as oppose to just IE.
I have the solution to the background issue, but I need to know when to add it with js depending on if there's support for the background-size property.
My question is, whats the best method to check for css background-size property in old browsers?
I have seen a few related questions but they all require using Modernizer, I'd prefer not using an extra library unless its the only option.
Thanks.
if( 'backgroundSize' in document.documentElement.style) would be the easiest way to go about it.
It seems like using this function would be more portable or reliable, because the alternative is to set an attribute:
element.style.setProperty(styleproperty, valuestring);
element.setAttribute('style',styleproperty+': '+valuestring+';');
The second method would also seem slightly more inefficient though that's hardly a concern.
But at least on Chrome, the style does not update on the page unless I use the setAttribute method.
The reason why this is a bit of an issue, is that I have potentially many different separate style properties I want to modify independently of the others. I have to do a whole lot of string parsing and processing if I can't make use of setProperty, removeProperty, etc. I have to pull out the style string, search it, modify it, and set it back in via setAttribute. Should work, but I don't like it.
Is there a reason for this? Is this a bug? My guess is that setAttribute triggers something for the browser to perform a re-render. What is a suitable way to force this update that is generally browser-friendly?
Setting the style attribute directly has consequences that may be undesirable: it will wipe out all existing styles set in the element's style attribute, and setAttribute is broken in older IE (and compatibility modes in later IE). Much safer is to use the element's style property directly to set only the style property you need:
element.style[styleproperty] = valuestring;
This will update the page immediately in all major browsers.
One caveat: CSS style properties (generally using dashes, such as in background-color) do not map precisely to properties of the DOM element's style object (generally camel case, such as in backgroundColor). There are also exceptions to this rule.
How can you detect if a browser supports the CSS attribute display:inline-block?
Well, here's what you can go if you want to do it purely by examining the bavhiour of the browser w/ javascript instead of user agent sniffing:
Set up a test scenario, and a control scenario. With, say, the following structure:
div
div w/ content "test"
div w/ content "test2"
Insert one copy into the document with the two internal divs set to inline-block, and insert another copy into the document with the two internal divs set to block. If the browser supports inline-block, then the containing divs will have different heights.
Alternate answer:
You can also use getComputedStyle to see how the browser is treating a given element's css. So, in theory, you could add an element with "display: inline-block," and then check the computedStyle to see if it survived. Only problem: IE doesn't support getComputedStyle. Instead, it has currentStyle. I don't know if currentStyle functions identically (presumably it functions similarly to the behaviour we want: disregarding "invalid" values).
According to the QuirksMode charts, the only mainstream browsers not supporting inline-block are IE6 and 7. (Well, they support it, but only for elements which have a native display type of inline.) I'd just assume it is supported and then apply a workaround for IE6/7 via conditional comments.
(Note: I'm ignoring Firefox 2's lack of support for inline-block and assuming the vast majority of users have upgraded to FF3, but brief googling didn't unearth any numbers to back that up. YMMV.)
If determining support from JavaScript is your only option however, you'll have to fall back to user-agent sniffing. The YAHOO.env.ua class from the YUI library is a handy chunk of code that you could copy and use. (It's BSD licensed, doesn't depend on other parts of the YUI library, and is only about 25-30 lines without comments)
By the way: There is a neat way to implement cross-browser inline-blocks in IE6+, FF2+, Opera and WebKit with CSS alone. (Not valid CSS, but still only CSS.)
Christopher Swasey is quite correct.
I have set up a jsFiddle demo of his technique at http://ajh.us/test-inline-block.
The code is essentially:
var div = document.createElement('div');
div.style.cssText = 'display:inline-block';
// need to do this or else document.defaultView doesn't know about it
$('body').append(div);
// that was jQuery. It’s possible to do without, naturally
var results = false;
if (div.currentStyle) {
results = (div.currentStyle['display'] === 'inline-block');
} else if (window.getComputedStyle) {
results = document.defaultView.getComputedStyle(div,null).getPropertyValue('display')=== 'inline-block';
}
//clean up
$(div).remove();
alert('display: inline-block support: '+results);
Please note this exact same technique also works for detecting display: run-in support.
There is no way to detect that with Javascript as it is a pure CSS attribute that does not relate to any object or function in Javascript. The best thing I can tell you is to check here for a pretty good compatibility list and use CSS to create a workaround.