great discussion, thank you for the feedback and reasoning
Absolutely, starting this was more to hash that out then anything else really. While I work in HAX land, my intention wasn’t to suggest “make this your default editor” it was more as you suggest in the plugin ecosystem. If there’s a place for HAX in the ClassicPress ecosystem where we work on HAX to passively support the use-case you suggest (needs to work with Tiny, needs to work with older stuff, needs to work before and after HAX is enabled).
This was intended less of a “ADOPT HAX OR DIE” (that’s the slant for Drupal ) and more that our mindsets of “hey I have a lot of stuff I made before and you can’t break all that compatibility over night without pissing me off” which could help provide a place for ideas to bounce back and forth.
It could also be that when people eventually say “but I kinda want to play with a block editor” that if we can get HAX to a point where people in this community feel it’s a viable enhancement to ClassicPress because it’s philosophically aligned, to do so (organically, not as like some edict).
To your questions (the above is addressing the 1st one)…
The current plugin’s integration requires TinyMCE… as it then jumps in and hollows it out and replaces the body blob of contents of Tiny as the starting point for HAX’s editor. It’s similar integration to how Tiny injects it’s JS and hijacks what otherwise would be a bland textarea input.
I’m not sure how it translates complex post over to HAX, should render, it’s just presenting HTML after all. If the DOM of that tiny area is deeper then 2 levels of hierarchy it won’t break HAX just many conventions in it won’t recognize it to do anything meaningful. HAX is a “block” editor but without rigidly defined BS react blocks. our “Blocks” are normal paragraph tags, divs, iframes, and yes custom elements / web components.
HAX doesn’t have a concept of fields, though if you’ve played with any of the demos you might be referencing the edit form for a video or any other web component. HAX is reading JSON Schema dynamically off of the web component and building a form which is saving the data by writing HTML in the page that matches the properties, attributes, and slotted (inner HTML that’s tagged) areas. By doing this, you can get highly structured content in concept yet in the DOM it’s still a single or handful of tags being placed in the page with properties filled out in the tag. Complex (array / object) data is json encoded and stored w/ the element though we only have a few elements that operate this way and largely don’t recommend it unless it’s absolutely necessary (image gallery, tab list, play list of media as possible examples).
Again, not trying to coopt nor would I want HAX to be the default editor of an ecosystem (I’ve got 6 ecosystems I’m playing in at the same time + 2 of my own platform I’m building that it’ll be the default in). But, given the philosophical alignment we have in our projects if there’s any room for people in this community to try HAX inside of ClassicPress (via plugin) and offer feedback on how we can make it work better with TinyMCE to augment when needed, or provide an alternative perspective, it’s something that I think could help both projects.
My community wants to simplify the transition from old to new world editors instead of just flipping people the bird so feedback in how we can make the more possible is invaluable to us. Also, long term, the Gutenberg question from clients of having website tonight software and “why dont I just use Wix” will keep being a nagging issue and maybe, if it becomes a viable solution to people, HAX can be one of those options without people going back to Gutenberg which will not adopt our vision of the future.