As of currently (late 2020, what a year) and according to the official documentation, adding a new note type requires editing several files in the plugin:note distribution, such as syntax.php; meaning, those additions are lost when upgrading, downgrading or reinstalling the distribution.
Ideally, a mechanism should be in place so that notes customization can be done another way, without altering distribution files.
An example strategy that I can think of would be the following:
Notes customization would be picked from the one place (or few places) users are expected to customize - userstyle.css and related files. Users do this by adding a new specification such as what follows:
.plugin_note .notecustomnote {
/* I loved <blink>, don't judge me */
text-transform: wavy, blink, matrix, rotate, etc;
}
Notes are given the base CSS class plugin_note, which contains the base styling and is provided by the plugin's style.css, and the second style which is variable and depends on what the user inputs:
<div class="plugin_note ${note_tag}"> ...
If sanitizing the note tag listings is desired, the sanitized list can be built at page load time (or, if something like a service worker is available, at service start with an optional refresh) from the following two sources (this sourcing can also be used to build a toolbar menu):
The plugin's table list as provided by syntax.php
DOM parsing of userstyle.css to check all declarations that have the class plugin_note and a class that begins with note.
Optionally, to avoid runtime building as per option 2, users can be required to register their note types in a configuration file such as DOKU_CONF/notes.txt. Since the users of the plugin itself are expected to have access to userstyle.css anyway, this should pose no problem.
As of currently (late 2020, what a year) and according to the official documentation, adding a new note type requires editing several files in the plugin:note distribution, such as
syntax.php; meaning, those additions are lost when upgrading, downgrading or reinstalling the distribution.Ideally, a mechanism should be in place so that notes customization can be done another way, without altering distribution files.
An example strategy that I can think of would be the following:
Notes customization would be picked from the one place (or few places) users are expected to customize -
userstyle.cssand related files. Users do this by adding a new specification such as what follows:Notes are given the base CSS class
plugin_note, which contains the base styling and is provided by the plugin'sstyle.css, and the second style which is variable and depends on what the user inputs:If sanitizing the note tag listings is desired, the sanitized list can be built at page load time (or, if something like a service worker is available, at service start with an optional refresh) from the following two sources (this sourcing can also be used to build a toolbar menu):
syntax.phpuserstyle.cssto check all declarations that have the classplugin_noteand a class that begins withnote.Optionally, to avoid runtime building as per option 2, users can be required to register their note types in a configuration file such as
DOKU_CONF/notes.txt. Since the users of the plugin itself are expected to have access touserstyle.cssanyway, this should pose no problem.