I have seen in the comments of Is quoting the value of url() really necessary? and CSS background-image - What is the correct usage? that Mac IE 5 does not support quotation marks inside the url() function.
Also PPK's CSS page does not mention the url() function at all:
http://www.quirksmode.org/css/contents.html
So I would like to know what browser support is like for this function. What browsers recognise the value, which ones require what quotation marks, whitespace, and so on.
I realise that everything released in the past five years probably support all syntaxes. It's the older browsers I am thinking of.
Mac IE5? Serious? :) I think this browser is seriously outdated and not being used anymore :)
Anyhow, according to W3C, it's
body {background-image:url('paper.gif');}
And it works for all (older) browsers. For who are you developing if you need support for this kind of ancient browsers?
I have never ever had any issues with background-image for any browser type.
Unless of course you are putting it as a div with no content and not specifying the width and hight of the element...
example usage of background/background-image
#body {background-image:url('mylovelybg.jpg');}
or the long hand (to allow for color and repeating factors
#body {background:url ('mylovelybg.jpg') repeat-x #fff;}
Related
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've noticed that Safari and Chrome behave the same when it comes to HTML and CSS. However, there are differences between Firefox and Safari (and hence, Chrome as well).
Sometimes things can look great in Firefox, but the CSS misbehaves in Safari and Chrome. The cause of the mis-behaviour can be attributed to "anything" (as opposed to in IE 6 and 7, mis-behaviours are usually caused by excessive paddings/margins that cause elements to float out of position). For example, while debugging CSS of a website for Safari the following attributes have caused cross-browser misbehaviours:
position
height
width
padding
margin
Is there a common pattern to Chrome and Safari CSS debugging?
Can you guys offer insight into the differences between Safari and Firefox that may help me with my cross browser debugging?
Thanks
Typically, and anecdotally, the majority of large differences between cross-browser rendering of the same page are due to:
invalid (x)html, use the on-line html validator from the W3 to ensure the validity of the mark-up.
lack of establishing a base-line for CSS (as #Jeroen suggests: use a css reset).
use of CSS which varies in support from browser-to-browser, particularly the newer CSS 3 (transitions, column-count and box-reflect1 particularly, though there are many, many others).
This may, or may not be, a proposal for inclusion in CSS3 by the World Wide Web Consortium, the only references I've found for it are exclusively with the -webkit vendor prefix, which suggests that it's probably a proprietary extension. I can, however, hope that others will follow suit. It's so much easier to apply reflections with css than with js/php...
I have noticed differences, but not that dramatic. As usual, most differences can easily be overcome / avoided by using a css-reset. Do you use one on the pages you are talking about?
This css difference is because, there is a default styles difference for firefox and chrome browsers. click this links for default css sheets
http://hg.mozilla.org/mozilla-central/file/tip/layout/style/html.css
http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css
While developing the webpage itself we have to make sure of overriding this default styling commonly for both browsers. using the browser extensions like -webkit and -moz etc..
After development and in debugging state, we need to override this default styles. I don't think we have any common debugging for this. correct me if i am wrong.
Can you use the browser specific prefix in front of all standard tags?
e.g.
#div{
padding:20px;
-moz-padding-bottom:10px;
}
is the above valid CSS for ensuring Firefox has a different bottom padding to all other browsers?
No, it's not a prefix for targetting a browser, it's a prefix that is used for specific non-standard properties like -moz-opacity or -moz-padding-start. It's not available for the standard properties.
First, no, there isn't a prefix for things that are standardized, since they're the same property cross-browser (or should be, don't take this for granted in IE).
Instead of what you're after with this prefix, I'd instead look at a completely different approach...taking out the differences in rendering, instead of trying to fix them, at least as many as possible.
Take a look at a CSS reset stylesheet, to normalize the padding and such across browsers, then look at fixing any remaining quirks.
You can always do it, but the style will be ignored by browsers who don't understand it and the CSS won't pass CSS Validation.
This might be of interest.
-webkit-text-stroke
Works in Firefox browsers as well.
I'm trying to use the page-break-inside CSS directive, the class of which is to be attached to a div tag or a table tag (I think this may only work on block elements, in which case it would have to be the table).
I've tried all the tutorials that supposedly describe exactly how to do this, but nothing works. Is this an issue of browser support or has anyone actually gotten this working, the exact bit of CSS looks like this:
#media print {
.noPageBreak {
page-break-inside : avoid;
}
}
Safari 1.3 and later (don't know about 4) do not support page-break-inside (try it, or see here: http://reference.sitepoint.com/css/page-break-inside). Neither do Firefox 3 or IE7 (don't know about 8).
In a practical sense, support for this attribute is SO spotty, it doesn't make sense to use it at all at this point. You'd be lucky if even 10% of your visitors have browsers that can support this.
The solution I used was to add
page-break-after:always
to certain divs, or add a "page-breaker" div in where you want breaks. This is quite ham-handed, I know, because it doesn't do quite what you want, and causes content to not reach the bottom of the printed page, but unfortunately there isn't a better solution (prove me wrong!).
Another approach is to create a stylesheet that removes all extraneous elements (display:none) and causes the main content to flow in one main column. Basically, turn it into a single column, text-only document.
Finally, avoid floats and columns when styling for printers, it can make IE (and FF) act wacky.
Safari 1.3+, Opera 9.2+, Konquerer, and IE8 all support it, at least to some degree.
Firefox apparently still does not.
Firefox does not support this as of 2010-11-30, and thus won't in Firefox 4.
IE8 does support page-break-inside: avoid - but when I tried this on IE9, it's not very successful at avoiding page-breaks (this may be a regression, or perhaps IE8 is also only capable of avoiding page breaks in very simple cases).
AFAIK it doesn't work in any webkit browser; certainly not in chrome.
It actually works in Opera, even on real sites.
Safari 1.3 and later support page-break-inside.
So does Konqueror.
I'm trying to use the page-break-inside CSS directive, the class of which is to be attached to a div tag or a table tag (I think this may only work on block elements, in which case it would have to be the table).
Firstly, there's no need to guess. Just look at the specification, and you'll see that it does indeed only apply to block-level elements.
Secondly, <div> elements are usually block-level elements, so there's no problem applying page-break-inside to a <div> element.
Finally, you don't need to wrap it in #media. You only need #media if you want to apply media-independent rules to only one medium, for instance, if you want to use display: block only for one medium. In this case, you don't need to hide those rules from other media, because they'll only apply to paged media anyway.
From preliminary searches, it's hard to find up-to-date statistics on browser support for this, but it seems that Firefox 4beta6 supports it and Chrome 7 does not. Chrome also breaks pages halfway through a line of text, so that part of the text appears on one page and part appears on the next. Uncharacteristic lack of attention to detail, but I guess neither Google nor Apple care about printing things.
Firefox 4 also adds some nice headers and footers to your prints with url, page title, site title, number of pages, and time. Nice.
As a bit more information further to Eamon Nerbonne's answer on the IE rendering (IE8+), you need to make sure the browser is in standards mode. This article on MSDN shows what is necessary - including a meta tag in your html to force the issue:
<meta http-equiv="X-UA-Compatible" content="IE=8" />
Feels kludgy, but there you have it... seems to work more consistently.
I'm wondering if there's any way to write CSS specifically for Safari using only CSS. I know there has to be something out there, but I haven't found it yet.
I think the question is valid. I agree with the other responses, but it doesn't mean it's a terrible question. I've only ever had to use a Safari CSS hack once as a temporary solution and later got rid of it. I agree that you shouldn't have to target just Safari, but no harm in knowing how to do it.
FYI, this hack only targets Safari 3, and also targets Opera 9.
#media screen and (-webkit-min-device-pixel-ratio:0) {
/* Safari 3.0 and Opera 9 rules here */
}
There are some hacks you can use in the CSS to target only Safari, such as putting a hash/pound (#) after the semi-colon, which causes Safari to ignore it. For example
.blah { color: #fff; }
.blah { color: #000;# }
In Safari the colour will be white, in everything else it will be black.
However, you shouldn't use hacks, as it could cause problems with browsers in the future, and it may have undesired effects in older browsers. The safest way is to either use a server side language (such as PHP) which detects the browser and then serves up a different CSS file depending upon the browser the user is using, or you can use JavaScript to do the same, and switch to a different CSS file.
The server-side language is the better option here, as not everyone has JavaScript enabled in their browser, which means they wouldn't see the correct style. Also JavaScript adds an overhead to the amount of information which needs to load before the page is properly displayed.
Safari uses WebKit, which is very good with rendering CSS. I've never come across anything which doesn't work in Safari, but does in other modern browsers (not counting IE, which has it's own issues all together). I would suggest making sure your CSS is standards compliant, as the issue may lie in the CSS, and not in Safari.
So wait, you want to write CSS for Safari using only CSS? I think you answered your own question. Webkit has really good CSS support. If you are looking for webkit only styles, try here.
You'd have to use JavaScript or your server to do user-agent sniffing in order to send CSS specifically to Safari/WebKit.
#media screen and (-webkit-min-device-pixel-ratio:0) {}
This seems to target webkit(including Chrome)... or is this truly Safari-only?
This really depends on what you are trying to do. Are you trying to do something special just in safari using some of the CSS3 features included or are you trying to make a site cross browser compliant?
If you are trying to make a site cross browser compliant I'd recommend writing the site to look good in safari/firefox/opera using correct CSS and then making changes for IE using conditional CSS includes in IE. This should (hopefully) give you compatibility for the future of browsers, which are getting better at following the CSS rules, and provide cross browser compatibility. This is an example.
By using conditional stylesheets you can avoid hacks all together and target browsers.
If you are looking to do something special in safari check out this.