The state of the gradients in nib

[kizu]

Problem

There is a problem with gradients in nib now: there is a canvas polyfill for simple linear gradients and support for old webkit syntax.

While this is cool, it's cool until you want to do something more than just simple linear gradient.

Today you can do a lot of other things, like repeating gradients, radial ones, multiple images (look for example at the Lea Verou's pattern collection), and you can't use all those things with nib, 'cause, as I understand, you'll need to support the canvas and old webkit syntax as well, so you can't do just anything you want to gradients' mixin.

The nib's issues affected by this:

• linear-gradient and multiple background #14 could be fixed easily.
• Vendor-prefixed properties AND values #19 also would be easiy to work for border-image, -webkit-mask etc.
• linear-gradient() fails when passing degree #71 could be fixed.
• Added radial-gradient incl svg and canvas #12 — issues with such fallbacks must be done apart of the nib.
• Gradient helper prevents having a 'top()' mixin #56 there is a chance that it would be fixed.
• linear-gradient with variables #67 could be fixed easily.

The solution

1. Move the canvas generated gradients (and other fallbacks like pie or svg) to the mixins with different syntax from the current one, so the linear-gradient() one wouldn't generate them by default. Or move them to different repo at all.
2. Remove the support for the old webkit syntax — it's needed now only for some old androids — so who cares really? They're already in the Candidate Recomendation state and such legacy is a burden for nib.
3. Rewrite the mixins a bit, so it would fix all the current issues. It would be rather simple if you'd have no need in all this legacy stuff, that are there now.

I can try to fork nib and do all those things, but I want to know if it's needed there.

@visionmedia, what do you think?

[tj]

sounds reasonable. Personally I only use linear grads but I definitely don't want to render some functionality useless for those who do want it. We're missing support for degrees and I think the original position is optional, which I never noticed when I implemented it, or maybe it wasn't optional at the time

[kizu]

Ok, then I'll try to find time and get to the gradients, there are a lot of things to do with them.

[tj]

it's unfortunate that browsers put us in this situation, I really wish experimental stuff was implemented as if it was official, we would still have some of this maybe with varying implementations but it would be a lot better I would think

[superstructor]

It would be great to have fully functional gradient support =)

Re 1. and 3. Its nice to be able to write a single linear-gradient and have all the support you have configured automatically generated instead of having to repeat yourself three times.

Nearly all CSS3 gradients can also be implemented with canvas or SVG. Sure that support involves some code and added complexity. But I don't understand how that has any impact on making the specific issues you listed simpler to fix ? Most of those issues appear to be related to the use of current-property which is a problem regardless of the fall-back support ?

Feel free to re-write gradients and drop the SVG/canvas support for now. I'd be happy to re-add SVG and canvas support for linear/radial gradients based on the fixed mixins when this is merged unless there is some issue I can't see that makes that uber complicated. Maybe I'll need to see the diff to understand =)

I definitely think a long-term view of removing legacy/fall-back support altogether, or moving to it another repo, would be a step back for nib and put us far behind compass/SASS which currently does SVG and PIE.

Re 2. +1

[kizu]

Yeah, I won't have anything against the canvas etc. support for linear gradients as long as it won't break all other gradients :)

So it would be ok if there'd be an image fallback when it can be done and just CSS3 stuff otherwise.

[superstructor]

Sure its would be great just to have pure CSS3 support working well first so your plan sounds good.

Then after everything is fixed and merged just for pure CSS3 can have a look at the feasibility of re-implementing more comprehensive canvas or SVG support based on the re-written mixins =) I believe it will be possible without too much troubles and will be better to do it with a more solid base as the current state of gradients is quite broken.

Cheers =)

[kizu]

Some progress: kizu/nib@kizu:vendor-properties-values...kizu:new-gradients (based on my pull-request #95 — it have the code that also helps in this issue a lot).

It already fixes some issues (multiple gradients, angles), however there are still work to do:

• While you can now apply gradients to variables (like in linear-gradient with variables #67), they are not expanded (except for the border-image lol), so I must make sure it works with variables and properties like: background, background-image, cursor and list-style-image.
• There are no radial and repeating gradients now. I'll try to add them later, when all the vendor magic would be stable.
• Tests! There are no new ones, I'll add them later too.

Maybe there is something else I forgot, I'll find out this when I'll get to the tests.

[kizu]

Current state: moved the logic for the gradients from the linear-gradient() function to the vendor ones, creating such for background, background-image etc.

So, this fixes almost all of the problems, so you could set the gradients to the variables, use them in any context that can have the backgrounds etc.

What must be done still:

• Tests!
• Look into the normalizing of the stops (btw, what do this function does?).
• Hack the differences between the final syntax and the legacy ones (like top becomes to bottom etc.)
• Radial and repeatings gradients.

[Charuru]

Looking forward to this!

[Grawl]

When it will be done?