The (for me) unexpected success of the new tables module, which I wrote for Atlassian and which they are now maintaining as an MIT-licensed module, has convinced me that this style of tables are the future, and my initial attempt, prosemirror-schema-table is a dead end.
Specifically, the initial module used schema constraints to enforce table shape (each row having the same number of cells). This is in principle a good idea – when you can encode constraints in your schema, you make sure that they are always enforced, and you never get documents that violate them. But in this case, it does have downsides — I had to add a bunch of extra, rather ad-hoc features to schema content expressions to support it, such nodes are a pain to work with (you often have to know the width of the table at points where it is tricky to do so), and it doesn’t generalize to tables that support rowspan/colspan (merged cells).
So the approach in the new module, where row- and column-spanning cells were a requirement, is to define a much simpler schema, which only says that table cells go in rows and rows in tables, and to enforce table shape constraints in the appendTransaction method of a table-editing plugin. This means that the document may, for some editing operations, end up with non-rectangular tables at the end of a transaction, but another transaction fixing that will be appended right away, before the content is even drawn to the screen. So if you had code that crashes when looking at a non-square table, that might be a problem, but in practice that doesn’t seem to really come up.
The new module thus support row- and column-spanning, along with cell selections (implemented using the extensible selection feature added a few months ago), providing a much better table editing experience.
Which leads me to think that no one really needs the old table module anymore, since there’s a much improved alternative available. So I plan to stop updating it.
That, in turn, means that it is possible that no one would be using the attribute-based content constraints anymore, since as a feature I don’t think they are much use for anything except that cell-count hack. So I would really like to drop that feature, making the constraint-enforcing code a little simpler and faster. Since that’s a relatively invasive change, it’d be something that would need to happen before 1.0.
Is anyone using attribute-based content constraints (the syntax where you refer to attributes by prefixing them with a dot in a content expression, or use [] syntax to constrain attributes themselves)? And if so, are you using it in a way that couldn’t be replaced by splitting your attribute-carrying node type into multiple types?
