recommend not using css3please #104

Open
paulirish opened this Issue Aug 4, 2012 · 16 comments

Comments

Projects
None yet
6 participants
Owner

paulirish commented Aug 4, 2012

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?

Owner

paulirish commented Aug 4, 2012

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

Collaborator

uxder commented Aug 4, 2012

+1

Collaborator

mathiasbynens commented Aug 4, 2012

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”).

Collaborator

jonathantneal commented Aug 6, 2012

@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.

Owner

paulirish commented Aug 7, 2012

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.

Contributor

chrsr commented Nov 16, 2012

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?

Owner

paulirish commented Nov 16, 2012

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.

Contributor

chrsr commented Dec 7, 2012

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 :)

Owner

paulirish commented Dec 7, 2012

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.

@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?

Owner

paulirish commented Feb 21, 2013

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.

Thanks.

The information needs work, for sure. Adding browser info (next to prefixed lines a la CSS3 Please) is on my list: davidhund/shouldiprefix#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 added a commit that referenced this issue Apr 15, 2014

Owner

paulirish commented Apr 15, 2014

Just added this to the site:

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

image

PR's welcome for changes.

Collaborator

jonathantneal commented Apr 15, 2014

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

Owner

paulirish commented Apr 15, 2014

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

@paulirish paulirish closed this Apr 15, 2014

@paulirish paulirish reopened this Apr 15, 2014

Collaborator

jonathantneal commented Apr 15, 2014

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

Maybe we/I can write a followup.

@paulirish paulirish referenced this issue in davidhund/shouldiprefix Jan 7, 2015

Closed

Remove link to css3please #28

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment