1. use only smooth gradients for your background (LOL)
2. remove most of your pixels
3. assume that the browser will interpolate for you (Also LOL)
If this had been called "pictures of smooth gradients don't need to be high res if your viewer interpolates them sufficiently well" then it would be accurate and sound a lot less noobish.
I agree, but your comment would have been much better without the "LOL".
about 3: most browsers have a good interpolation method for smooth images. It's a safe assumption if you have time to read all the documentation and you drop the support for IE6. (Perhaps IE6 can also interpolate correctly. I don't know and I'm not going to try to find the docs. IIRC I once had problems with the autostretching of the background image in IE6.)
Are you familiar with any web browsers that would not do a "sufficiently well" job of interpolating? I wouldn't expect a browser to use anything less than bilinear, which is fine for the use case presented. The author freely admitted that the technique isn't universal for all images.
- Simple horizontal, vertical, or radial gradients can rarely capture the "organic" look that most designers want (the gradients of real materials and scenes are highly uneven so perfect symmetry has a distinctly artificial appearance).
- I'm not sure if it's actually an aspect of the spec, but all implementations I've seen interpolate the colors in RGB or an RGB-like colorspace. This can have the effect of creating dramatic jumps or ridges. With a lot of trial and error (or color math) you can overcome this by using custom stop values, but it's much simpler and more in-line with a designer's toolset to be using colorspaces whose linear interpolations are more perceptually uniform.
Of course there's also the "standard drawback" of modern webdev too: it's often easier to just throw assets at the problem. :/
That is part of the spec. CSS colour 4 allows colours to be defined in using different colourspaces, but the gradient spec continues to dictate linear interpolation of the RGB values.
Eh, I'm not fussed about that. The example images used are smooth but still rather complex. It would be hard for your average bear to codify them programatically.
Usually they would be. I’m sure there is a rare exception for why you would want to create it as a raster image, but for the usual cases I run across CSS is far more flexible.
Embedded gradient images for use in emails for clients without CSS gradient support, possibly.
In this specific case I can see why layered CSS gradients would be non-trivial to assemble, but it’s a trade off.
Comments
No, the "technique" is to
1. use only smooth gradients for your background (LOL)
2. remove most of your pixels
3. assume that the browser will interpolate for you (Also LOL)
If this had been called "pictures of smooth gradients don't need to be high res if your viewer interpolates them sufficiently well" then it would be accurate and sound a lot less noobish.
I agree, but your comment would have been much better without the "LOL".
about 3: most browsers have a good interpolation method for smooth images. It's a safe assumption if you have time to read all the documentation and you drop the support for IE6. (Perhaps IE6 can also interpolate correctly. I don't know and I'm not going to try to find the docs. IIRC I once had problems with the autostretching of the background image in IE6.)
Are you familiar with any web browsers that would not do a "sufficiently well" job of interpolating? I wouldn't expect a browser to use anything less than bilinear, which is fine for the use case presented. The author freely admitted that the technique isn't universal for all images.
I'm no web design expert, but I'm surprised gradients such as that aren't defined via CSS or some other programmatic means.
CSS definitely supports gradients in theory but perhaps the way they work is not to the liking of designers / their audience / their clients
https://www.w3schools.com/css/css3_gradients.asp
CSS gradients have 2 notable annoyances:
- Simple horizontal, vertical, or radial gradients can rarely capture the "organic" look that most designers want (the gradients of real materials and scenes are highly uneven so perfect symmetry has a distinctly artificial appearance).
- I'm not sure if it's actually an aspect of the spec, but all implementations I've seen interpolate the colors in RGB or an RGB-like colorspace. This can have the effect of creating dramatic jumps or ridges. With a lot of trial and error (or color math) you can overcome this by using custom stop values, but it's much simpler and more in-line with a designer's toolset to be using colorspaces whose linear interpolations are more perceptually uniform.
Of course there's also the "standard drawback" of modern webdev too: it's often easier to just throw assets at the problem. :/
(Thoughts from a design-adjacent dev.)
That is part of the spec. CSS colour 4 allows colours to be defined in using different colourspaces, but the gradient spec continues to dictate linear interpolation of the RGB values.
Eh, I'm not fussed about that. The example images used are smooth but still rather complex. It would be hard for your average bear to codify them programatically.
Usually they would be. I’m sure there is a rare exception for why you would want to create it as a raster image, but for the usual cases I run across CSS is far more flexible.
Embedded gradient images for use in emails for clients without CSS gradient support, possibly.
In this specific case I can see why layered CSS gradients would be non-trivial to assemble, but it’s a trade off.
Example: https://stackoverflow.com/questions/14926189/creating-a-grad...
Yeah, agree -- I over-simplified it.