Slate: Links should be marks instead of inline nodes

[SamyPesse]

Currently in the examples (https://github.com/ianstormtaylor/slate/blob/master/examples/links/state.json#L12), links are inline nodes.

I think, similar to Prosemirror, links should be marks, so that the user can click the Link button, enter an href and start typing (similar to Google Docs or other editor) (link will be added to cursorMarks).

Maybe it's already possible, then examples should be adapted.

[ianstormtaylor]

I'm not sure about this one... but down to debate!

For Inline vs. Mark, I think the distinction should be whether the user expects the element in question to be "breakable". Since marks are always grouped by ranges, if there are different ranges, then multiple marks will be rendered, without a way to enforce the nesting order. Whereas with inline nodes, you are always certain that it you create one, it'll stay as a single node, wrapped around any marks that get added/removed.

If links were marks and you wanted to change the URL of a link, you'd need to do some complex logic to update the href data property on every mark in the contiguous range.

I think it might be better to write handler logic that keeps track of the "current link" in a similar way to cursorMarks and applies it on any insertion of text, unless the selection changes before text is inserted. Off the top of my head that sounds like the best approach.

(Of course Slate doesn't enforce it, so folks are free to choose to use marks for it if they really want.)

[tyler-johnson]

I was under the impression that marks only set styling in the range and don't affect the tagnames or attributes. To me that is solid separation between Mark and Inline.

I do find it strange that Prosemirror allows links to be separated by paragraphs. I'm not sure when a user of the WYSIWYG would desire that functionality, but then again stranger things have happened.

Quill has something similar called "formats" where you can add inline elements arbitrarily over several other inlines or elements. The result? A horrible mess of tangled code _riddled_ with edge cases. I think creating a clear separation that relies on the DOM for "design inspiration" is going to result in a cleaner solution that works more reliably.

[SamyPesse]

I'll probably experiment with both and keep you updated!

[ianstormtaylor]

@tyler-johnson I use that distinction mentally too, but I was thinking that there _might_ not be a reason to limit mark rendering to an object of styles. I think it would be possible to let people render them as component, so you could implement hover effects or similar! (Doesn't affect this question, but food for thought for later.)

[ianstormtaylor]

@SamyPesse let us know if you end up disagreeing after experimenting, I'll close for now!

[SamyPesse]

@ianstormtaylor I agree, marks should be component too, in my case limiting to styles is disturbing (we can't use our classic css, and we not to "copy" the styles from it).

something like this would be great:

const Bold = (props => <b>{props.children}</b>);
const WithStyle = (props => <span style={{ fontWeight: 700 }}>{props.children}</span>);

function renderMark(mark) {
    if (mark.type == 'bold') return Bold; 
    else return WithStyle;
}

[ianstormtaylor]

@SamyPesse agreed! I'll open an issue for that so I don't forget. It's slightly lower priority for me right now, but I'm sure I'll find a use case for it myself that'll cause me to implement it eventually! Until then, anyone else is welcome to take a stab.