Support definition of custom types
LokiMidgard opened this issue · 9 comments
Is your feature request related to a problem? Please describe.
You can currently change the way a document is rendered by specifying the type metadata. But only the 2 predefined.
I would like to create different documents that should be rendered differently e.g.
- invitation
- protocol
Describe the solution you'd like
A folder custom-types in the installation that includes css files. When a type other then slide is specified,
include the css with the same name if available.
If more advanced features would be required, a script which transfors the html or markdown before it get renders cold also be added in the folder
(Seems not be nessasary for my use case)
Describe alternatives you've considered
I currently have my own script localy where I copy paste the MarkDown to render it localy.
I also thought about creating a fork and hardcode the css
Additional context
Hey @LokiMidgard,
intersting idea. At least to me the CSS part of your request sounds like it would be solved by hedgedoc/hedgedoc#2876. You would of course have CSS code in your notes then, which may be undesireable, and also old notes would not be updated with your latest CSS code, but I think aside form that it would be what you want.
Especially for protocols where you could include some base structure you need in every protocol.
Aside from this your advanced feature would be a lot more complicated and probably not something we will tackle in the foreseeable future.
I hope this is of help to you.
@DerMolly I'm not sure, if your right I totaly misunderstood hedgedoc/hedgedoc#2876. For me template means to have a preconfigured front matter. What I'm looking for is a way to change how the html is displayed. Which seems not be possible currently by adding metadata to frontmatter.
The advanced function seems also a bit complicated to me. I used something like this for a markdown parser that did not support footnotes in the past. So I thought I add it for compleetness. But it is not something I activly request :)
What I mean is, currently it looks like this:
after applying custom css it should look like this
forgive me that I haven't photoshoped the later in the preview section of the first. But I hope what I would like achive is understandable.
For me template means to have a preconfigured front matter. What I'm looking for is a way to change how the html is displayed.
Template means a new note is created with the contents of annother note by copying it on creation. As you can include CSS in a HedgeDoc note your idea should be possible with this…
https://demo.hedgedoc.org/jUYcTkYcT_Oj7i6jTkFKlQ#
<style>
h1 {
color: red;
}
</style>
# HedgeDoc CSS Test
Some other text unaffected by this
Thank you I wasn't aware that you can add css to hedgedoc
You're welcome. Maybe you want to have a look at https://docs.hedgedoc.org/references/hfm/ to know what else HedgeDoc is able to do…
tl;dr
I think I could handle a document with a custom styling. Some people I want to work with, I'm not so sure.
A way to hide the css from the end user seems nessesarry for my usecase.
I tried your suggestion and it works, however I find it a little bit complicated for non tec people. The css I tried had around 400 lines of code, It can propably reduced but it will take some space. And the (some) end users will be confused by the style sheet.
They will not know where they can put there text, propably add/remove/chage style code accedently resulting in invalid css.
I don't think the abilit to hide the css by clicking the arrow at the beginning of the style would solve that. It would propably be fewer people that runn in the problem but some will find a way to accedently open the style tag...
And in the end it will be fall back to word documents (.doc not .docx) send per mail in multiple versions....
Normally you only get one shot to introduce a new system, if there is too much friction, its back to the old one, forever
I will reopen the issue, but feel free to close it again, if it is out of scope for this project.
Okay let's break down what you're requesting here.
You want an easy possibility for users to specify the style of a document.
IMHO using the top level "type" key wouldn't be the correct way here, because this key defines the type of the NOTE and which renderer should be used. Right now that's either document or presentation.
What you're describing are different types of DOCUMENTS like "invitation" or "protocol".
While it would be possible to change the fallback of the top level "type" key, I wouldn't do it. It would add a side effect that makes totally sense for your current use case but could be confusing for others because it's a bit hidden. It also mixes up note types and specific document types.
I can also understand that inserting large chunks of CSS into the document is undesirable as well.
So my proposal is a compromise between easy custom css and clean side effect free frontmatter:
We add a new key "style" that just imports an existing css file from the public directory (or a subdir).
It should also be pretty safe because the css is only included in the renderer and you need file system access to modify it.
@DerMolly @ErikMichelson what do you think?
Tahts pretty much exactly what I need :)
The style keyword in the metadata is tracked in hedgedoc/hedgedoc#2954. Therefore this can be closed.