recommend not using css3please

[paulirish]

css3 mixin libraries are stable and a better way of doing things when building a decent sized site/app.

I'd like to be suggesting people investigate compass (sass) and nib (stylus) as an alternative to the copypaste rigmarole of using css3please.

thoughts?

[paulirish]

this would probably manifest as some text and links at the top of the page for now. later on it could be more aggressive.

[uxder]

+1

[mathiasbynens]

A recommendation at the top couldn’t hurt. However, I like to use CSS3 Please as a reference, as it neatly lists the required prefixes at any time and the browsers they’re needed for.

So, +1 to adding a recommendation, but -1 on removing the current functionality / abandoning this project (if that’s what you meant by “become more aggressive”).

[jonathantneal]

@paulirish I think I'm 100% with you. Something at the top suggesting a superior alternative, and later on considering something more aggressive along the lines of dropping Safari 3-4 support / etc. Basically, I long for the day the gradients can be consolidated.

[paulirish]

I like to use CSS3 Please as a reference, as it neatly lists the required prefixes at any time and the browsers they’re needed for.

Me too. I think we can appropriately communicate this. Good call.

[chrsr]

For the last year or so I've used css3please extensively as a goto reference for vendor prefix support. To see the project abandoned would be a shame however I agree that moving to a well maintained mix-in library is where it's at.

I've begun on a project to create a similar css3please like reference (all the css3please things) for LESS.js that is essentially just a bunch of mix-ins outlining vendor prefix support for css3 features.

The aim is to have both a LESS mix-in plus the generated CSS side-by-side so a user can copy/paste from either. Eventually the same would be created for other css preprocessors, less, stylus etc etc.

The beauty of css3please is it documents current vendor prefix states is a really easy to read, demo and copy way, it would be a shame to loose this to a library where prefix support could potentially be hard to find amongst all the other preprocessor library benefits.

What's your thoughts on whether or not a separate "preprocessor vendor prefix mix-in reference" would be useful?

[paulirish]

I agree the vendor prefix status is a great reference. Maybe it can evolve to be a reference of that information and a spec that could be used for mixin libraries. Like to know that Compass generates all the right vendor prefixes and no superfluous ones.

Actually superfluous ones isnt the problem. (gzip means no byte overhead) Only really differing syntax is the challenge. Hmm

On Fri, Nov 16, 2012 at 3:27 AM, Chris Roberts notifications@github.comwrote:

For the last year or so I've used css3please extensively as a goto reference for vendor prefix support. To see the project abandoned would be a shame however I agree that moving to a well maintained mix-in library is where it's at.

I've begun on a project to create a similar css3please like reference (all the css3please things) for LESS.js that is essentially just a bunch of mix-ins outlining vendor prefix support for css3 features.

The aim is to have both a LESS mix-in plus the generated CSS side-by-side so a user can copy/paste from either. Eventually the same would be created for other css preprocessors, less, stylus etc etc.

The beauty of css3please is it documents current vendor prefix states is a really easy to read, demo and copy way, it would be a shame to loose this to a library where prefix support could potentially be hard to find amongst all the other preprocessor library benefits.

What's your thoughts on whether or not a separate "preprocessor vendor prefix mix-in reference" would be useful?

— Reply to this email directly or view it on GitHubhttps://github.com/paulirish/css3please/issues/104#issuecomment-10435526.

[chrsr]

Finally got around to to creating a basic demo of what I think would be a nice direction for css3please to take. Reiterating my comments above suggesting css3please becomes both a mix-in library and a css3 vendor prefix reference.

My demo uses LESS.js (cause I can do it in the browser), but there is no reason it couldn't be replicated using SASS or Stylus etc.

live demo: http://chrsr.com/css3lessplease/ source: https://github.com/chrsr/css3lessplease

Only tested in Chrome at this stage :)

[paulirish]

that's pretty cool.

On Thu, Dec 6, 2012 at 10:19 PM, Chris Roberts notifications@github.comwrote:

