Design Panel HTML: first impressions

Feature Request
1

Hi Pinegrow,

I started to use the design panel for HTML today and I wanted to give some feedback, a “bug”, and some general thoughts and impressions.

Creating and Updating theme.css
The theme.css file is created upon initializing the panel, and it’s placed before any of the rules so the main css-file can read them. This led to some abnormal behaviour since I reset some things in my CSS, so putting it last worked better for me.

I updated the theme.css file but that didn’t influence the design panel. It has it’s own rendering and doesn’t register change. This to me feels off since I can’t trust the css-file anymore and have to change things in the editor with the limitations of a visual editor to reflect in my code.

The second thing I noticed is that you can make variations of your designs, but the css doesn’t change with it. It’s like the css is not at all connected to the instancing I do in the design panel, and I believe in the background it’s Sass running and producing the theme.css file.

Editing and Syncing Design Panel
I already have some css-variables that I just would love to load into the design panel, and use them on the mark-up of the page. That would save a ton of work and the feature is already availabel: (!) uses it so why wouldn’t the design panel use it?

The benefit of the design panel is that you can actually create your design system foundation with it, and serve as the boiler-plate version of the styles panel. A JIT tool for visual editing frameworks, regardless.

The other thing I find missing is an export function. Yes, the theme.css can be exported to be used, but not in another instance of PG itself… You would have to remake it so you can work in a design panel with the design you made in the design panel. Meaning, the design panel doesn’t export very well to itself imo.

My take; give the design panel !-superpowers and some read/write/sync functionality, and it’s a winner. If every “new design” you create from the design panel would get it’s theme-1.css, theme-2.css name, it would be very clear which version is which and where to change things.

Buggy Deletion and Replication
I deleted the theme.css file to see if anything changed, but to my surprise everything still kept running. This is caused by the fact it’s still referenced at the top of your html, so if you remove that, deactivate the design panel and then reactivate it, it creates a new theme.css in the html but not in the folder

So in short; there’s a css-file in PG that keeps floating around and influencing the design, but I can’t delete it because it’s not there (I updated the whole project in PG, double checked in Finder and VScode). The weird thing is if I outcomment the href in html, the styles do disable so it does read something.

But like I said, it’s probably some Sass-file still running live because it doesn’t rely on the generated css-file to be applied to your page. This is bad because then what you see in PG is not what you will see IRL, it’s literally a layered illusion of a css-file that will never be shipped with your product.

So like IKEA, for now only put it together once because it works nicely. But delete it or deactivate it and stuff can get funky.

1 Like
2

Well, I gotta admit, I’ve not looked at what our @BonoBoos is exploring here, but I DO like his style!
I also loved exploring the inner twiddlngs of how PG does things and it really got me into fiddling about with it.
Alas, I haven’t had the time for it for a while now, but this is GREAT to read! :smiley: its really good to see people trundling around the dark cogs if its inner mechanisms, carefully avoiding stepping into the Cogs of the inner mechanism, still getting things done, and then seeing the wobbly sprockets/ bent shafts, and saying

Hey! how the hell is that doing that?.. Ah, maybe this would work/be better/ be broken if…

Taking the time to explore this stuff, and then taking the actual time to report back in a well thought out manner is great to read/see and could be of great use to the PG team.

Respect @BonoBoos

:slight_smile:

1 Like
3

Hi @BonoBoos,
The idea about being able to name and exports designs is a good one. We will consider it for a future release.

In the HTML Design panel, everything is powered through standard CSS. The colors are added as vars. Some changes utilize those vars and many are flagged as !important to overwrite existing rules with the Design panel rules.

With regards to other CSS variables - any that are added to your standard CSS files should be available in the style panel dropdown. I guess it is a work-flow preference if you want all project specific variables in one place, or if setting some up in the theme.css file and the rest in another stylesheet. Note that from within Pinegrow, the theme.css file is locked for editing. When changing between saved designs there is a chance of over-writing any modifications. Also note, the saved designs are saved within the projectdb.pgml file. Any valuse for the Design panel are parsed from there.

As I pointed out in the other forum post, Pinegrow caches some files. So just deleting them is sometimes not enough. You need a refresh to eliminate them. I’m not quite sure what you mean by

For me, after project save and refresh the ‘theme.css’ file is re-written back where it was originally.

I guess overall, the vision behind the Design panel is to set your theme styles at the very beginning of a project. Then use it to make variants of that same project. After a variant is decided upon, deactivation of the panel leaves behind your styling decisions that can then be easily adjusted visually from the normal styles panel or from a code editor if desired. It wasn’t really designed for a use case of repeatedly turning the Design panel on-and-off.

Cheers,
Bob

2 Likes
4

Great stuff, thanks for answering a few of the things that caught my eye. I don’t thik I’m actually using or seeing functionality that was not “as intentional”. I like to think of those intentions as robustness, so the more robust the design panel is the less easy it will break. This broke quite easily and I don’t think without any robustness you will have full control over your theming.

As a matter of fact, it’s the only tool in Pinegrow that has it’s own layering and naming. The rest “just talks” to CSS and is a visual coding tool, the design panel is a UI-tool on top of a visual coding tool. I think that seperation of concern can have a healthy influence on how to look at the intended functionality of the panel tbw.

2 Likes