Designers wanted - post them here, sexiest wins (I am rather partial to a green unicorn riding a tickmark btw!)

Given a string passed to a JavaScript function:

background-image: -moz-linear-gradient(bottom, #F8F8F8, #FDFDFD) !important;

...can a function return an object with all supported gradient CSS values.

Note that if a linear gradient is passed, linear gradients should return, as with radial and non-specific.

Code must also come with tests.

Problem

The proposed URL for checking websites, (http://cssprefix.com/[URI]) doesn't work with local web pages, either with a local webserver or plain file://.

This means that the developer needs to:

1. Publish the website with incomplete CSS prefixes.
2. Run the website through CSS Prefix.
3. Download the updated code.
4. Update their CSS.
5. Re-publish the website.

This is a sub-optimal workflow. If CSS Prefix supports local web pages, the first deploy of the website could already have all the needed CSS prefixes.

Possible solution

I believe there are three ways to do this:

1. Pasting the code to CSS Prefix
2. Uploading the code to CSS Prefix (drag & drop would be nice)
3. Developing browser extensions.

Browser extensions are able to do cross-domain requests, but I'm not sure if they can make requests from file:// websites.

Use the service to determine the status of the currently viewed page and display the appropriate [traffic light] icon in the address bar.

Don't kill me! I know I'm asking for a vendor-specific implemented feature that determines whether there are vendor specific features in the page's style sheet, but I still see value in this.

Using the green/red idea for the pass or fail, make a request to

"http://cssprefix.com/check.json?url=" + window.location

And the JSON returned contains:

{ pass: true }

(or false) - which will drive the icon.

Can this be done for all browsers?

I think a job should be shot off to something like rabbitMQ (which I have no experience in doing) and picked up by the prefix.js process. Once done, kickback to the main server and it would give links to the completed job.

Currently the forked child is nuking the server!

TL;DR - please have a look at my zeromq setup - it's wrong and needs fixing - help me Obi-Wan....

I'm using zeromq to post off the job of parsing all the CSS in a url, and then once it's complete, it passes the message back to the the main app.js node process.

Ideally, lots of requests could come in, and I could be running 2-4 worker processes (node prefix.js) and requests would queue up, get processed, and returned to the correct waiting http client.

My problem (aside from having never used zeromq or any queuing system for that matter) is that the job is passed off to the worker, but because (I think) I have an odd one-to-one queue set up, the same job gets returned to all of the clients.

It's tricky to replicate, because you need concurrent request - but here's an example:

curl "http://cssprefix.com/check.json?http://remysharp.com"; \
curl "http://cssprefix.com/check.json?http://jsconsole.com"; \
curl "http://cssprefix.com/check.json?http://remote-tilt.com"

{"pass":true}
{"pass":false,"lint":{"type":"warning","line":834,"col":3,"message":"The property -ms-transition is compatible with -webkit-transition, -moz-transition, -o-transition and should be included as well.","evidence":"  -webkit-transition: opacity 200ms;\r","rule":{"id":"compatible-vendor-prefixes","name":"Require compatible vendor prefixes","desc":"Include all compatible vendor prefixes to reach a wider range of users.","browsers":"All"}}}
{"pass":false,"lint":{"type":"warning","line":834,"col":3,"message":"The property -ms-transition is compatible with -webkit-transition, -moz-transition, -o-transition and should be included as well.","evidence":"  -webkit-transition: opacity 200ms;\r","rule":{"id":"compatible-vendor-prefixes","name":"Require compatible vendor prefixes","desc":"Include all compatible vendor prefixes to reach a wider range of users.","browsers":"All"}}}

Note that the last two return checks are exactly the same, even though the CSS is different for all three sites - which says to me that the worker returned to two clients - hence the screw up.

I'd love for someone with experience to dive in an have a decent crack at getting the parent / worker set up correct - then we'll have a web service that doesn't blow up my machine when concurrent requests come in!

I'm sorry, I'm just trolling. But this is a neat idea to have in a checklist!

I'd rather be using (and did try) to use cluster to fork the process against each CPU and have the web service fire off jobs to the workers.

Currently I'm doing a fork on every request, and the net result is cpu spike and process top out.

I'd happily take a refactor of the app.js code.

Similar to an HTML validator tool, though initially only supports url entry:

• header
• strap line information (I'll comment on what this will be later - probably: compatible vendor-prefixes in one click - or some such marketing crap)
• form - enter the url to check and get back whether it's good or bad, and the updated CSS files to download
• submitted form view should include the form (from line above), and above the form the status of the check: clear RED / GREEN for bad or ok. If bad, a download link to save the updated CSS
• project information, how you can help, API access, extensions
• footer / credits