Text node handle "style" field

[amyworrall]

On Lexical JS, text nodes have a "style" field, into which raw CSS can be put. (see TextNode.ts).

On iOS, so far we have implemented this field as a string field, but it does not do anything to affect the output. (The field is there in order that we can correctly round-trip some JSON created by Lexical JS, but nothing more.)

We should decide how to address this in iOS. A most idiomatic iOS way of handling a "style" field, for example, would be to make it take arbitrary NSAttributedString.Key/value pairs. That would accomplish the same thing on iOS as the CSS-based "style" field on web -- letting the API consumer add whatever styling information they wanted, without Lexical having to understand it. However, then we would not get cross platform compatibility of serialised JSON.

We could have our own manual parser/mapping of CSS properties to attributed string properties, built in to Lexical iOS. This will by definition be only a partial solution, as supporting every single possible use of CSS there would be super difficult.

We could punt the problem to the user, by having iOS Lexical store styling info as NSAttributedString.Key/value pairs, but allowing API users to register some kind of plugin/transform that runs when turning the text nodes into JSON and vice versa. Then users can write something which parses just the styling information that they plan to use on their web version, without having to worry about a general purpose solution.

We could also modify Lexical JS, and either come up with an interim format for styling info, or limit the "style" field to a subset of possibilities. However that has the disadvantage of limiting style's usefulness as an 'escape hatch' for any kind of styling not supported natively by Lexical.

We could make the iOS styling field completely separate from the web styling field, and have both versions of Lexical round-trip both of them. That way, there'd be no data loss, each platform would be able to add its own styling information, but there would be no sharing of styling information unless API consumers built it manually.

All of these possible approaches have tradeoffs. Suggestions are welcome!