aia

It seems you misinterpreted my suggestion. You 'don't agree' with something weird that you came up with yourself because I never said to do that. I would not agree with that either 
I only suggested adding one interactive area, which allows typing in the paragraph only upon interaction, and nothing like what you described. In this implementation, it does not have any of the drawbacks you imagined.

Those elements are not intuitive for inexperienced users (i.e., almost all users).
It would be much more intuitive and easy to use if there were an area where users could click to start writing in a new empty paragraph. This area should always be placed right after the existing content in the editor:

If this is implemented, even inexperienced users won't get stuck in a state where they can't add a new line and don't know where to search for a button to do that.

JS and iFrames are one thing, but what about, for example:
HTML anchors (to add a link to an H2 further down the page)? Elements IDs and classes (for CSS)? Adding spans (for custom styling)? Will these be possible in the new editor? 
I like to be able to style elements in specific ways, in Pages but also in the forum, for example: 

Or, for example: 

It seems you misinterpreted my suggestion. You 'don't agree' with something weird that you came up with yourself because I never said to do that. I would not agree with that either 
I only suggested adding one interactive area, which allows typing in the paragraph only upon interaction, and nothing like what you described. In this implementation, it does not have any of the drawbacks you imagined.

It seems you misinterpreted my suggestion. You 'don't agree' with something weird that you came up with yourself because I never said to do that. I would not agree with that either 
I only suggested adding one interactive area, which allows typing in the paragraph only upon interaction, and nothing like what you described. In this implementation, it does not have any of the drawbacks you imagined.

Those elements are not intuitive for inexperienced users (i.e., almost all users).
It would be much more intuitive and easy to use if there were an area where users could click to start writing in a new empty paragraph. This area should always be placed right after the existing content in the editor:

If this is implemented, even inexperienced users won't get stuck in a state where they can't add a new line and don't know where to search for a button to do that.

For example, I add a class to an embedded YouTube video to center it. The embedded block does not respond to the centering buttons from editor.

Love it! Although I am concerned my members will write their entire posts in H1 😄

Hi Kudos to IPB Team they have added tiptap as new editor for IPB5 it looks amazing. But it would be really great if team could also add support for Lexical Editor so admin could choose between tiptap and Lexical for their communities 


Here is Playground Demo Link

https://playground.lexical.dev/


Here some noticeable feature about Lexical Editor:
MIT License (Developed by Facebook Core React Team)
Its headless and built-in excalidraw 
Lets you convert the html content into JSON and vice versa.
React 18+ support. Lexical is very minimal. it's closer to an API for a virtual DOM around content-editable than it is to a text editor framework. That's pretty low-level
Lexical is 22KB gzip. The rest is shipped as plugins that users can seamless plug and play (as they're as independent from the rest, including the real-time collaboration plugin) and you only pay the cost of what you need 

and many more out of box !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


Here is Short Video Demo Link
https://i.imgur.com/kCPmiBd.mp4

Please submit your comments and Likes so this feature get enough votes to be added 🙂

Thanks
Dia ^_^

@Matt Finger Thanks for your inputs, I totally agree what you mentioned above, Here My Two Cents:

Only problem with Tiptap is, As they are very small startup as compared to Billion Dollars Facebook. They just recently raised some seed round and they have been surviving by selling Licenses for PRO Features which are freely available in other Text Editors. Sooner or Later there will be less updates for Free Version to push the users to buy premium licenses which will be not good for long term sustainability of IPB Development & IPB Based Communities.

it is true Facebook killed Draft.js ( But Lots of Startups Shut Down Too)
Lexical Now is what Draft.js wanted to be. Lots of developments going on with Lexical right now. Moreover Facebook has very good track records as compared to others to develop Open Source Projects which have been become industry standards.
Thanks!!

It's worth remembering that its behavior could be adjusted for specific regions such as Pages, while global defaults could follow best practices.

It's important not only for SEO but also for accessibility, especially for screen reader users.
The usage of more than one H1 tag is considered a bad practice for a reason, as highlighted even in MDN docs.
By the way, Google isn't the only search engine in the world. I know it's (almost) not the case in the US, but other countries also exist on this planet.

It's important not only for SEO but also for accessibility, especially for screen reader users.
The usage of more than one H1 tag is considered a bad practice for a reason, as highlighted even in MDN docs.
By the way, Google isn't the only search engine in the world. I know it's (almost) not the case in the US, but other countries also exist on this planet.

H1 must be removed from this menu. Also, its insertion should not be triggered by just one "#" symbol (Markdown).
Each page must have a unique H1.

It's important not only for SEO but also for accessibility, especially for screen reader users.
The usage of more than one H1 tag is considered a bad practice for a reason, as highlighted even in MDN docs.
By the way, Google isn't the only search engine in the world. I know it's (almost) not the case in the US, but other countries also exist on this planet.

It's worth remembering that its behavior could be adjusted for specific regions such as Pages, while global defaults could follow best practices.

It's important not only for SEO but also for accessibility, especially for screen reader users.
The usage of more than one H1 tag is considered a bad practice for a reason, as highlighted even in MDN docs.
By the way, Google isn't the only search engine in the world. I know it's (almost) not the case in the US, but other countries also exist on this planet.

H1 must be removed from this menu. Also, its insertion should not be triggered by just one "#" symbol (Markdown).
Each page must have a unique H1.

At present, shorts are embedded using a 16:9 aspect ratio, which is not ideal since their actual format is 9:16. It would be nice to fix this.
Adjusting the embed settings to match the native 9:16 aspect ratio of shorts will enhance the viewing experience and maintain content integrity.
Now:
Should be:

At present, shorts are embedded using a 16:9 aspect ratio, which is not ideal since their actual format is 9:16. It would be nice to fix this.
Adjusting the embed settings to match the native 9:16 aspect ratio of shorts will enhance the viewing experience and maintain content integrity.
Now:
Should be:

It's quite a bad approach and should never be used in any reputable software. Unwanted styles/tags should always be stripped immediately when text is pasted into the editor, long before the message is sent to the database, not on the template side as it happens in this example.
This code is a temporary and ineffective workaround, not a solution.

It's quite a bad approach and should never be used in any reputable software. Unwanted styles/tags should always be stripped immediately when text is pasted into the editor, long before the message is sent to the database, not on the template side as it happens in this example.
This code is a temporary and ineffective workaround, not a solution.

Transitioning from "Display Name or Email" to solely "Email" logins isn't seamless for users who have stored their login credentials using their Display Name.
They repeatedly click "Sign In" without comprehending the issue when login attempts fail.
Adding a simple tooltip to the login field when the entered value is not an email would greatly improve UX in this case. This way, users can easily see and switch without encountering further problems.
Example:

Also, it would be a good idea to keep the "Sign in" button in this form dusabled until both fields are valid (email is validated and password is not empty), so users won't waste their login attempts with this kind of little mistake.

It's quite a bad approach and should never be used in any reputable software. Unwanted styles/tags should always be stripped immediately when text is pasted into the editor, long before the message is sent to the database, not on the template side as it happens in this example.
This code is a temporary and ineffective workaround, not a solution.

It's quite a bad approach and should never be used in any reputable software. Unwanted styles/tags should always be stripped immediately when text is pasted into the editor, long before the message is sent to the database, not on the template side as it happens in this example.
This code is a temporary and ineffective workaround, not a solution.