I propose changing
prosemirror-view to use the provided
place element as its content element instead of creating a new div under it.
- Can remove a few arguments from the constructor that can now be handled outside of the editor:
- label (aria-labels)
- Allows angular & vueJS & other view libraries to setup behaviors on the content div itself
<div class='editor' ng-show="editing">
- Users can still create an extra wrapper if they want.
Cons: There are no cons
We’re assigning classes to this element ourselves, so we do need control over its class. I can kind of see how this is attractive, but it doesn’t play well with the current design.
I don’t think that prevents this. You could
content.classList.push("foo") to add and then a combo of
splice to remove. So instead of setting
class, add and remove the ProseMirror specific ones.
That’d leave you with multiple sources of truth for what the classlist for that node should be (mutations by the code that ‘owns’ the node + ProseMirror’s classes) which would be bad. Allowing plugins to conditionally add classes is really practical, so I’d like to keep that.
Hmmm, that’s definitely a valid point. Trying to decide if plugins will also present the issue of clashing ownership of classes. I think they can run into the same issue (two plugins adding/removing same classnames). It’s definitely heightened a bit by having the div owned outside of ProseMirror but I don’t think that it would be a major issue. Probably best to leave it as is and wait and see if more cases present themselves.
This patch introduces an
attributes prop which can be used to control arbitrary attributes on the outer node.