Require: converter for gradients about cssprefix HOT 8 OPEN

Does this need to include an SVG response, or as it is not prefix specific as such is it outside the scope of this tool?

from cssprefix.

I think it's outside the scope.

from cssprefix.

What about the various different notations? Stuff like multiple gradients, gradients mixed with images, gradient notation in the background shorthand, etc? Or should we start with just this simple variation and expand from there?

from cssprefix.

I'd suggest starting simple. Get the structure of the library right, so you can pass in and get you get out.

Start from there and build upwards. Right now we have nothing - so something is better than that :)

from cssprefix.

Ok, well I have something which I can add as a starter tonight, hopefully then others can make it more efficient or add to it if I'm slow.

from cssprefix.

I've just committed the very first version of a parser in my own fork. It only works so far for lines like the one above, without the "!important". I'll continue working on it.

Do we also need to add the old webkit syntax? That might prove to be a bit of a challenge :)

from cssprefix.

I don't know how you've been getting on with this chevalric, but I've got a version that I'm going to fork off of yours later.

It doesn't convert from webkit-gradient to modern versions yet, and it doesn't attempt to do any conversion to -webkit-gradient for radial, and has very limited scope for converting to use "filter" for IE6-8 with linear gradients as well as not attempting to convert for filters for radial gradients. Without a DOM to interact with it would be, to my mind, impossible to create an appropriate -webkit-gradient rule for radial gradients in all but the most basic version of it.

filters are being included for completeness, though it'd be down to the user to ensure that they modify it in a way that didn't interfere with IE9-10's -ms- prefix.

Ultimately, if this tool is purely to prefix up CSS code, then it won't be able to do so in completeness nor exactness on this front, and we should accept that rather than hand over CSS code in return that would significantly differ the viewing experience across browsers, potentially to the detriment of the users design.

Extra tools could fairly easily be created to automatically create exacting SVG and/or -webkit-gradient fall backs for older browsers for inclusion on their website at runtime, or to be run on their website once if they are sure their design will not have it's elements housing radial gradients change size; but then that should be a JQuery plugin, or something similar, I feel. On the SVG front it'd be a better recommendation to point people at things like CSSPie that actually already do this job!

from cssprefix.

Better late than never, the files/code is up on a fork of remy's cssprefix (not Chevalric as said before)

from cssprefix.