Develop Reference

How do I know when to abandon vendor specific prefixes? [duplicate]

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.

Alternative to CurvyCorners

Is there an alternative script to CurvyCorners that does border-radii based on CSS? CurveryCorners has so many bugs and rarely works the way it's expected to, it's just not worth using anymore.
Thanks.

The alternative is to use the CSS3 border-radius style.
This works out-of-the-box in all current browsers, except IE8 and earlier. For browsers other than IE, you shouldn't be running any kind of script at all for this, as it's a standard built-in feature in the browser.
For IE8 and earlier, there is a hack called CSS3Pie which allows IE to also support the standard CSS3 border-radius style. This is Javascript based, but works with the standard CSS code, meaning you can use the same style for all browsers.
As an added bonus, CSS3Pie also implements CSS3 box shadows and gradients for IE as well. And it's under active development, and the author is great at helping people out on the forum if they're having problems with it.

In the past i've used Diller Design's Roundies which has always worked pretty well for me.
It uses VML to create the rounded edges.
UNfortunatley i don't think the author is updating it any more.

<marquee> html tag usage/replacment

I know that <marquee> tags are evil.
If it is so bad to have scrolling text, then using JS to get the same effect doesn't make it any better, right?
And suppose I decided to have some scrolling text (gasp), is there some type of CSS(3?) or HTML(5?) way to do this that is technically correct (i.e. not deprecated)?
If there isn't a CSS/HTML solution, should I use:
Javascript, which will be heavier to download and might be turned off (is that a pro or a con?), but I get the bonus of being W3C correct and valid and non-deprecated and smart,
or should I use
the hated <marquee> (<blink><blink>) tag, which is lightweight (19 bytes!), fully supported by all browsers in all rendering modes and all doctypes (even though it shouldn't be), but is deprecated?
Thanks.
P.S. I think a news ticker is a valid use for marquee-style
P.P.S. If anybody tells me that if I don't want a heavy Javascript solution I should use JQuery because it is lightweight, I will shoot them in the comments
Edit: I'm adding JQuery tag since that seems to be the best way to get attention from a lot of experts on JS questions, and it is not totally unrelated here.

It is not the effect that is bad. The problem with marquee, blink and font tags is that they convey presentation not structure of your content.

CSS3 has support for marquee, but it is only supported in a few browsers (Safari and Chrome are the only one, to my knowledge)
http://www.w3.org/TR/css3-marquee/
There are several JQuery plugins that accomplish it, but they come at the expense of loading JQuery (26Kb, heavier than the HTML only solution, but not what I would call heavy)
http://plugins.jquery.com/plugin-tags/marquee
Of course you can easily do it yourself without JQuery, but looking at those plugins may give you ideas.
Another option to consider is to do a small Flash animation.

If you're sure that it works on all platforms you're aiming for, and you don't care what w3c says you can certainly use the marquee tag. There is no way that you can find a JavaScript solution that works in less than 14 bytes.
The only unfortunate thing is that the reason all these browsers support all these deprecated elements that are -in this case- not even part of any HTML standard, is because of all these people using these elements and start whining when a new version doesn't support their 1982 compliant website anymore.
So please go ahead and use marquee as long as it works for you, but please don't complain if you site stops working in a newer browser.

Here's the code that implements the marquee element in Firefox, it's basically doing it in JavaScript anyway so you could always just adapt that code and use it directly in all browsers.
The code can be hacked around so that marquee can be implemented on any element in Firefox, applied through CSS and XBL bindings (Firefox only example). The equivalent in IE would be behaviours, and you could use the CSS3 in Safari/Chrome as nico suggested and you would be keeping the presentational stuff out of your markup, but only you can know if it's worth the effort.

I've been looking for the most efficient and cross-browser supported marquee implementation. For whatever reason, even the webkit CSS marquee implementation is glitchy.
The common approach is to use timer (or jQuery animate implementation) to adjust the CSS margin property of the element. This is too glitchy and very inefficient. I came up with implementation that utilises CSS3 transitions for browsers that support it and otherwise animate the scrollLeft property of the containing element. It is an experimental implementation, though it works well with IE7+. Other people might find it useful as well, https://github.com/gajus/marquee (demo https://dev.anuary.com/60244f3a-b8b2-5678-bce5-f7e8742f0c69/).

Recently, i had to do this effect for a client and i've used this plugin which is very easy to use :
jQuery Marquee plugin on github
jQuery Marquee on plugins.jquery.com

Actual IE6 Png fix

What png fix method is the most actual today? Lite-weight, with background-repeat and background-position support.

IE7.JS in my view:
IE7.js is a JavaScript library to make
Microsoft Internet Explorer behave
like a standards-compliant browser. It
fixes many HTML and CaSS issues and
makes transparent PNG work correctly
under IE5 and IE6.

Create PNG's with Fireworks and encode them as PNG8 instead of PNG32.
See: http://www.sitepoint.com/blogs/2007/09/18/png8-the-clear-winner/
No need for js, no need for css filter.
Unless you need more then 256 colours, then you are stuck with filter/js fixes.

I believe that the DD_BelatedPNG method is superior to the filter method used by ie7.js.
You can use PNGs as the SRC of an
element or as a
background-image property in CSS.
If you attempt the latter, you will
find that, unlike with vanilla usage
of AlphaImageLoader,
background-position and
background-repeat work as intended.
As a bonus, "fixed" elements will
respond to a commonly used set of
Javascript style assignments, as well
as the A:hover pseudo-class.

Detect Browser Support for display:inline-block

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.