Significant update to SOURCE - 3 Oct 22

Stuart has just updated a point update to Source Addons adding a significant new feature not seen in Stacks before in addition to many other significant new stuff.

It is now possible to add CSS code directly into the Coder stack, so that actual code will be executed. This avoids the requirement to add that code into the Page or Site wide code area or into a second Coder, avoids creating a class name and then adding that class name to the CSS Class box.

What is different about this?

If you want to add a class or call up a class that has some code or access any of the Utility Classes, then you still do this by adding the class name into the CSS Class(es) box, just as before.

There is now a new CSS box to enter code directly, if you want.

So, for example, if you want to set the height of a Coder to be 300px , you would enter height:300px. To set the height and width to 300px, you would use height:300px; width:300px. Any valid code can be used here giving you access to essentially every feature there is.

This is not only a quicker way to build sites with smaller faster code, reduce the processing time for RW or Stacks App to read and process all of the settings in a stack, it is also a quick way to live preview the code you may want to add.

I will repeat that it is also a quick way to live preview the code you may want to add.

For 1 off layouts this additional new feature will not make a noticable performance difference, but for complex repetitive layouts such as blogs, product layouts, etc., this will increase performance and reduce page code complexity.

So we now have a web development tool with live code preview that also has access to existing modules such as normal stacks.

Indirectly, this has just introduced yet another way to build CSS Grid and Flexbox layouts using a Coder as the grid container.


thanks @webdeersign !

Yes - that is a useful new feature i think for where you want to apply stylings directly to the content of that particular Coder stack. If there are stylings that should be shared between multiple things then the old way would still be the best / most efficient way to do it. Also worth nothing that if you want any custom css applied at different breakpoints then this too would still need to be added via the regular RW CSS settings too.

Support for grid template areas was also added in this update. This provides an alternative / complementary approach to grid building and will better suit some grids / workflows. You can find out a bit more about that here.

Full release notes here.


Fantastic update, Stuart! Looking forward to exploring it when I’ve finished this stack. Grid Template Areas is really interesting to me — I’m excited to see what it will be possible to do with that in combination with Poster 2. But the Coder and other new features are brilliant too: recently I was experimenting with Will’s ‘Builder’ and found myself thinking “but wouldn’t it be great if Coder had a CSS panel…” Well, here it is! :-)

[BTW Google’s latest polyfill to provide legacy support for container queries seems really robust in my testing — and, as might be expected from Google, is really lightweight and quick. So there is now no reason not to implement container queries.]


Yes absolutely.

1 Like

I took advantage of the new Source update to improve my (Poster2) blog which is the most complex and largest of all my main site pages.

I replaced the Container, Header, Paragraph and Markdown stacks used within the blog, with Coder stacks. The latest update made this fine tuning process a lot easier using the new CSS box to finalise the CSS with live preview. I.e. Now it is possible to type in the Coder CSS code and view the live result.

Once finalised, I recreated the CSS into the page wide CSS code and called these using the class names and removed the code from the Coder CSS boxes. The individual blog items are a perfect place to do this because the same code can be used over and over.

I had been meaning to do this before but the way that RW / Stacks works breaks the flow during the edit process was time consuming. That is no longer the case.

The end result is a noticable RW /Stacks preview speed up, cleaner page code and a perfect 100% from Pagespeed result. PageSpeed no longer advises to Avoid an excessive DOM size which is due to now using Coder.


That is downright impressive…

1 Like