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?

[kizu]

I'm a bit overwhelmed with my current work, I hope I'll complete this in a week or so.

[Grawl]

good

[kizu]

Working on it, however, I stopped at the conversion between new and old gradient syntaxes, I think I'll redo most of the hacks needed to the gradient on the plain js via the plugin, so I could use the proper tools for that. The Stylus' pseudo-language don't allow me to do most of the things I want.

[Grawl]

awesome, Kizu. who's a master? Kizu is a master!

[KrisHedges]

Hi I've recently released a stylus framework that takes a lot of inspiration from nib and a fair bit of code, as well. Initially I planned to use nib for CSS3 mixins, but decided to try my hand at writing my own. I tried to focus on the mixins being as simple and transparent as possible. the linear and radial gradients accept the new css3 syntax. example linear "to" keyword. radial "at" keyword. There are still some issues as far as implementation. For instance support for radial sizes in pixels seems to be absent from firefox? or maybe I'm just doing it all wrong. I'm not an expert in the language stylus so my code could likely be refactored by someone who knows better. but it basically demonstrates the approach I'd like to see with mixins for CSS3. Maybe there's something relevant for you guys in it? I'd love some feedback.

http://github.com/InkSpeck/fluidity
http://fluiditycss.com

[flying-sheep]

will it be possible to use multiple gradients in one background-image directive?

what i mean is when i use the following code ATM,

@import 'nib'

body
  background-image \
    linear-gradient(rgba(red, .1), rgba(blue, .1)), \
    radial-gradient(black, white)

i get

body {
  background-image: -webkit-gradient(linear, left top, left bottom, color-stop(0, rgba(255,0,0,0.1)), color-stop(1, rgba(0,0,255,0.1))), radial-gradient(#000, #fff);
  background-image: -webkit-linear-gradient(top, rgba(255,0,0,0.1) 0%, rgba(0,0,255,0.1) 100%), radial-gradient(#000, #fff);
  background-image: -moz-linear-gradient(top, rgba(255,0,0,0.1) 0%, rgba(0,0,255,0.1) 100%), radial-gradient(#000, #fff);
  background-image: -o-linear-gradient(top, rgba(255,0,0,0.1) 0%, rgba(0,0,255,0.1) 100%), radial-gradient(#000, #fff);
  background-image: -ms-linear-gradient(top, rgba(255,0,0,0.1) 0%, rgba(0,0,255,0.1) 100%), radial-gradient(#000, #fff);
  background-image: linear-gradient(top, rgba(255,0,0,0.1) 0%, rgba(0,0,255,0.1) 100%), radial-gradient(#000, #fff);
}

i.e. only the first background is vendorized.

---

PS: can we get parens to work like in python? so that we can simply do that instead of escaping newlines

background-image (
  linear-gradient(rgba(red, .1), rgba(blue, .1)),
  radial-gradient(black, white)
)

[kizu]

@flying-sheep using multiple images is already possible in my branch, and it's almost complete, so I'll send a PR on this week or on the next one.

[jescalan]

Any word on the status of this? Big fan of the initiative : )

[kizu]

The only thing left is to make the ie canvas fallback to work where possible, I jut can't find some spare hours for it. But I hope I'll do it on this or next week.

[jescalan]

Awesome. I'm generally not a fan of the whole canvas implementation anyway just because it's easy enough to use css3 pie when you need it. Has anyone else tinkered with this? It works extremely well in IE (in production on a few large projects for my employer) and is very easy to implement.

PS You are awesome for doing this. I'd love to help out too, and hopefully I will. I just feel like nib is undocumented and really losing steam, so I've been porting pieces of it over to a stylus css library I've been working on for a while.

[kizu]

Yeah, adding some pie could be a thing. And I'm too not a fan of all those canvas polyfills, but I just dont' want to break anything for someone who uses it.

However, I still that all the canvas functionality should be moved to another repo, 'cause it's not that everyone would use anyway.

[enyo]

Just wanted to say that I'm really looking forward to that update as well! Hope you'll find the time soon.

[domyen]

Thanks for your efforts on the gradient front Kizu! (specifically radial-gradient -yes, people actually use them)

[jescalan]

For anyone that's remotely interested, I've been putting a lot of work into this stylus library - I ported over the core gradient syntax (without the canvas piece) and it's stable and available as a stylus plugin like nib: https://github.com/jenius/roots-css

I'm very actively working on this project and will continue to do so.

[domenic]

Any progress on this?

[jescalan]

@domenic roots-css was released a few weeks ago and is stable. it's being used in roots, and documentation for the gradients piece can be found here. All linear gradients are supported (no canvas implementation, uses pie for IE fallback), haven't yet implemented radial because of lack of demand and support.

[domenic]

I am not interested in another plugin; I am interested in nib.

[jescalan]

Nib is not being actively worked on. This issue was opened 8 months ago.

[kizu]

Yeah, right now we use my branch in production, but there are still few issues with it that pervent the merging to the nib's upstream (mostly backwards compatibility ones). I still don't have time to fix them.

The main problem is that the new way to render gradients is by using plugin in js that need to be somehow included. While there is no way to include plugins right from .styl files, then moving to my branch would mean broken gradients for those who just @import nib, without all the js stuff.

So, to fix it we should use the old gradients if the nib is simply included and use the new gradients if we can use the functions from the plugin. The Stylus' syntax don't allow it to write the needed mixins in it, so it's possible only via the plugin.

[domenic]

The Stylus' syntax don't allow it to write the needed mixins in it, so it's possible only via the plugin.

Maybe this is true. Perhaps because you seem to be trying something pretty complicated in the OP. I just want my damn gradients to work in IE10 and new versions of Firefox, so my goal is to change the last line from "top" to "to bottom" etc. Looking at all the complicated things already done in gradients.styl, this seems likely possible.

I guess I'll spend some time today trying to do this, and maybe that will get merged in, even if this ambitious project cannot be completed due to lack of time and technical issues.

[tregusti]

I would really love to see this issue closed with al the hard work you've done @kizu!
As I see it with backwards compatibility, raise nib to 1.0 and it's allowed to break some things. Gradients are only becoming more and more used, so we need a proper implementation.

[Pickachu]

👍

[igor10k]

Is there at least slightest chance that these changes will be implemented in the original Nib?

[notslang]

according to https://developer.mozilla.org/en-US/docs/Web/CSS/linear-gradient

WebKit since 528 supports the legacy -webkit-gradient(linear,…) function. As of WebKit 534.16, it also supports the standard gradient syntax.

and according to http://www.quirksmode.org/webkit.html & http://www.chromium.org/developers/webkit-version-table & https://en.wikipedia.org/wiki/Google_Chrome#Release_history - webkit 528 was first added at chrome 1.0.154 and webkit 534.16 was added at chrome 10.0.648

With data from statcounter, I calculate that the total usage for chrome 1-10 is 0.45%, which seems about right.

That means that removing the legacy webkit gradient would only affect about 0.45% of users, which doesn't seem that bad... they'd just see the same fallbacks that other old browsers get. Therefore, I support removing the legacy webkit gradient syntax.

PS: if anyone else can verify this against a larger dataset than just chrome, that'd be great. I doubt that adding in stats from Safari and the mobile browsers that use webkit would change much, but it's always better to have more data.

[jescalan]

+1 @slang800

[notslang]

This has been rebased on top of #192 and will be mergable once the 1 test that is still failing is fixed.

[KrisHedges]

Whoa. Huge! Nice work @kizu I'll check this out soon.