Hi @matjaz
You’re welcome. Thanks so much for taking time to respond, before it too slipped into the abyss. 
I also posted a few other “detailed” Feature Request ideas here at the forum if you are interested. I am happy to share thoughts and ideas to help improve Pinegrow. Especially when they can advance it further to help benefit existing users and gain more users also.
As you say, I noticed the groundwork getting in place for such features becoming reality. But I do acknowledge it is perhaps not as simple as it would appear, mostly due to workflow considerations and outcomes, and that there are considerations and concerns that may go along with any feature development.
It’s really nice however to hear your response that it’s something you are working towards.
Fragmented CSS
As it stands right now I believe this type of fragmented CSS can still presently occur and still remains to be considered even with the workflow as it currently stands at this moment.
You can go into Pinegrow and start using the new Visual CSS Editor, which by default creates a “inline style attribute” for the selected item you are working on. You can do this on as many items you like and Pinegrow will amass a list of “Classes without rules” which translates to all these visual edits placing inline styles on items.
The user can then save the file without warning and these inline styles will remain in place. Of course we know inline styles are largely frowned upon in general within the industry as it fragments the CSS workflow across locations and makes maintenance a nightmare to search for all the corresponding CSS instances in multiple locations. But having said that you can use it effectively, to create HTML emails which may require inline CSS, etc.
So what to do, or what can be done to help prevent this inline CSS fragmentation?
Perhaps a 3 Step Actionable Warning System approach as follows:
1.]
Advise the user upfront with an overlay covering the entire Visual CSS Editor with an informative warning explaining the workflow in quick simple terms, or even video doing the same. So the user understands the correct way and the ramifications of not following the suggested proper methods of declaring classes, etc… This advises of the process, and places the outcome and responsibility with the user. It would also be a chance to make the user aware of the following two related features.
2.]
The next thing might be a “common indicator” (relevant icomoon icon (to stick with theme), or custom icon, etc.) that shows visually on page which items still have inline CSS attributes. Have some kind of CSS Inline Style (red) warning indicator displayed on each item, where inline style attributes are found to exist. Such an icon + warning, could be located in each items control bar when selected, or even displayed when not selected. There could also perhaps be a CSS warnings icon in the top icon bar of the app that toggles the display of the icons on all related items which have inline CSS, so the user can address each instance that displays warnings. When these warning icons are rolled over it could display a (red) tooltip immediately explaining the issue. It could also be present in Tree View to the left side of each item, and basically anywhere else which is relevant across the app for each item until inline styles are dealt with by the user.
At which time, when a class is declared and the inline CSS is no long present for the item, the indicator disappears across the app from all visual occurrences being displayed for that item. It would help give multiple opportunities to warn of such inline CSS attributes present and give the user multiple opportunities to address it. These indicators would help users to clean up things as they work as needed, and also lessen the length of the compiled list given in the next suggestion (#3) which happens upon Save, Save As or Close, etc.
Here are quick generic examples demonstrating the above ideal. Note: I’m not saying it fits with the UI design, just for the purpose of quick reference regarding #2.
Etc., You get the idea, across all relative features and areas as needed as briefly described in #2.
While #1 & #3 should be more obvious regarding what they discuss, without showing examples.
3.]
The last thing would be to quickly parse the HTML and check for inline CSS “style” attributes in the source upon trying to Save, Save As or Close, etc., and display a scrollable module window with a list of all these instances of inline Style Attributes behind a description of what it is they are associated with (img, div, id name, etc,). Have the same + button for “Save element style to CSS rule” beside each item to give users a chance to correct any remaining inline styles present from using the Visual CSS Editor, etc., that still remain after the above two warnings and opportunities. It could act like the present features that when you select each instance it takes you directly to that item, if you need to explore it further before deciding on a class name or association. Also give the user the ability to quickly bypass this process and simply acknowledge the warning and issues and proceed directly to Save, Save As or Close, etc. Then its again left on each user how they want to later rectify the inline styles and not on Pinegrow just like the initial warnings.
Would be applicable across CSS features:
The same type of solution would be in place for items “modified directly on page” as discussed in this feature request for Basic CSS Properties. Obviously all CSS features need to remain working in conjunction as they presently are. If the approach is taken as described by also having a button in the top bar to enable disable on page edits of basic CSS Properties, that again would be a chance for an initial warning information described above, and interaction by the user.
A developer should quickly learn or already be aware and know the current new Pinegrow CSS workflow already. But in the midst of working and using the Visual CSS Editor, or via on page direct item controls (as discussed in the first post), even a seasoned developer might let something inadvertently slip though as inline CSS. So it’s not just towards the newer less experienced user that this can occur or be a problem. Thats why perhaps a multiple step warning process (as described above) which is modestly direct and “encouraging” is needed to ensure proper structuring of CSS within pages and projects by users.
Having such failsafe warning methods, seems like the only way all case scenarios could be noted and addressed concerning avoiding inline CSS style fragmentation, and helping to create structured code and maintainable projects. Since you obviously can’t assume everyone has the same understanding or comprehension of the application or web development in general. So this type of approach would seemingly be needed to help prevent such cases and actively make the user informed and actionable.
Or do you get even more direct and force the app too demand a CSS Class ?
Forcing the declaration of a class by the user for each item, if an existing class is not found when any type of user edits occur per item. This would occur when a user selects an item and uses the Visual CSS Editor, or the discussed direct page manipulation of Basic CSS Properties in this thread, and across the other CSS manipulation methods, etc. At which time they are forced to first declare a class via a prompt. But then how do you handle that as each item can have multiple classes associated with it, you would need to have all the existing associated classes offered to the user in the prompt to decide which class the settings and changes get added to.
Is direct forcing the right approach however, or are the 3 more subtle tactics mentioned above regarding indicators and process better. Certainly it would be less in your face as described above verse forcing the decision constantly of the user and demanding a class.
Subtle encouragement and actionable methods:
I feel the 3 step actionable warning approach described above would be a better method vs constant forced interaction. Plus it would be easy to document and show in video, so the the process and workflow should quickly become self evident to all users. With in app documentation you can even launch and go to specific sections from within the app areas and features, as the documentation is developed further.
Regardless a method has to be in place to provide the user a method of interaction to understand the presence of inline CSS derived from these types of various Visual CSS Editing methods, and a way to easily address it through actions. I think the above 3 step approach could enable an easy clean workflow, while creating and encouraging clean source output and provide maintainable and structured code for pages and projects. While working all within the existing app structure, logic and workflow, with out creating a mess as you said.
Obviously to not annoy users, these types of warnings systems should also have the ability to disable or toggle for those users whom don’t need them or don’t want to see them constantly.
What are your thoughts @matjaz concerning these ramblings ?
Agreed, thats why I specifically asterisked the “constraining to parent objects or areas *” bullet, as I knew parent child relationships and properties will be important within such a workflow.
The width example you give, and all relative things similar. Would it require some type of fast algorithm for runtime checking. Evaluating up and down each items parent child tree what CSS properties exist and comparing that to defined rules and constraints to know what properties work with each other or against each other concerning CSS properties up and down the hierarchy. But with many scenarios and property comparisons is such a method possible or practical? Could such a runtime or algorithm and workflow be created or efficient, to gather and compare such arrays of properties conditionally against each other. Perhaps, since its a limited basic set of properties to compare against that was suggested. Then what do you do if a property does not comply, etc., disable the feature per item? Maybe.
I would hope however that there may be an easier answer or approach to allow smart on page visual editing of the basic CSS properties mentioned. But I understand that many things need taken into consideration and its not simply just black and white, but a bit of grey.
I do too, again I do too !
Hopefully that all makes some sort of sense. I look forward to any feedback, thanks for your time and consideration. @matjaz .