Finally got around to to creating a basic demo of what I think would be a nice direction for css3please to take. Reiterating my comments above suggesting css3please becomes both a mix-in library and a css3 vendor prefix reference.

My demo uses LESS.js (cause I can do it in the browser), but there is no reason it couldn't be replicated using SASS or Stylus etc.

live demo: http://chrsr.com/css3lessplease/ source: https://github.com/chrsr/css3lessplease

Only tested in Chrome at this stage :)

— Reply to this email directly or view it on GitHubhttps://github.com/paulirish/css3please/issues/104#issuecomment-11120199.

[davidhund]

@paulirish et. al.

Recently (esp. after the Opera WebKit adoption) I was looking for a simple reference of vendor prefix status and could not find it. To be honest I never really looked into CSS3 Please as I assumed it took the 'crossbrowser route' (chuck all prefixes in for ultimate coverage).

This is why I just created http://shouldiprefix.com/ — My aim is to provide a simple(!) overview of newer CSS features and currently needed prefixes. I deliberately do not include 'cross browser' rules (IE fallbacks, etc) because I think a simple overview of the 'current state of prefixes' could be of some value.

Many preprocessor mixin libraries, I believe, are outdated and offer superfluous prefixes. This is not a big deal — really — but it might be good to have a 'clean' reference somewhere?

I love CSS3 Please and have used it often as a reference for crossbrowser CSS3. In no way do I aim shouldiprefix.com to 'compete' with it. What do you think?

[paulirish]

cool site!

i think it lacks a bit of granularity that is still needed. what mobile browsers and desktop browsers need each prefix?

for example plenty of people now dont support android 2.x, which means -webkit-box-sizing is unncessary.

i think the browser support for each line should be called out a bit more expliticly. or provide the user a way to specify what their own browser support needs are. everyone has different audiences.

On Thu, Feb 21, 2013 at 1:16 PM, David Hund notifications@github.comwrote:

@paulirish https://github.com/paulirish et. al.

Recently (esp. after the Opera WebKit adoption) I was looking for a simple reference of vendor prefix status and could not find it. To be honest I never really looked into CSS3 Please as I assumed it took the 'crossbrowser route' (chuck all prefixes in for ultimate coverage).

This is why I just created http://shouldiprefix.com/ — My aim is to provide a simple(!) overview of newer CSS features and currently needed prefixes. I deliberately do not include 'cross browser' rules (IE fallbacks, etc) because I think a simple overview of the 'current state of prefixes' could be of some value.

Many preprocessor mixin libraries, I believe, are outdated and offer superfluous prefixes. This is not a big deal — really — but it might be good to have a 'clean' reference somewhere?

I love CSS3 Please and have used it often as a reference for crossbrowser CSS3. In no way do I aim shouldiprefix.com to 'compete' with it. What do you think?

— Reply to this email directly or view it on GitHubhttps://github.com/paulirish/css3please/issues/104#issuecomment-13887987.

[davidhund]

Thanks.

The information needs work, for sure. Adding browser info (next to prefixed lines a la CSS3 Please) is on my list: https://github.com/davidhund/shouldiprefix/issues/8

I want to avoid, however, adding back too many older prefixes — even though for some people they might be needed (see my disclaimer).

Like you I'd like to take a progressive approach. This is easier for http://shouldiprefix.com than for http://css3please.com since my goal is not to provide people cross-browser copy-paste-able code.

I'll add some browser info next to the rules, soon. Thanks

[paulirish]

Just added this to the site:

Update: We recommend using <a href="http://css-tricks.com/autoprefixer/">Autoprefixer</a> instead of CSS3Please.

PR's welcome for changes.

[jonathantneal]

Could I update to the project directly? Or did you prefer Chris’ blog? https://github.com/ai/autoprefixer

[paulirish]

the blog post seemed like a better onboarding experience. though i wish both the blog post and the github readme called out the Sublime extensions a little more directly. ah well

[jonathantneal]

Wow, I totally missed Sublime extensions! https://github.com/sindresorhus/sublime-autoprefixer

Maybe we/I can write a followup.