Reporting a bug: Somewhere in the Slate rendering / deserialization process nodes get wrapped in <span> -elements. You can notice this when inspecting the markup with the browser tools. Why / how this happens isn't explained in the docs, which leads me to believe this is either a necessity for Slate to function or maybe a bug.
Here is an example fiddle: https://jsfiddle.net/kLh1yxeb/
Example of extra Slate wrappers:
<li data-key="12">
<span data-key="13">
<span data-slate-leaf="true" data-offset-key="13:0">
<span data-slate-content="true">
Item 1
</span>
</span>
</span>
</li>
Expected behavior: No extra spans are created. The spans are coloured red and the "text content" inside the <li> elements remains as the default color (black).
Current behavior: Everything inside the <li> -elements is colored red, depending on the element order some of the content disappears entirely!
Environment information:
Operating system: Linux Mint 18.3
Browser: Brave 0.58.18 (Chromium: 71.0.3578.98)
- - -
"slate": "0.45.1"
"slate-html-serializer": "0.7.39"
"slate-react": "0.21.21"
I'd argue this problem is caused with a css rule that is too broad. You can use css rules, like first-child or class names to deal with this issue in a more precise way. The spans that slate renders may not be immediately obvious, but your use case is still achievable.
Hey @neutraali the inner text content of the nodes is an implementation detail and can change over time, so you shouldn't try to select deeply into it.
@CameronAckermanSEL The CSS in question is just a bare-minimum snipped to showcase the erroneus behavior. When parsing, for example, a mailer-template with custom CSS you can easily see how those extra spans will start causing problems.
@ianstormtaylor What do you mean by this? It's obviously a bit of a problem when we deserialize those <li> -elements (in this example) and find out that some of the content goes missing!
Would it be possible to (via configuration?) change those "implementation-detail-spans" into something non-standard, like <slate> -tags? That would eliminate some of the current styling problems, at least.
Use Slate only to edit and write your own renderer (or ask around in Slate Slack) to render "clean" HTML from JSON state. That goes for email templates, regular front-end content consumption, etc. You wouldn't want users to download extra JS: Slate, like all rich text editors, is not super small and it's obviously not as performant as rendering with just plain React. You can store classes or inline CSS in data attribute.
Slate has readOnly mode but I'd say it's suitable for features like preview.
Use Slate only to edit and write your own renderer (or ask around in Slate Slack) to render "clean" HTML from JSON state
Right, so Slate doesn't support _editing in place_ - A mention of this and a description of why/how Slate adds extra elements to the DOM would be super useful to have in the docs.
Still curious as to case of the vanishing content though - It's a relatively show stopping bug for us.
Most helpful comment
Use Slate only to edit and write your own renderer (or ask around in Slate Slack) to render "clean" HTML from JSON state. That goes for email templates, regular front-end content consumption, etc. You wouldn't want users to download extra JS: Slate, like all rich text editors, is not super small and it's obviously not as performant as rendering with just plain React. You can store classes or inline CSS in
dataattribute.Slate has
readOnlymode but I'd say it's suitable for features like preview.