Right now the placeholder is treated as a single node, which the placeholder can be placed to the right of. This means that if you tap the editor, or delete the content in the editor, the cursor often ends up to the right of the placeholder, which looks all kinds of broken.

A few hacky patches were done in #16, but that's certainly not a long term fix. One use case (deleting content) isn't resolved at all, and others have FOUC flashes as the cursor is shoved back to the left.

This seems to be a regression from when ProseMirror was bundled with simpla-text, so worth exploring what's changed.

Not sure if this is possible to do in a general way, but would be nice to be able to declaratively bind to subprops on the returned instance, rather than having to programatically setup listeners using the inbuilt emitter.

Eg:

<button
    class="range__tool"
    data-format="bold"
    active$="[[editor.plugins.bold.applied]]">
    ...
</button>

Under new collection, simpla-element-authors

Since the alignment styles are written inline and the dev would have to use !important to overwrite them, they shouldn't set anything they don't absolutely have to.

Therefore, center aligned images should be:

display: block;
margin-left: auto;
margin-right: auto;

Removing all the content between two format tags should also remove the format.

Repro of where this is a problem:

• Apply a format to the text at the beginning of an article (eg: heading)
• Remove the formatted content
• Cannot remove format without entering extra content, then unformatting with toolbar.

When embedding an image it should be auto focussed so the user can align it straight away.

In simpla-article, we're focusing the editor before applying any format. Given how much this is repeating things - would it make sense to just auto focus on the editor before any format / embed is used?

This could break things if controlling it imperatively, as it will just clobber focus, even though it might be needing to format / embed imperatively outside of current live selection...I feel like this is the edge case. But it also just feels messy, it doesn't feel like embed / formats should care about where the current focus is.

It'd probably make sense to add an autoFocus prop which is set to true by default, and automatically re-focuses the editor whenever a command is made on it.

cc/ @seaneking

Right now config options are only available in the constructor, and cannot be updated after initialization. The returned editor instance needs a method to update properties after initialisation, to be used in element property observers.

Something like

this._editor.setOption('placeholder', 'Enter your text...');

Backspacing a new list item (rather than pressing enter) leaves the cursor in no mans land - no list item, but not a new line either.

Screencap:

Embedding an image should only insert a new line following the embed if there isn't already one there, otherwise inserting an image before existing content results in buggy seeming behavior.

Screencap repro:

We need to interact with injected images, either by making them top-level nodes (slotted styling) or injecting stylesheets.

Few things:

• All images should have cursor:pointer when article is editable
• Images should auto-focus when embeded
• When focussed, images should have (our own) blue outline (ie: have a focussed attr/class)
• Images should have attrs/classes for what position they have, so devs can hook in (eg: custom offsets, medium-style width overflows if positioned center, etc)

A lot of this will be the same for other configurable embeds - eg: OEmbed/videos/etc

Space characters seem to be clobbered in Firefox as you type, and it's impossible to make a space between words unless you do a bunch of backspacing and messing about.

This is live in simpla-text as well, and is badly breaking.

Screencap repro:

Pressing enter or escape when focussed on an image should blur the image/editor, more intuitive behavior.

Use-case: embed image on first (and only) line of article

Result: Can't focus on anything but the image, because no text nodes are preserved

Just wondering, since this is a pure JS lib, would it make sense to distribute as both a .min.js and a .html file, like simpla-paths?

Currently blockquotes / headings formatters aren't applicable when highlighting a list item. They should be applicable and the behaviour should be to split the list in two at the given list item, then insert a block with the contents of the highlighted list item between the two.

Currently we've got a few different stylesheets being injected by plugins e.g. placeholder styles, pre-wrap styles. Plus there're also styles that should be applied to images, which is being done over on simpla-article but in reality should be done in this behavior.

All the plugins should be able to define styles that are (conditionally) applied, and all be injected into the one stylesheet. That stylesheet should also only be applied once per root to avoid unnecessary stylesheets.

Marginally related to #15, it's impossilbe to remove the first line of an article (and its format, if it had one) if an image is embedded after it, since there's no way to place the cursor in the node immediately preceding an image, and pressing forward delete removes the image rather than the focussed line.

You can drag and drop the image onto the first line, but this isn't consistent across browsers, or intuitive.

Repro screencap:

Right now when you select an img node, it'll be overlaid with the normal blue selection box. This selection should be transparent - ProseMirror normally achieves this by getting you to include their stylesheet and setting ::selection to be transparent when selecting nodes.

Also because images are inserted inside p and in Shadow DOM v1 you can only style top level child nodes, you can't style images inside the element using richtext behavior e.g. simpla-article.

The most likely workaround will be a similar behavior to what we're doing with the placeholder plugin, where we inject style tags into the element using ProseMirror widgets. It's pretty messy, but it'll work, and ProseMirror can handle ensuring the style tag doesn't get clobbered.

Doesn't look like history plugin is working - or at least the keymappings for undo / redo aren't working, might not necessarily mean the entire history plugin is failing.

This shouldn't be a Simpla behavior, it's really just a general inline-editing richtext plugin.

@bedeoverend thoughts? Can live either in simplaio repo or your personal one IMO.

It's impossible to focus on an editor by clicking on the placeholder in Safari, you can only focus on it by clicking after the placeholder, which is both incredibly unintuitive, and for inline simpla-text impossible.

This effects production simpla-text, so is urgent and breaking

Screencap repro:

Lists currently generate the following markup

Content:

- List item

Output:

<ul>
  <li>
    <p>List item</p>
  </li>
</ul>

It should generate this markup:

<ul>
  <li>List item</li>
</ul>

This is breaking for any case where you have other content inside list items and are expecting inline content (as would be intuitively expected). Case in point: custom list bullets in ::before elements on Simpla's Privacy Policy. Using simpla-article results in a newline between the bullet and the list item content, since paragraphs are blocks by default.