bastianallgeier / triptrap Goto Github PK

This field is likely to be used for stuff like blog posts. There, you'd want to have one <h1> (which is the title field) and perhaps a subtitle (which might be a subtitle field). This is just good SEO and is how Medium works. This means that in your content, you'll mainly have <h3> and up (again, how Medium works as well). This is also an argument for #8.

My argument is that in the editor, you'll likely be writing ### and #### most of the time, which can get annoying. My proposal is to be able to configure a "heading offset" that specifies the starting heading index.

For example, the default heading offset could be 0, which means:

• # == <h1>
• ## == <h2>
• and so on...

However, if you set headingOffset: 2, you get:

• # == <h3>
• ## == <h4>
• and so on...

This is useful for two reasons:

1. You get a better writing experience since you won't be counting hash symbols.
2. If at some point you wish to change the heading hierarchy, you just change the heading offset. For example, if I had headingOffset set to 2 and I want all <h3> to turn into <h2> (and all others to be adjusted accordingly), I would simply reduce headingOffset by 1. I wouldn't have to change the content at all.

In Safari 12.1.1 (14607.2.6.1.1), spellcheck doesn't occur while typing in the field. I would expect to see red underlines for incorrect words. The standard textarea field works fine for this.

Currently, the editor supports just <h1>-<h3>. You can't output the smaller tags even by writing ####, so this is not a just problem with the UI. It should support all six tags so content can be organized more freely.

If I have the following content:

Sample text: (image: quote.png caption: Caption lorem ipsum dolor sit amet)

...I get the following markup:

<p>Sample text: (image: quote.png caption: Caption lorem ipsum dolor sit amet)</p>

That's expected. But when the text is parsed with kirbytext(), the created <figure> tag is put within the <p> tag, which is not valid.

The obvious solution is to save it like that:

Sample text:
(image: quote.png caption: Caption lorem ipsum dolor sit amet)

...which turns into:

<p>Sample text:</p>
<p>(image: quote.png caption: Caption lorem ipsum dolor sit amet)</p>

...and you have the same problem. I don't know how this may be solved efficiently, though. I guess:

• Kirbytags can be turned into ProseMirror nodes, as I mentioned in #2, which is the best approach, but involves more work
• The final HTML could be parsed and <p> tags that surround kirbytags should be removed, which I don't think is easily possible and is actually a pretty bad idea, so it's not really a solution

The reason this is such a problem is because the browser can't handle block elements inside a <p> tag since the HTML spec does not allow it. Because of that, markup like:

<p>foo <div>bar</div> baz</p>

...is turned by the browser into:

<p>foo </p><div>bar</div> baz<p></p>

...which is bad. You expect one <p> tag and you get two, one of which is empty.

You could add kirbytag support by serializing tags to XML before saving them.

(image: quote.png caption: Caption lorem ipsum dolor sit amet)

to

<kirby image="quote.png" caption="Caption lorem ipsum dolor sit amet"/>

I use that in kirby-exporter and it has worked flawlessly so far. It uses a lot of native Kirby functionality too.

Then, you could configure tiptap's toDOM() method to parse <kriby> tags. You'd have a custom Vue component to handle them - and that's it.

As for the UI, you could add a dropdown similar to those for headings - except it contains all possible kirbytags. Or perhaps those that are allowed in the field's blueprint.

Edit: On second thoughts, tiptap should be able to save Kirbytags as XML tags by itself, as long as you correctly define the parse rules. Then, the only problem would be to convert those tags from XML to the actual HTML output that each tag has in a template. That could be accomplished by:

1. Parse the field's HTML containing XML kirbytags
2. After obtaining each tag's properties, generate its output
3. Replace the initial XML tag with the generated markup
4. Return the processed field HTML

this is solved?

• JSON to kirbytext: converted on server
• kirbytext to JSON: is this necessary or are you passing it generated html or something else?

Like you said on slack, parcel is including the vue runtime in the bundle. Actually, it seems like parcel has no other choice.

tiptap explicitly imports Vue here: https://github.com/scrumpy/tiptap/blob/master/packages/tiptap/src/Utils/ComponentView.js

I see 4 options and none of them is without drawbacks:

1. We nag ( 😉 ) @scrumpy until he removes the dependency: Vue is imported only in that file, maybe there's a workaround
2. We do nothing: out of the 397KB bundle, the vue runtime is 97KB: "only" about 25%
3. The editor becomes a core feature (this would still add like 300KB to the panel)
4. Theoretically, parcel could "alias" the "vue" module to any js file. That js file could be something like

   export default panel.Vue;

   (this requires Kirby's Vue instance to be exposed ofc)