[acywatson]

Thank for the feedback - we're definitely still working on the docs.

> These are weird and conflated set of buzzwords. Why should something that isn't concerned with UI components be concerned with accessibility best practices?

Are they? Support for speech-to-text technologies and IME/composition input, for example, are independent of UI components.

> but Slate.js is 10kB and much more mature.

Is it?

https://bundlephobia.com/package/slate@0.77.0

[alephnan]

> Support for speech-to-text technologies

So Lexical doesn't care about how the DOM is rendered? Or is speech-to-text derived independent of the DOM?

> but Slate.js is 10kB and much more mature.

The maturity bit, yes.

For the bundle size, Slate.js is still better. It's the same bundle size for something that's batteries included.

[acywatson]

> So Lexical doesn't care about how the DOM is rendered? Or is speech-to-text derived independent of the DOM?

I do now see your general point about the conflation there - the reality is Lexical also provides separate packages that implement a lot of common rich-text functionality. Within these, we do try to adhere to accessibility best practices. At the same time, the core library's accessibility claims are more based on support for various input methods, which I don't see as necessarily directly related to "UI components".

> For the bundle size, Slate.js is still better. It's the same bundle size for something that's batteries included.

Maturity is mostly a matter of time. I'm not sure what you mean by "batteries included"? AFAICT you need to install plugins on top of the core library with Slate to get a working text editor.

[alephnan]

> I'm not sure what you mean by "batteries included"?

A rendering layer. With Lexical, you'd have to add in the React layer, which wasn't already included in the bundle size comparison.

[trueadm]

Don't you need `slate-react`, `slate-history` and other plugins too?