IDEA: allow editing the placeholder in-place (like GCP docs)

[thesuperzapper]

The Google Cloud docs have an interesting placeholder implementation.
Users can click on the placeholder instances to turn them into the corresponding input box, so they can be updated in-place.

EXAMPLE PAGE: https://cloud.google.com/kubernetes-engine/docs/how-to/api-server-authentication#applications_in_other_environments

Step 1 - Default

• 

Step 2 - Click to edit

• 

Step 3 - Changes are reflected across page

• 

They also have real-time mutation, but that is not necessary.

[six-two]

Hi, thanks for the suggestion. I like the idea, since it is far more intuitive than the (sometimes pretty large) tables that are currently used to set placeholders.

I think it should be possible to implement, since the dynamic (default) placeholders already are replaced with a bit of HTML. Adding a onclick event to that, that would turn it into a textbox should thus be possible. Live-updating is also supported (without reloading the page), if only dynamic placeholders are in use.

I will see if I find some time this weekend to try to implement it (or at least a prototype to see if it would work as expected).

[thesuperzapper]

@six-two in a separate but related idea, it would be great to have the input boxes scale to the width of the current text (which will be critical for the in-place editing).

I messed around with it today and it's actually kind of painful to dynamically scale the width of <input> tags, so we might be better off using <span>.

[six-two]

Neat, I never knew you could make <span>s work similar to input fields with contentEditable. Thanks for the idea! Input elements have always been annoying, due to them looking differently across different MkDocs themes, browsers and operating systems. So it would have been a pain to make them behave like inline elements.

I hacked together a small prototype using the <span> approach. It is still missing a proper UI, validation, support for checkboxes/dropdowns, etc. But if you go to https://dev.mkdocs-placeholder-plugin.six-two.dev/demo, click on file_to_transfer.txt anywhere in the page, edit it and press Tab/Enter it should update the value everywhere on the page.

[thesuperzapper]

@six-two also, while I have you here, I see that you are often working on the actual string version of the rendered pages (when looking for the input tags to mutate with default values).

Rather than trying to build your own XML parser, it's actually possible to hook into the Python markdown library (which mkdocs uses) with a tree processor extension that can work on the XML tree object rather than as a string after it's rendered

For example, I made this hook/plugin which finds <a> tags, and makes them open in a new tab, if they are external to the website:

• https://github.com/deployKF/website/blob/main/hooks/external_links_md_extension.py

[six-two]

Thanks for the tip! That might also be useful some of my other extensions (like mkdocs-badges) where I remember implementing some custom markdown parsing to see whether I am in a table or code listing

[thesuperzapper]

The only thing to remember, is that when you use a markdown extension, it will only affect the actual content from .md files, not the Jinja theme templates.

But at least for the placeholder plug-in I think that's fine, because I don't know why you would want placeholders outside of the main content.

[thesuperzapper]

Three more ideas:

