@james is our lead dev so I’m tagging him here — thanks for opening this discussion!
3 Likes
not a huge MD fan either because of design limitations, just meant in concept. A lot of ppl claim to enjoy MD based solutions because of the pure writing form (went to a humanities conference where non-technical ppl are teaching each other markdown for this reason).
Yes, I know the sort of people you mean!
I like LyX because it gives me the power of LaTeX without having to learn LaTeX. It’s like being able to type in the WP/CP editor and then letting the theme make it all look good.
Yes, this is the way it should work. I don’t trust a lot of users with page builders / block editors. They end up changing the look and feel of the site. They are good for certain things, but not for general post writing.
I do like markdown. To me the biggest distraction is using the mouse. With markdown I can set headings, bold, and italics from the keyboard without breaking my rhythm.
1 Like
Might be worthwhile creating a plugin for ClassicPress as (a) proof concept and (b) for community testing.
Once tried and tested the community can vote on retaining it as a plugin or request for it to be merged into CP core
Might gain traction as a plugin since the community is advocating for a leaner bloat less core code
5 Likes
Everything has purpose for people that need it, and it doesn’t for people that don’t.
Markdown isn’t for writers, it’s for developers. You can’t bold or italicize when writing in console, so you use markdown.
Even Gutenberg has its purpose, as ugly as it is. It helps WordPress.com compete against website builders and against page builder plugins. At least that’s what I think, why Gutenberg was pushed down our throats.
Many bloggers (most?) hate Gutenberg because it completely changed UI/UX making it harder to simply write. Now they have to build a blog post, not just write it. This is akin to UK switching to driving on the right side of the road. Or US using metric system.
People are used to writing using TinyMCE because many text editors - online and desktop - conditioned users to this type of UI/UX to write. MS Word, Open Office, Google Docs, etc.
One thing to consider, since CP is business focused, business customers might expect to see TinyMCE because that’s what they used to and that’s what they use internally. This is just a thought, I don’t know if it’s valid or not.
And HAX, it’s quiet an annoying text editor. That toolbar always visible as you write right above is very distracting and it visually forces you into blocks. Having a border around paragraphs. The UI/UX is not intuitive, it’s asking me to waste time trying to figure it out. We’d be back with our own Gutenberg fiasco.
This was discussed before, and to quote James:
I wouldn’t replace TinyMCE in the core, but making it easier to allow a plugin to replace it if needed could definitely be something worth exploring.
9 Likes
But that is surely just a criticism of this forum software which does seem a bit confusing and clunky.
There are other forum softwares (e.g. Xenforo) that are a lot better (IMO), more intuitive to understand.
As I see it though, the old WP editor was very good. Surely it would have been possible to integrate some blocks into it for those people who wanted blocks, but could be ignored by those who just wanted to write.
For example, inserting an image with a caption is a block as far as I can see. You admit, edit the alignment and size it floats on the page how you want.
Something similar but a text box would be ideal, something like you might at in MS Word or Mac pages for a floating text box.
But this may be what so many people are bashing WP for on the forums, making Gutenberg the cor default not something as an option for those who want it.
The forum text area (which is fine for this type of conversation) was an entry point to the authoring experience setup 
.
I believe this is the case too (as an outsider). I can’t believe they replaced Tiny as core editor and have said they are deprecating that. I’m obviously building something that at least will draw comparisons and I’d never force that option on anyone without having Tiny / a baseline editor for fallback among my own user base. Now, if there was like Gutenberg: a WP Production and it was default there… I think there would be less headaches for all
Hi @btopro, thanks for starting this thread. It’s clear already that different people want very different things out of an editor.
I like Markdown, personally. Though I think it depends somewhat on what you are trying to do. Most of what I write is text with lists and links.
If I were making more image-heavy landing pages, I’d probably want something that knows how to deal with components or blocks.
Ok, I suppose now is as good a time as any to unpack this quote a bit
We’ll definitely keep TinyMCE for our initial long-term-support release series, v1.x. The goal there is to provide a stable, predictable option for people to build websites on, and what better platform than the classic editor with TinyMCE? This is stable, proven technology that has been used for millions of sites and billions of conent edits.
Which editor ClassicPress uses by default in future versions is up to the committee. We’ve already set the direction for the v2 release series, which is around building a ClassicPress plugin directory and moving some less-used features of the core software out into plugins.
Having our own plugin directory will also allow us to provide and recommend plugins like an alternative editing experience. This would be opt-in by default, and I could definitely see HAX fitting into that kind of role in the ClassicPress ecosystem.
In order to change from TinyMCE to another default editor in a future version of ClassicPress, we’d have to get lots of testing via a plugin, and wide agreement among the community that this is a change we want to make.
So far the way we collect and measure this agreement is via votes on our petitions site, but I’m happy to discuss future plans and HAX in general here too.
Thank you for using web components!
I will make some time to try out HAX soon, in the meantime I have a few questions:
-
I’ve shared a bit of my perspective here, but what do you think HAX’s role could be in the ClassicPress ecosystem?
-
How does the HAX editor behave in terms of backwards and forwards compatibility with TinyMCE? If I make a complicated post in TinyMCE, how does it translate over to the HAX editor? If I make a complicated post in HAX, and then disable it and edit it via TinyMCE, what happens?
-
I’ve thought for a while that it could be interesting to leave
post_contentas rich text using TinyMCE, but start to think of a post as a list of one or more custom fields, of whichpost_contentis just one. This could avoid some of the pitfalls of storing a blob of structured content inside the unstructured not-quite-HTMLpost_contentfield, and it could also be a way around many potential backwards compatibility issues. Is storing each component as a custom field a direction that you considered for HAX?
2 Likes
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.
7 Likes
I love medium way of writing ( i hoped Gutemberg was like that when they announced it).
to say the truth also Facebook note editor and Linkedin is Ok…
Manolo
This is how a proper CMS should be buildt. Even having opportunity to install Gutenberg editor, if someone misses that. Freedom (in form of plugins) vs. dictatorship.
7 Likes
4 Likes
I think the future is about properly structured content, like https://sanity.io.
The thing that most put me off about Gutenberg (apart from the dictatorial approach), was the use of html comments to delineate the blocks in the DB. This is just crazy, and a nightmare if you wish to consume data from WordPress with another system like Gatsby. Blocks done right, with their own DB tables and all, would be fantastic for WordPress / ClassicPress.
8 Likes
Absolutely right about the use of HTML comments. Sheer madness!
4 Likes
We have blocks done right in the form of widgets. I hope, CP will expand functionality of widgets in the future.
3 Likes
I clicked your Codepen link to try HAX, but it warned me that it might not work in my browser. I went ahead anyway, and just saw a white area below the code. I couldn’t see the HTML that it said was there.
So I think you have a ways to go yet. and concerns with browser versions. Not everyone uses the bleeding edge of browsers.
Another thing on the topic of different editors is how difficult it is for the theme to style it to resemble the front end. TinyMCE in core is pretty easy because it uses iframe. Gutenberg is a nightmare because all the UI controls are mixed in with the user content, and the specificity of the CSS is very different from front end to back end.
TinyMCE also has a simple interface to extend the toolbar. Themes can add a filter to the config to add “formats” for users to apply. That’s one PHP function and the theme’s custom classes can be added to any content.
4 Likes
I mentioned in another post (roadmap idea) my thoughts that everything should be a plugin. Including the editor. The base editor is just a plain text-area where you type (or paste) code. No formatting at all. Then if you want tinyMCE that’s a plugin you add. You want a page builder, you add that. And even that plain text area would itself be a plugin.
This way I can have my clients use Libre-Office or some other clean html desktop client where I’ve given them a template with predefined styles and they can just copy-paste it in. Even this editor here in the forum has more formatting than I would have as the “default”.
Just my $0.02
JS
3 Likes