search

rishikanthc / markopolis

Markdown Programmable Interface
https://markopolis.app
MIT License
160 stars 2 forks source link

Suggestion/improvement request - expose the frontend/ app.html , favicon and *.css files #15

Open cromelex opened 2 months ago

cromelex commented 2 months ago

Hi,

I just thought I'd suggest the following to allow light customisation:

Mapping the frontend/ folder, or partse thereof, to a volume so that the app.html, favicon and the .css can be modified. This would allow for an easy way to do light customisation.

I know you've mentioned the ability to use and entirely different frontend, but that would be beyond my ability ( and also not something I'd want to spend time on ).

However, it would be cool to have the ability to do some very light customisation. A previous project I used for basic .md websites ( https://github.com/dbohdan/caddy-markdown-site ) allowed modifying a few bits of the html template and changing the .css.

As far as I am aware, Obsidian Publish also allows users to change the look of their websites by changing a .css. So this would fit in with that.

Thanks!

rishikanthc commented 2 months ago

That's a great suggestion. Yes I shall expose the ability for custom css. I can modularize different parts to give you the ability to customize your layout. I'll have to check how much customizability I should support but this helps also use custome css in markdown just like in obsidian. I'll work on this as the next feature.

rishikanthc commented 2 months ago

I gave this some thought and was wondering what level of customizability would you need. For eg. at the component level like file-tree, the rendered page, etc or fine grained customization ? I think there's a trade off in terms of complexity of enabling this feature. I think I can make this work by allowing custom css that can be attached during run-time to override specific classes or style settings for specific aspects of the design.. This would be feasible and would not cause too much overhead. Let me know if this is along the lines of what you were thinking or you need something even lower..

cromelex commented 2 months ago

In my opinion you should make it really high level. And keep it simple for people with close to zero web development skills (me included).

If you consider the target user as someone who essentially wants to be able to publish markdown notes (like an Obsidian vault), then I think for most people there's 2 main things:

  1. Structure of the page ( Maybe a true/false setting env?)

    • file tree navigation / sidebar
    • outline (it's great for longer content, but takes up screen space
    • graph (I know a lot of Obsidian users really like the graphs, I don't care for it but just mentioning it)
    • obsidia-webpage-export does this, where it allows users to toggle on or off these different sections. I think this works really well, and it's about as customisable as you'd want, without getting overly complex?

  2. Theming. I know very little about this, but ideally you'd want to maximise the options for your users by making it compatible with existing stuff, by just dropping in a stylesheet?

    • caddy-markdown-site does this by allowing users to change the stylesheet in the head.html, and just using this to "theme" their site
    • obsidia-webpage-export seems to integrate Obsidian themes, but it does that by being a plugin for Obsidian rather than a standalone tool.
    • Could be an idea to piggyback on Obsidian's publish.css stylesheets? Ie just allow people to drop an existing publish.css like the ones from obsidian minimal publish theme to theme their pages?
rishikanthc commented 1 month ago

So for the structure of the page, when you mean true/false setting in the env, are you talking about enabling/disabling that component entirely ? Or you want to make it toggleable like in Obsidian-webpage-export ? Making the sections toggleable is definitely easy to implement.

So regarding theming, do you only want to change the colors ? I checked out the Obsidian minimal publish theme, and it basically only seems to be setting the colors of different elements. publish.css seems to be overriding predefined variables to set new colors. If this is sufficient then it's very feasible to add this feature.
It only gets tricky when you want to adjust the design/layout itself. For eg. if you want the file tree on the right instead of left.. That sorta stuff would add more complexity and I would need to give it some thought.

Does this make sense ? So here are the options..
option 1: allow mechanisms to change all colors.
option 2: layout level flexibility to change any css property

option 1 is straightforward and can be done while 2 is more complex and would need time to analyze. Let me know what you think.

cromelex commented 1 month ago

So for the structure of the page, when you mean true/false setting in the env, are you talking about enabling/disabling that component entirely ? Or you want to make it toggleable like in Obsidian-webpage-export ? Making the sections toggleable is definitely easy to implement.

Obsidian-webpage-export (which I tried and which is why I'm comparing against) allows users to completely disable components in the export settings. If I choose to disable the graph, it will not be present at all on the export. If I enable a component, it'll allow me to choose whether it starts collapsed or expanded.

Personally, I am not sure if you need to go that far. I'm perfectly happy with just the ability to toggle (by which I mean have it present, but having the button to show or collapse) each of the components (like the current tag explorer). I'm not a fan of the graph, but that seems to be an important thing for a lot of people using obsidian.

If you give me option to disable that component, I will, but otherwise I might simply start with it collapsed if I'm given the option.

Likewise, if someone doesn't really use headings within their text, the ToC becomes useless. Same can be said for tags and the tag explorer.

I would not go any further than this. Based on your comment about layout complexity, I don't think it's worth it to start allowing to move things around.

tag explorer:

table of contents:

graph view (from the roadmap):

So regarding theming, do you only want to change the colors ? I checked out the Obsidian minimal publish theme, and it basically only seems to be setting the colors of different elements. publish.css seems to be overriding predefined variables to set new colors. If this is sufficient then it's very feasible to add this feature.

I think colours, font and maybe font size will be the 3 things that most people would be interested in.

If you change these you can make any site look entirely different.

Just going to link the obsidian publish theme docs for reference: https://docs.obsidian.md/Reference/CSS+variables/CSS+variables#Obsidian+Publish

Does this make sense ? So here are the options.. option 1: allow mechanisms to change all colors. option 2: layout level flexibility to change any css property

option 1 is straightforward and can be done while 2 is more complex and would need time to analyze. Let me know what you think.

I think option 1 is the clear winner. Layout changes will introduce too much complexity. An override file might be best?

Optional bind mount in docker with a publish.css or theme.css where anything set would override the default ? This simplifies the deployment.