• have a "revert to default" button when you are clicking on an inline text entry field
• put some indication that the in-place placeholder is editable and clickable (like on the GCP page)
• consider adding autocomplete="off" if we still use tags like <input> (I don't think browsers will autofill <span>) so that changes are reverted when the user refreshes their page (or at least have an option on a per-placeholder basis)

[six-two]

Regarding the three ideas:

1. A button would be hard to inject (while keeping the layout simple). Maybe a small span with an revert arrow when editing the placeholder. The idea I had is to show a tooltip below the field being edited. It could contain the placeholder's description and the default value. A user could just retype the default value or use the (somewhat hidden) reset all placeholders function from a placeholder table's settings. Another option would be a key binding, but that is not easily discoverable.
2. UI for the function is still missing. I would add a special class to them, so that users can overwrite the style and some optional default styling when I have some time.
3. Does your browser try to autocomplete any of the inputs? Would be a bit strange, since I do not recall setting 'id' or 'name' for them and they are not in a ''. So my understanding is, that the browser likely will not offer autocomplete based on this page. Placeholder values being stored is an intentional feature, so that you can change them on one page and they will remain with that value and also have it on other pages. If you do not like it, you could include a small script that (selectively) clears the localStorage entries for placeholders when a page is (re)loaded.

[six-two]

@thesuperzapper I have implemented the UI features (tooltip, special styling, etc) and support for dropdown/checkbox placeholders. Is there anything (except a revert button) missing related to the inline placeholder editors or are there any obvious bugs? The only thing I noticed is tooltips not being shown on my smartphone, but that is more of a general issue with touch devices not having mouse pointers.

The latest version is deployed at https://dev.mkdocs-placeholder-plugin.six-two.dev/demo and pushed to the main branch. If there is nothing broken/missing, I would like to release v0.4.2 with this new feature in a couple days.

[thesuperzapper]

@six-two A few things:

• the input boxes in the table now glitchy resize (get smaller) when you first edit them
• there should be a minimum width for the in-line placeholder (otherwise it could be very difficult to input a new value)
• I quite like what GCP did to indicate the in-line editable fields:
  • they put a small fixed-width icon which swaps between a "pen" and an "x" depending on if the input is selected (a "revert" button is probably more useful than "x", and it gives us a good place to put it)
  • they put a dotted underline (to show the boundary of each input field, which is important if they're beside each other)
  • they italicized the editable text
  • https://cloud.google.com/kubernetes-engine/docs/how-to/api-server-authentication#applications_in_other_environments
• in-line editable placeholders should be opt-in so that not all instances of placeholders become editable:
  • you already have the concept of dPLACEHOLDERd, perhaps something like ePLACEHOLDERe for editable ones
  • this also lets us do the underline (and put the edit icon), because it won't affect existing placeholders
• I don't think "toggling" is the best implementation for "drop-down" and "check box" placeholders:
  • it's possible to accidentally click, and not be able to revert it (which might be a problem if it's a command template)
  • having a drop down sector, even for the in-line, is important
  • and I'm not sure that we should have in-line editing for check boxes

[six-two]

@thesuperzapper Thanks for the feedback. Regarding the points you raised:

the input boxes in the table now glitchy resize (get smaller) when you first edit them

I do not see this behavior with Firefox on Linux on my test site. To help me reproduce and fix it: What browser/OS and URL did you encounter this on? Can you maybe send a screencapture?

there should be a minimum width for the in-line placeholder (otherwise it could be very difficult to input a new value)

Implemented: for now it is a pink square with the width of the letter m, but you can apply custom styles with a selector like .placeholder-value-editable:empty

I quite like what GCP did to indicate the in-line editable fields:

• they put a small fixed-width icon which swaps between a "pen" and an "x" depending on if the input is selected (a "revert" button is probably more useful than "x", and it gives us a good place to put it)
• they put a dotted underline (to show the boundary of each input field, which is important if they're beside each other)
• they italicized the editable text

• Adding an icon (image) inline will likely be hard. Different themes and contexts may have different font-sizes, etc. And if I use an Unicode character (which would get around the above issues), I am afraid that it may be included when the user presses the copy listing button.
• I do not want to go too aggressive on the styling by default, but I see the point. That is one of the reasons why I show an underline when you hover over the placeholder. This shows exactly where the placeholder is and what it's value is before you click it. Again, custom styling is possible.
• I also colored and italicized the text 😉

in-line editable placeholders should be opt-in so that not all instances of placeholders become editable:

• you already have the concept of dPLACEHOLDERd, perhaps something like ePLACEHOLDERe for editable ones
• this also lets us do the underline (and put the edit icon), because it won't affect existing placeholders

Good point, I will think about it. Although I would probably implement it as a opt-out by default (by mapping xPLACEHOLDERx to ePLACEHOLDERe and giving an option to revert to the old behavior).

I don't think "toggling" is the best implementation for "drop-down" and "check box" placeholders:

• it's possible to accidentally click, and not be able to revert it (which might be a problem if it's a command template)
• having a drop down sector, even for the in-line, is important
• and I'm not sure that we should have in-line editing for check boxes

I tried to implement it with an inline dropdown that shown up when the user hovers or clicks on the placeholder, but that was both very buggy. For example when selecting a value in the onmouseenter implementation the user would leave the placeholder and thus cancel the dropdown. Now with the "empty placeholders can not be edited anymore" issue fixed, I do not quite understand the "accidentally click, and not be able to revert it" reasoning. For a checkbox just click it again. For a dropdown just right click it once or left-click till it has the old value.

One of the advantages I see with inline editors is that we do not need to rely on placeholder tables anymore. While they work OK on small to medium sized pages, they become way to big on very large pages, where it is a real pain having to scroll to them, find the correct placeholder and scroll down to your place again. Thus I would like to have all placeholders support inline editors. And if a site owner really dislikes the behavior, they could selectively disable the inline editors for these placeholders (dCHECKBOX_PLACEHOLDERd).

[six-two]

This week I made some changes to the code:

1. I changed the styling a bit. It turns out that (at least with Firefox/Chromium on Linux) contents of pseudo elements are not copied. So I can show an Unicode icon after each inline editor without for example breaking the copy function in code listings. There are two styles with the developer (inline_editor_icons in placeholder YAML) being able to choose the default and the user (Use icons and other styling to highlight inline editors in settings) being able to overwrite it.
2. Inline editors for checkboxes and dropdowns can now be manipulated using the keyboard: Tab to select one and Enter to change its value.
3. I added the ePLACEHOLDERe syntax and mapped xPLACEHOLDERx to it by default.

@thesuperzapper Do you see any more glitches, bugs or problems with the code in the current state? Do you have details for reproducing the "the input boxes in the table now glitchy resize (get smaller) when you first edit them" bug?

[thesuperzapper]

@six-two I can't seem to reproduce the glitchy size error, so it might have been fixed with your other updates.

Based on your demo my main comments are now about styling:

High Priority

1. Currently, I can't select only part of a code block by dragging my mouse:
   • (This is especially bad when you drag from the right hand side)
   • It seems like my mouse passing over the input boxes makes it open the edit box.
   • It's critical that we only open the edit box when a user explicitly clicks on the editable section.
   • I am not sure if its necessary to fix this, but the GCP docs actually don't seem to use contenteditable, but they swap and open an <input> tag on click.
   • Maybe we need to do that, or just only set contenteditable on click?
2. Dont use emojis, they are not consistently represented across devices (and are really bad for accessibility):
   • I recommend we use material design SVG icons:
     • Edit can be: https://pictogrammers.com/library/mdi/icon/pencil/
     • Swap enum can be: https://pictogrammers.com/library/mdi/icon/swap-horizontal/
     • Boolean can be:
       • False: https://pictogrammers.com/library/mdi/icon/checkbox-blank-outline/
       • True: https://pictogrammers.com/library/mdi/icon/checkbox-outline/
3. I am not sure a background color is the best way to highlight the input boxes:
   • It disrupts the flow of the page and theme
   • I like how GCP does a color + dotted underline: , and only shows a background box when the editing box is open:
4. We should stop the browser from doing strange things and set:
   • spellcheck="false"
   • translate="no"

Medium Priority

1. For the currently active edit box:
   • We could swap the "edit" icon for a "revert to default" button:
     • Icon: https://pictogrammers.com/library/mdi/icon/undo-variant/
   • Or we could at least swap the "edit" icon for a "close" icon to indicate which ones is currently open:
     • Icon: https://pictogrammers.com/library/mdi/icon/close/
2. We should still update the other instances of a template (even if it fails validation):
   • Otherwise its hard to know which ones are connected

[six-two]

Hi, it ha been a while, but I had a lot of private stuff to do. In response to the issues you raised:

• High 1: Should be fixed. But if you start selecting text over a text input you will edit it instead (and can only select within its bounds). I think this is a reasonable restriction, since you just can start somewhere else and end over the text box. Unless your selection starts and ends in the middle of text fields, but that is an edge case I am willing to accept.
• High 2: Fair point, I will try to switch from Unicode to SVG. I am just not sure how easy or hard it is to implement.
• High 3: Working on it
• High 4: Should be fixed
• Medium 1: The problem is: I can add an onclick event listener and it checks that you clicked in the icon. But checking whether you had this element focused before was not trivial. I played with something like that and it never worked as expected. Swapping the icon for a close button would be easy, but if it should actually remove the focus from the element, we run into the same issue.
• Medium 2: I disagree. If something fails validation (an error, not a warning) it should not be inserted anywhere. It could produce issues. Imagine you enter a space into an element that is inserted (unquoted) into a bash command (like sudo rm -rf xPATHx). It would change the meaning of the command with potentially dangerous consequences (example: sudo rm -rf /home/someuser /bin instead of sudo rm -rf /home/someuser/bin). I only show the new, invalid value in the textbox (instead of reverting to the last valid one) to give the user the chance to fix their input without loosing all their progress and frustrating them

[six-two]

@thesuperzapper

• High 2: Thanks for the icon links, I have replaced the emojis with inline versions (data URLs) of the icons.
• High 3: I stopped using background color and just indicate the inline editor state with border styling (is editor -> dotted underline, is hovered over -> solid underline, is focused -> full border on all sites). The focused mode looks different on Chromium, but it should be fine.

I noticed that Should be fixed is ambiguous. I actually meant that High 1 + 4 are fixed, but I only tested them myself a little (so they might not be fixed "right"). Given the current state, do you think the feature is ready to release or are there still some things that need to be fixed?

[thesuperzapper]

@six-two it's looking really great, it will be a seriously cool addition to the world of MKDocs!

I have a few more notes (assuming this demo is the latest version):

1. I think we should use a different color than "blue" by default, it is really hard to read in dark mode
2. We should apply vertical-align: text-top; to the icons, so they sit within the line properly
3. When you click on an edit box, the border seems to jut out around the edit icon (for boxes that sit outside code block)
   • this is probably caused by the icon not being in its own span
   • 
4. We should make the color of the icons the same as the text (e.g. blue/yellow/red rather than black)
5. We should size the icons the same (so the edit, swap, and checkbox occupy similar sizes)
   • this could be complicated, it might be necessary to put the icon in its own span

[frimik]

The beauty with inline edit is; there's no need for an automatic input table anymore. You can design your own input table or "overview" of all the values in markdown any way any style you like.

[six-two]

@thesuperzapper Nice, sooks like we are mostly past the functional bugs. Thanks for your testing. Yes, the site you reference is built with Vercel every time I push a commit, so it should reflect the latest changes. Regarding the new issues:

1. I changed it to green (looks ok with dark Material theme) and documented how users can overwrite it.
2. The property did not fix it. For reference my current styling is the following (see src/mkdocs_placeholder_plugin/generic/generic_style.py for the full styling):

   .placeholder-value-any .inline-editor-icon-span {
       display: none;
       width: 1em;
       height: 1em;
       margin: 0px 3px;
       vertical-align: text-top;
       fill: var(--inline-editor-color);
   }

3. I removed the default styling that the browser adds for highlighted elements. It was very different accros browsers. Is it now fixed? If not, what browser and operating system does the glitch appear with? I do not see it on MacOS with Chrome, Firefox or Safari.
4. Required a good bit of rewriting, since it did not work with my :after element trick. Now actual inline SVGs are used. These changes probably introduced some new bugs (visual or functional).
5. Currently all icons have a width of 1em (so they are as wide as the letter m in the current font, see also point 2). So the issue seems to be with the image files. The icons may look differently sized, but the actual images are the same size (13.6px for me).

[thesuperzapper]

@six-two ok, its looks much better now, but there are a few new bugs:

1. You can actually delete the icon with backspace, and even put content after the icon, lol. You need to move the icon outside the content editable span.

   • 

2. The input boxes no longer correctly wrap if they contain a long string with no spaces (outside code blocks which don't wrap by design). You need to allow breaking words in the middle when overflowing.

   • 

[six-two]

@thesuperzapper

1. Are you by any chance using Firefox? I tested it with a bunch of different browsers (Firefox, Safari, Edge/Chrome/Chromium) and operating systems. So far it only seems to happen with Firefox and only with inline editors, that are not in a code listing. It might be an upstream bug, I will investigate/try to fix/work around it.
2. Fixed

[six-two]

Update for 1: I tried to fix it properly (by adding a span around the text the user edits), but it broke too many things. Instead I added a function after every input event, that ensures that the icon is still there and that there is no text behind it. It should prevent the issue you described. I also just checked on my phone and it also highlights/selects the icon too, but my "fix" seems to work there too. Can you confirm that it is fixed?

[thesuperzapper]

@six-two for context, my primary browser is Brave (which is chromium).

Regarding your fix for 1, it seems to have a strange effect on Safari, which is that hitting backspace on an empty input field scrolls the page back to the top. Separately, double clicking on the content of an open editor (trying to select the full text) actually selects the entire page text (but this is less serious).

Are you sure you can't arrange the spans differently so the content-editable only affects the part before the icon?

Currently you have:

<span contenteditable="plaintext-only">
  text for this input
  <span>
    <svg></svg>
  </span>
</span>

Can't you do something like:

<div> // with `display: inline-flex` or `display: inline-block`
  <span contenteditable="plaintext-only">
    text for this input
  <span>
    <svg></svg>
  </span>
</div>

[frimik]

This is purely a "looks" comment, which may be further down the line for you while trying to fix functionality...

I've started using this in an experimental site (smallish doc/project-suggestion collection project... so it's perfect for driving an initial template generation).

I'm actually slightly in favour of a de-cluttering option which would only render the edit-ability in either a specifically marked block, or by default on the first templated element. Possibly even not rendering any special color on the other parts of the document... not quite sure.

But regardless, the way you can already now design your very own "input table" makes things work well. And the version I was testing now, where the pen icon hides worked very fine.

Ideally the text doesn't change color but instead there's a slight background shade difference.. tough to do reliably perhaps.

Either way. Love it so far!

I was leaning towards something as simple or subtle as this in the flowing text at least:

    cursor: text;
    /* color: var(--inline-editor-color); */
    /* border-color: var(--inline-editor-color); */
    /* font-style: italic; */
    outline: none;
    word-wrap: break-word;
    background-color: #e6f7ff;

I also tried to default to a black with alpha rgba(0, 0, 0, 0.1), it was also fine. Blue is "soothing" and subtle... but of course might not work in all cases depending on surrounding themes.

[six-two]

@frimik Thanks for your comment.

I believe I already tried to do the highlighting via background color, but it had some disadvantages (like bad contrast, etc). It also has to work with light and dark themes, so that makes it even harder. Personally I think the current look is fine as a default, but of course you are always free to customise the styling. Maybe I could add an official theming support in the future (and include multiple themes that the user can choose without having to manually write/include CSS), but that is a topic for another issue.

---

I'm actually slightly in favour of a de-cluttering option which would only render the edit-ability in either a specifically marked block, or by default on the first templated element. Possibly even not rendering any special color on the other parts of the document... not quite sure.

Personally I would not include it into the plugin because:

1. It introduces more complexity (the code is already too complex for my taste).
2. It might confuse users: Can they only edit the first one or any one in the page?
3. You should be able to do it already with the current code base. If you just want the first/a specific placeholder inline-editable mark it with ePLACEHOLDERe and all other instances with dPLACEHOLDERd. If you want all inline-editable but only one styled, you can write a small JavaScript snippet that adds a special class to the first editor for any placeholder (or any editors within a specific block) in the site. Then you can use custom styling to differentiate the first placeholder and all other placeholders.

[six-two]

@thesuperzapper Yeah, Safari has weird behaviours. It selects the whole page when you select the SVG. I already fixed a bug where it highlighted the entire page when clicking a placeholder, by only selecting the text node, not the SVG when you start editing it.

I tried to change the layout of inline-editors to the following, before coming up with the work-arounds:

<span class="placeholder-value-editable">
  <span class="text-editor" contenteditable="true">text for this input</span>
  <span class="inline-editor-icon-span">
    <svg>...</svg>
  </span>
</span>

The issue is, that all my code (like value validator, event handlers, etc) expects to just read/set the value of the first text node. Changing it to use the .text-editor span as a value, but assigning new dynamic classes to the . placeholder-value-editable attribute requires a lot of changes and added complexity, but would probably fix the issue. When I tried that (before the work-arounds) it broke placeholders in a way that they were not editable and I had no clue why. I will try to avoid that work by seeing if I can use the old :after trick when editing an element (similar to how it was a few commits back). If that does not work, I will try again to do it the "propper" way.

PS: plaintext-only causes an exception in Firefox, since it is not supported. There are so many little browser engine quirks that this feature runs into 😓

[six-two]

Ah, the :after has the color issue, so it will not respect the variables like --inline-editor-color. But I have been thinking: Do we even need to show an icon when the user is editing a field? I get why we show it when the user hovers over it (to show it is editable and what type it is) or, if enabled, for all placeholders (to show they are editable). But when the element is already is selected all the text gets highlighted and the border makes it look a bit to an input field. Plus you get the input element cursor. Maybe that is enough information for the user to know that they are now editing that placeholder?

@frimik @thesuperzapper What are your thoughts on that? The latest deployment (https://dev.mkdocs-placeholder-plugin.six-two.dev/demo/) has the icon hidden when editing a placeholder, if you want to try it out. If it is OK from a UX perspective, it should work around most of the bugs that were recently brought up.

[thesuperzapper]

@six-two the problem with hiding the icon is that it causes the page content to jump around because the content changes width. We should try and keep the edit mode the same width as the non-edit mode.

Also, regarding the complexity of contenteditable, this is probably why the google docs creates an <input> tag with the value property set to the current <span> (or in their case <var>) when the user clicks on an editable field.

Every keypress then updates the corresponding <span> content, and then the <input> tag is removed when the user clicks off.

[frimik]

@frimik @thesuperzapper What are your thoughts on that? ... the icon hidden when editing a placeholder

Everyone has their style..

• Icon hiding on edit is good.
• I prefer no icon at all, or only on hover. It clutters the actual document I'm trying to "provide" to the user too much.

I think having that option to highlight in orange is a great compromise, if it's a toggle that's even better.
To me, the best style is a decent background shade, or even a strong one in case that's required to add a functional default.
Or outline: dashed rgb(0 0 0 / 15%);

Mainly: No icon, but as long as I can actually control the style myself anything goes and I understand your focus on a default that works for all audiences, especially considering high contrast needs.

Hope that makes sense?

[six-two]

@thesuperzapper It only makes the content jump around when showing the icon by default or if you hover over the text before. If you use the simple style (icons on hover only) and tab into the editor, it should not change. With the simple style on touch devices (phone/tablet) it might even provide a better experience if I fix the flickering in and out of the icon. And personally I would ship the simple style as the default.

@frimik I will try to add a third style that has no highlighting or icon and only does minimal changes like the cursor. That should make custom styles easier, since you no longer have to unset all the values I set. Then it should only be a couple lines of CSS to have things like a different background or an outline.

[six-two]

@thesuperzapper I changed the behavior to minimize resizing. If you are using the icons style the icon (via :after) will be shown. Due to the restrictions I can not dynamically color it, so it is always green (even if the validator gives a warning / error). With the simple style it will be hidden, so tabbing into an editor will not change layout much, but hovering over and clicking it will first show the icon and then hide it again.

@frimik There is now a custom style that should allow you to create your own style from scratch. If you use it as documented here it should be able to co-exist with the builtin icons and simple styles, so users can select the style they prefer.

[thesuperzapper]

@six-two on your demo the icon now jumps upwards when you open the editor (which it didn't do a few times ago).

Also, a few commits ago there was no size change (when opening the edit box), but now I think the padding on the icon is causing it to change.

Also, if you plan to give an option which disables the edit icon (when the input is open), please make sure it's an option. I also think that keeping the icon visible should be the defualt.

[six-two]

@thesuperzapper The size should now stay the same when editing. There is still a small inconsistency with the icon jumping up and down a few pixels. But I think it is good enough to release, given that that is the non-default style.

Also, if you plan to give an option which disables the edit icon (when the input is open), please make sure it's an option. I also think that keeping the icon visible should be the defualt.

The simple style only shows the icon when hovering an placeholder with the mouse (and if it is not focused). The icons style always shows it. I am not sure, whether a clone of the simple style that shows the icon when editing a value would be much used.

Personally I hope that after the 0.5.0 release someone with some UI/UX experience writes some nicer styles for placeholders. Then we could bundle them with future versions of the plugin. The current styles with the border have some disadvantages like the border changing the width of an element, when it is focused.

Honestly, the whole styling code could use a rewrite in the future. It would be much nicer, if it was modularized into small CSS files that individual themes can pick and choose from, rather than having one huge string in some python file. But that is a TODO for future me and not relevant for this release.

Are there any functional bugs or major UI glitches, or can I prepare the code for release?

[thesuperzapper]

@six-two where can I look at a demo of the other styles?

Also, a few commits ago it did not change width or move the icon at all, what changed?

[six-two]

@thesuperzapper What changed is that I use inline SVGs instead of the :after pseudo-element, since it has some issues and is really hard to debug. Switching between the SVG (normal/hover) and :after (editing) causes leads to some slightly different styling. :after is used when editing, since it works around the ton of functional issues you found with the SVG implementation.

To change the style in the demo, click the gear icon in the placeholder table and switch the dropdown from icons to simple. custom also exists, but applies no styling, as it is for people who want to create their own style.

[frimik]

Works great. Although I of course use the custom option and add very very little style on top. 👍

[six-two]

Thank you both for your feedback and your time!

Version 0.5.0 is now live. If there are any more noteworthy issues with this feature, please open a new issue (this one forces me to scroll too much 😉).