What is the difference between Element Properties and Styles Panel? They both contain css properties.
1 Like
Yep! same here, this confuses me too.
Hi, guys. I may be completely wrong here (I’m very new to Pinegrow), but I suspect the difference is that the Styles section is for styling that is created by adding the style code directly to the element (ex. < h2 style=“color:red” > within the body of the HTML … as opposed to the Element properties, which may be styling done via the external style sheet. I may be wrong, but that’s my theory, if I’m understanding what you are asking.
If this is true, then I think that body based rule can be moved to the external style sheet by clicking the Save To CSS rule (or something to that affect) icon beside the rule.
( Embarrassed shrug )
Quick Introduction to Pinegrow
See:
- ELEMENT PROPERTIES
- STYLE – PAINT WITH CSS
Also see the following:
Element Properties
Styling with CSS
Reading those should provide the understanding between Element Properties and Styles Panel.
1 Like
Not really.
thats why he and then I asked for a concise, simple explanation that I can factorise into my/his understanding.
reciting a pile of links merely shows that you can’t conceptualise the difference and explain it simply in a line or two…the same as myself
so its probably either not well explained (I’ve already read those) or, the difference isn’t that easy to explain, or the margins are fudged, so , again, same question asked as this answer simply isn’t an answer or doesn’t address the issue, of poor explanation of something intrinsic to the product.
this answer is go away and read these same things again and then try to be smarter next time
this doesn’t always help.
3 links to explain one basic item question isn’t the way to go, especially when some of those links point to areas of our docs, which frankly, are even more confusing!
ie, the one instance that @ladlon mentions
ie,
Style attribute
“Style attribute” rule is always listed at the top of the Active rules. It represents the style attribute of the selected element. Its properties are not stored as a CSS rule in a stylesheet. Rather, they are listed in the style attribute in the HTML code of the element.
For example:
<h1 style="color:red>I’m red!
Although the style attribute is the quick and easy way of styling elements, using it is not recommended. Why? Because instead of using one CSS rule to tell the browser that all H1 elements should be red, you have to specify the color on each and every H1 element on your site. Now imagine that you have 20 pages and want to change the color to green.
But, Pinegrow knows a smart way of using the style attribute:
Edit Style attribute and then save it as a new CSS rule.
Use Style attribute to quickly style the selected element using the Visual editor or CSS List editor. One you’re happy with the result, click on the WHAT GOES HERE?-BLUE CROSS IMAGE? to save the style as a new CSS rule. Pinegrow will create the new CSS rule, transfer CSS properties from the style element to the rule and then clear the style attribute on the element.*
Jesus!
wouldn’t it be easier to say
“Style attribute” rule is always listed at the top of the Active rules. This is JUST for for the inline styles of this ONE SELECTED instance of this element. If you want to style ALL of this type of element on this (and other pages) the same, then click the BLUE CROSS to the right of Style Element (1) for this style to be saved to the preferred external style sheet instead, specified by yourself in project preferences.”
Or suchlike.
now, that is more time spent digesting and figuring out our own docs, still not figuring out the exact difference, of the initial question, (I will admit I need to also spend more time on it) I know it also has to do with frameworks and framework elements… which are different to HTML Elements. which I think is where I and others get confused. but then. my own docs confuse me and I have to read, re read and rework them.
but still that has nothing to do with the initial question.
for instance,
a button.
nice simple plain html page.
add a button.
you can click on it , edit its style.
Element properties…er not much going on.
so you would style it in the styles tab.
this makes sense
BUT,
if you now, go to the libraries tab on the left,
select
Manage Frameworks and Plugins , the two tools icons,
then select and activate Bootstrap
WOAH!
now, you have a choice of (BOOTSTRAP CLASSES ) colours to pick from in THIS tab and other choices (from OTHER Bootstrap Classes) -which can be applied to the BUTTON ELEMENT. ( and all other elements, where applicable)
so,
emphasising the fact that this ELEMENT styling tab really comes to life if you engage FRAMEWORKS
should probably be OVER emphasised more.
yeah long post. sorry 
but it has made me look at it more and understand it a bit better.
by explaining things we are often forced to understand it better ourselves.
so, just posting lots of links, doesn’t always help.
ie, I found grammatical/logic errors in our docs and had to find a way to explain/show how the element properties Tab, comes to life and has color when - we add a framework!
and this life, is due the Classes we can add, from that framework.
to explain all this has taken time.
I have also learnt something more about our (sometimes confusing) interface.
If the explanation is missing or non sensical, it is better to
Create a better one
so just create a new blank simple html page.
add a button,
look at the style and element tabs
then
activate a framework (ie, bootstrap)
then, see the difference in the Element Properties and Style tab.
thats how I noticed the difference and realised my error In my understanding, with regards the Colors for instance and where I should change them , if using a framework
so, thanks for making me think
I hope the explanation helps some others
@schpengle TLDR
imho the documentation is quite clear.
-
Use Element properties panel to edit element’s attributes. For example, to edit classes of any element, or to change source and alt text attributes of an image. The panel also contains controls for properties defined by frameworks like Bootstrap.
-
Styling – painting and positioning elements – is done with CSS properties and rules.
1 Like
Yep that is a good explanation.
but… a little buried and just one line.
Its a REALLY important part that doesn’t quite explain the difference of when to use which
and the ABSOLOUTE BRILLIANCE of it! for frameworks.
it gets a bit lost in the Overwhelming splendour of our Interface and its great Capabilities.
If your a beginner…and your look at our interface… ummm,
that aint gonna cut the mustard!
hence someone asking the difference.
because if your using a FRAMEWORK… THIS is where all the FRAMEWORKS classes appear and This Element Properties tab really comes to life!
Its awesome.
but, if you are beginning, and you have just gone bootstrap! cool! I’ll activate that
and then fire it up.
you now see lots of colors for Element Properties…Tab
you have colors in Style Tab!
if your beginning with either frameworks or our interface or both.
you now have two places to make those changes>
thats without… our slightly confusing explanation of inline styles.
so maybe greater emphasis should be put on WHEN to use the Element tab?
I Don’t know. but, to be honest, explaining this for someone else has helped ME work it out as I have been confused by it.
so, I shall now go and carry on RTFM
And it might be a good idea to look at the bit In our docs I highlighted. I think there is an explanation or an image (blue cross for adding styles to sheet?) missing in the explanation
and the image at the top of the page is good, but maybe ALSO highlight the Bootstrap 4 (or whatever framework) part on the left , next to Layout, so that it can be seen that this element tab is styling WITH Bootstrap 4 styles.
sounds obvious but, if you have colours going on in several places, it would/could help the explanation.
ok I’m off to read our fine manuals again. cheers, Ive worked some stuff out.
Any way, this is great! Im getting to the bottom of some of the interface stuff which still confuses me when I’ve been away for a while
Ok, Attribute editor and Visual editor study for me tomorrow!
Agreed. 
?
ok then. Ignore the users that are highlighting issues.
Ostrich mentality.
we have v4 docs. v3 docs, beta docs, I guess v2 docs. thats a lot of docs to be keeping on top off and ordering.
there is no point patting yourself on the back and ignoring the feedback.
Opening with comments such as that (or others riddled throughout ) certainly does not compel a person to expound, paraphrase or help further.
Speaking in general.
[ Off topic regarding documentation ]
There are obviously still attributes of the documentation that need filled out and finished, along with videos that were discussed back around last summer regarding whether to use a computer voice vs human voice. Having incomplete documentation of course does not help, as it fragments the understanding with users having to dicier across differentiating versions and UI’s, or with nothing at all.
No doubt more updates to the documentation resources (written and video) are still to come and the staff continues to work on these resources.
v4 was supposed to be the culmination of everything, the documentation, etc., but obviously this is still a work in progress. There has been indicators of a new main site appearance a few times, so I assume things are still underway for some major transition to the new version since the rewrite. We are now back to the dot release versions again (even though a few more milestones where seemingly reached), so not sure when that actual transition will culminate, v5 ?
Obviously the Pinegrow team is small yet nimble, and has a lot to accomplish between the main application development, new features, performance, bug fixes, documentation, marketing, participating and helping across communication channels, etc., etc. So a lot of times documentation can fall behind and suffer because of this. I have seen it be the case with other small development teams as well.
The other thing is developers obviously have a clear understanding of the how and why of features and workflows of their application. But sometimes that does not translate into documentation that is clear or simple for those that are just users, especially new users, or for new versions. Or fully encompass documenting all features, sub features, points of entry for usage and workflow, general intricacies and insight, best practices, tips and tricks, etc., which is a massive undertaking to document.
Many times things are taken for granted and only come out if specific questions are asked by users. It is easy for developers to take things for granted and not understand how to translate all of what they know as the developers down to the user about their application. But it generally comes down to time and resources, as documentation can be very time consuming, especially for small teams.
When writing documentation its hard to set aside the concise understanding for a developer and in contrast clearly and simply explain to the mindset of someone whom is a user and does not know perhaps anything. So many times, documentation is written from the developers point of view and understanding, not from a users point of view of not knowing.
Generally though users don’t take the time to understand software or familiarize themselves within a software through practice or trial and error, reading the documentation, gaining general understanding through general research of the underlying tech and terminology etc., before complaining or asking questions they could educate themselves on. So like most things, both sides play a role.
This is historical regarding documentation for many applications. But just like features, documentation can likewise be improved through user feedback, most developers gladly welcome understanding such deficiencies and ways for improvement. But any feedback should be as clear and concise as possible, without nonsense and precisely focused.
@Pinegrow_User, yeah I hear you on that one, but do you honestly think that replies such as
inspire people to post and ask for help here too?
Just MAYBE, they have studied the manuals intensely, before posting here, out of frustration, as the manuals contents changed for another version/release, or application has changed and manuals HAVEN"T been updated (which is far more common, with our amazing release cycle.) Or the manual simply contains mistakes or is a little confusing grammatically, just like many manuals.
We have several versions of everything, mixed up.
My riddling of comments throughout, was intentional.
This is a peer support forum mostly, but we are really lucky to have a dev team that actually lives here too and helps out! 
but are pretty busy, so we should all do the best we can.
To merely dismiss some (non daft) requests with a mere
must try harder, your not trying hard enough statement,
also is a not a great incentive to encourage people to try and ask for advice that many others may also be struggling with.
Not every questioner is as gifted/smart/clever as every responder thinks they are. So while pointing out some links might be spot on and very helpful, the comments that go with them aren’t always.
Touche, if you like.
worth thinking about.
Anyway , this is off piste to the actual topic and I do agree with your larger, secondary (and again, off piste) comment.
This has been a great topic! it has forced me to yet again, RTFM and battle on to figure some stuff out thet had also confused me and I have read a lot of docs, but still lack some understanding, so, while certainly having tried to get my head around some stuff have failed or become confused and couldn’t quite find the answer - that was right for MY WAY of thinking.
Since I am limited by… my way of thinking!
So docs are for someone else way of thinking.
Thats why we have forums.
Thats why we have feedback.
And thats where and why we can ask questions
And if the dev team sees the same topics or questions constantly being asked, then if they are lucky enough to have the time, they can address these with an FAQ section or, actually address the topic or area, with the extra hindsight of the though process and viewport of actual consumers, which , after all, is who this is now intended for.
This is great! constant extended beta testing for free, its not negative, (mostly) its feedback.
Anyway… back to the manuals for me.
This is great, trying again, now with V4 which is certainly much better than 2.951, which I still also use, but its damend confusing going from one to the other.
Ok, ciao, keep up the good work
It could be said, that this all has nothing or pretty less to do with application. It could be further said, that if you use a framework you should be aware of what a framework is and what it can do for you. This all could be said - it could be even said, that the original question is somehow confusing or misleading, making the job hard to answer.
What is a framework?
It shares (beneath HTML and JS stuff) a whole lotta bunch of predefined classes. This makes styling quick and efficient. While you usually have to seek those special classes within a large documentation, PG makes you the stuff much easier. It comes with a “GUI”, where you can set those classes intuitive. So if you want your button blue, you click on the color-spot for blue - the button appears to be blue AND a class of “btn-primary” has been added to the element. This is just because the underlying properties for this is class is
.btn-primary {
color: #fff;
background-color: #007bff;
border-color: #007bff;
}
Why the heck under “element properties”?
Because you add a class to the element which is “element-land”
So in fact, the GUI is just a placeholder for styles - not a “style painter”. Cause if you now want to overwrite a frameworks class, you have to bring them on a overwrite.css style-sheet. The framework itself is not dedicated for to overwrite.
Cheers
Thomas
1 Like
Yeah. Pretty much so, @Thomas and I guess you mean, at the end there,
that you shouldn’t edit and overwrite the Original Framework’s Class styles, which, say, declares a button’s colour as Danger and save that back to the Original framework’s stylesheet,
But rather, the correct way is to replicate that framework’s style in an external custom style sheet, which is attached AFTER the frameworks actual style sheet and, so doesn’t touch the actual frameworks, pristine classes.
which is, as you know, how it works.
but trickier to figure out, as a beginner (or intermediate) when first encountering our interface and maybe, have frameworks thrown in the mix too, just for fun.
so good points Brought up.
And the interface has just had me with a few more Gotchay’s! so, back to the manual again for me
its the mechanics of this process which catch me out, in our interface, even though I understand the process. and , I just ended up, back at the original question again, trying to do something.
ok, back I go
mmm… and do you mean that the Element Properties tab, in the GUI , is just a place holder for styles? (and somewhere to add and remove them, but not edit/create them)
oh, and attributes.
you can just list them, add them, remove them… er well actually, you can edit them, at the top section.
just no funky drop downs, you just edit the blue text.
Ok, manual…
The other thread you noted has nothing at all to do with Pinegrow or the manual, it’s a generalized question.
They also later asked for a full and complete explanation / solution of the conversion. Having previously been immersed in the same tech as they were speaking of, I fully understand the transition is not 1 for 1, hence the general response that it will require effort to learn and move on. The same person posted about centering CSS, and also made a thread that Pinegrow does not support transparent images which they quickly deleted.
So I’m not sure what your general point is to try and take little excerpts from that thread. But the overall example certainly proves the following point.
If you look across the landscape of the internet where peer to peer communication exists via Forums, Blog Comments, StackOverflow, etc., and the numerous endless venues to do so. You will see constantly people asking the same or similar questions, or asking for a complete solution from others. Which shows they either clearly fail to search and self discover, or do not desire to learn at all and instead wish to have others do their work for them.
So there is nothing wrong with encouraging people to learn and help themselves. However sometimes it seems from a perspective of harshness, because sadly people adamantly do not wish to do so.
Give a Man a Fish, and You Feed Him for a Day. Teach a Man To Fish, and You Feed Him for a Lifetime.
You’re welcome.
or, the one big point you miss,
the resources, they are all checking… suck
in some respect that is confusing them all.
so pointing to the source of all suck is not helpful.
Addressing source of suck is.
if something isn’t explained well, is confusing, or has multiple versions of explanations, for multiple versions of interfaces, and they don’t correlate with the version your using, well,
Suck might be playing a part.
Don’t overlook this .
Try and re read the source of suck from another point of view, ie, that of the recipients point of view, as indicated by the question, not as someone who creates said, suck
this is the missing point < otherwise, yeah I agree with you.
Lets help eliminate suck in Pineland,
same as BBEdit land 
https://www.barebones.com/products/bbedit/
N.B. and by suck I mean they fail to explain in some way,
You seemingly missed mine completely. 
Is that intended to be encouraging for all the effort put into Pinegrow and it’s developers? 
Nice edit / save.
Sorry, I can spend no more time on your whimsies,
Im concentrating on the actual question, how best to deal with it and my grasp of the interface too.
You just concentrate on whatever point it is your trying to make, IM interested in the originators question, our interfaces and how best to answer the confusion that sometimes arrises from it.
Im not spending on more time discussing this with you.