the Transform API somewhat limits the ability to change state.doc attributes.Is this limited by design ?I'm using such attributes because i identify the editor container with the editor doc.
Yes, an editor or transaction modifies the content of a given document node, not the document mode itself. That's just how it's defined. Putting in a different document node requires creating a new state.
So if i get this right, i just need to extend a Step that changes doc.attrs, and add it to a transaction.
That might actually work, I think.
What we did is add one extra node below the top document node ("Article") and then add everything else inside of that. That way we can use this all for global document settings such as language and document/citation style and don't need to maintain a different system for settings ourselves.
Well, that's a good and simple solution, for sure, but i wanted to experiment with editor's doc being the document body, and i did not see how to make it work as you describe.
Is there a practical advantage to doing this (instead of just adding one level above the top level node), or is mainly due to data-puritist reasons?
hmmm it's because i'm writing a CMS where one edit the page body. It's kind of "purist" reason, but also because i don't like to introduce non-semantic stuff when aiming for semantic stuff.
Ah ok. Purism is of course fine. I just wanted to make sure I wasn't missing some practical reason for doing this.
Well it's also about consistence: everything that's part of the prosemirror model should be treated equally - the doc node included. And it is ! just not when it comes to positions.