Menu
▾
▴
1 Attachments
#3113 no revert button in style editor even when CSS is defined
Dimitry, you had said:
And in order to see if the style defines its own CSS it is sufficient to look if the style node in a style editor has a revert button.
In the attached map in Style Editor, when the mouse cursor hovers over the Edit CSS button for style Notes or Details, I get the tooltip showing user-added CSS but there is no revert button. I do see a revert button when hovering over the same button for style Default.
Also, not sure if this is related, but even when there are no changes to the Styles in Style Editor, the title "Styles" in the window has an asterisk next to it as if there are unsaved changes. This remains after saving, closing, and reopening the Style Editor.
Since I wrote the documentation about CSS, I feel that the first part of the Bug is for me to respond.
@quickfold Please have a look at the following points
https://freeplane.github.io/wiki/#/css-for-html-or-markdown?id=order-of-css-application
Since I know that Default is applied to Details, filling in any undefined formatting properties, I also know that CSS added to Default is inherited by Details, filling in CSS which is missing in Details.
https://freeplane.github.io/wiki/#/css-for-html-or-markdown?id=css-for-details-and-note
Therefore, the revert button is only present for Default and not for Details, because CSS can only be reverted for Default.
The tooltip, on the other hand, shows the effective CSS that is applied to the Style.
As discussed in our previous emails about CSS documentation, please feel free to propose better wording to make it clear how it works.
Last edit: macmarrum 2022-02-08
Based on your explanation, I now see that there is a CSS tooltip for any style if there is user-added CSS in the Default style. But this is not the desired behavior. The point of the tooltip is not to show the user what fallback Default CSS will be applied, but to help the user quickly see if there is user-added CSS for a particular style when trying to edit that style. The current tooltip behavior does not aid that goal. Thus, I recommend that the tooltip behavior be changed to show the user-added CSS specific to each style and not to show the user-added CSS for the Default style.
Dimitry, your thoughts?
I must ask: how does that help, i.e. for Details to have a tooltip which shows empty (no CSS) when Default provides CSS that is applied to Details?
If I want is to see whether there is CSS added to a particular Style, I check if there's ↶ a revert button next to the
Edit CSSbutton for that StyleI agree, the tooltip is not the best way to indicate whether a style has user-added CSS. That was Dimitry's strategy to address the problem which he thought of and implemented. The solution I suggested was to have the "Edit CSS" button labeled as "Add CSS" when there was no user-added CSS for a particular style. I still think that is a much better solution, and our conversation here is evidence for that conclusion, since a tooltip showing fallback CSS is confusing.
I suppose I can learn to associate that meaning to the revert button, but to me, this is a really confusing use of the revert button. The revert button actually should not be part of the Style Editor because it has a different meaning there compared to its meaning in the Format Panel, which is where it was initially added. What is being reverted? If I change the user-added CSS for a user-defined style, and save it, and make 3 more changes on other days and save them, then the "revert" button will not revert to the previously saved state—it will erase all user-added CSS for that style. At least I think that is what it does.
Am I correct that the revert button actually deletes any user-added CSS for the selected style? If so, it should be labeled "Delete CSS", no?
Revert buttons were introduced following a request of quickfold although in some cases they are less powerful than check boxes used in previous versions.
And they always work the same way independently from the related formatting property.
The property value e.g. the font family or the color is always shown. Its origin style does not matter. If property is explicitly set at the selected node, there is a revert button. If you press the revert button, the property is reset to the value configured by the style.
The only difference related to the CSS is that here the value is shown in a tooltip and not on a button because it might be quite long.
Last edit: Dimitry Polivaev 2022-02-11
@quickfold
I like "Edit CSS".
The feature of a CSS tooltip showing "effective CSS" is a great idea, in my opinion.
To understand the revert button in Styles Editor, one needs to understand the concept of layered Styles in general.
Here's how I understand it.
Default is the base layer. Whatever is set on that layer will either shine through or be overwritten by the next layer put on top of Default.
Let's take Details as an example. It's a transparent sheet, initially. If
Font sizeis set on the Details layer, it will prevent the value set on the lower layer (Default) from shining through, overwriting it. All other properties will shine through. Same with CSS. If set on the Details layer, CSS set on the Default layer will be overwritten (ignored).Conditional Styles work in the same way. There is a list of Styles that are applied to a node in a sequence, layered on top of one another. Whatever property shines through to the top, is the formatting that is effectively applied and seen as the end result.
That being said, the revert button's function is an eraser, i.e. it's to clear the property set on that particular layer, making this property transparent. As you've noticed, clicking revert deletes CSS; it removes the change done to the property on that layer.
The revert button has the same function in the Styles Editor as in the Tool panel Formatting. If you think about this, properties in the Tool panel Formatting are on the top layer, above explicitly applied Style, above Conditional Formatting and the Default style (all layered on top of each other). Revert clears the property for that top layer so that it is transparent for any lower layer to shine through.
Last edit: macmarrum 2022-02-11
No, it is not related.
Just fixed in the source code.
Dimitry, I agree now, not a bug.
@macmarrum, I recommend adding more information to the documentation, in particular explaining that when the user edits the CSS in the Style Editor, the CSS field will be auto-populated with any Default CSS, which will also be show in the tooltip. I can't add to documentation any more because Dimitry removed me as an authorized contributor.
@quickfold Thanks for your recommendation. I'm not sure this is specific to
CSS. When I want to changeFont sizefor Details, Style Editor shows me the value set for Default -- the field isn't empty. By auto-populating (as you put it) the CSS set on a lower layer, CSS Editor simply follows suit.I can only guess the reasons for your login being removed form
freeplane-docu-writers. Anyway, I believe a Pull Request from your fork of the repo would be considered.I am open to your additions / changes to the CSS docs. Please feel free to contribute to my fork, if that's easier for you. My old become-a-collaborator invite still stands.
I removed you from the group because I got an impression that you are not going to work on the documentation. The group would only give you write permissions directly to the freeplane wiki repository, but even without these permissions you could create push requests which I could easily merge. If my impression is wrong and you want to start systematic contributions again I would invite you to the group again.
Actually, there are some related questions. The repository itself was created as an attempt to find the way how you could develop Freeplane documentation. Currently nobody else cares about it and it became just one of many currently not maintained sources of Freeplane documentation. Therefore I think that before anybody makes any contributions to this repository we should understand if it should be maintained or deleted. In the last case I need to move at least https://freeplane.github.io/wiki/#/css-for-html-or-markdown into the Freeplane documentation mind map because it contains great explanations not available anywhere else.
How do you guys see it?
Dimitry wrote:
I am fine deferring to your judgment on my participation, but I think we should be accurate and open with @macmarrum and the rest of the community. You told me directly over email that you removed me from the group because you were upset about statements I made on the forum, which you said were harmful to you as a person as well as to the Freeplane community. I generally consider it inappropriate to reference personal emails in a public forum without prior permission, but I do want to correct this inaccurate statement that directly involves me.
My view about the documentation site is that we should wait a bit for more discussion on my recent thread in the Open Discussion forum before making a decision.
Last edit: quickfold 2022-02-17
I've contributed my time and effort to the wiki (CSS, Connectors, Docsify config). I'd be sad to see it disappear. That being said, if it isn't the right tooling, it should be changed.
We should probably ask ourselves: if not the repo, what else is available to contribute and collaborate on documentation?
Reading the discussion Help figure out the new documentation platform! I can see there were many options considered, out of which github was chosen. I don't think much has changed since then in terms of available options. I'm wondering whether reopening the discussion would be a good idea.
I would like to keep the wiki either, I was just thinking out loud if it seems to make sense and if it is likely to grow or if it makes sense to keep it with only a few topics. If we decide to keep it it is fine, otherwise I would move the content somewhere else.
What do you mean by "connectors", is it a wiki page? Where can I find it?
@quickfold Yes, I was very upset because of some of your posts. I have not mentioned my private email because it was meant as a private email and therefore its content does not belong to the public audience. Today you asked a question about your deleted posts and I answered it in the forum. It shows that now you are back, your posts get attention and you are still taken seriously.
We can try to find together if you agree to avoid any form of personal confrontation, and to stop making any connection between ideas, decisions and persons. We can disagree with any ideas, have any opinions about ideas and question any ideas or decisions. However, I consider saying or writing "your idea is wrong" and "you are wrong" or "I disagree with you" in public to be very close to a personal attack.
We can disagree with points but not with persons. We should never question or attack persons because it lets them feel pretty bad. So they might decide to leave the project because of feeling the pressure and it could really harm the whole thing. And as a project lead I need to make sure that nobody including myself is stressed, everyone feels good, nobody is toxic and all of us enjoy being a part of this community.
Last edit: Dimitry Polivaev 2022-02-17
It's a section in understanding-nodes.md
https://github.com/freeplane/wiki/commits/main/understanding-nodes.md
Thanks. If we decide to abandon the wiki I want to integrate everything in freeplane docu mind map probably even as markdown. I value your contributions a lot and I want to have them in a place where the users are mostly likely to find them.
What do you actually think, which place seems to be better? If the wiki has a chance I would like to keep it, but now it seems to be quite tiny, doesn't it?
I agree that progress has been slow, therefore there's little content available. Yet, it's the only collaboration/contribution platform for documentation that we have, isn't it?
I am once again asking myself: if not the repo, what else? And once again I recall the many options that were considered and github being chosen eventually.
If you think there is a platform that would attract more contributors and make the progress more dynamic, I would love to hear more about it and discuss it further.
I don't know the truth. My experience says that the most contributions to Freeplane code and documentation were not a result of collaboration and swarm intelligence but come from individual contributors. For example, https://sourceforge.net/projects/freeplane/files/freeplane%20stable/freeplane-handbook-fullcircle-parts-1-15.pdf/download .
That might have been the case so far. In my opinion, if our documentation platform disappears, there's little chance that the situation will change.
To me, the creation of the wiki repo was an invitation to collaborate and a promise to provide a platform for people to work on improving FP documentation. I would be sad to see the door being closed on this initiative.
Please help me better understand how you see it: the disadvantages of having a documentation platform and/or advantages of not having one.
I am not against keeping the platform. I think that things happen only if someone spends effort doing them and that the tools should be chosen to make contributions and information spread as as easy as possible. I am just wondering whether, how, and when the current situation should be changed.
Let me elaborate. At the moment we have
I am afraid that particularly for the newcomers this situation might make finding the answer to their question quite challenging. By the way, today I have got an interesting chat with @rexelbartolome where he suggested to explicitly focus on onboarding for newcomers.
Maybe our current exchange does not fit this bug report well enough and could be moved to the forum?
And if you ask me which of the above collaborative wiki tools I prefer, I think that https://github.com/freeplane/wiki has the most flexibility and configurability (docsify), allows to create better quality content with less effort, uses standard language (markdown), the right entry barrier important for spam protection ( a github account, Pull Request and easy way to get editor rights), quite good github's own in-browser markdown editor, versioning, and it the most up-to-date tool. It has just got quite little content after it was started. And I would like to have a plan how we want to develop it.