Re: [w3c/editing] When an 'insertHTML' command should be applied as sibling or child of a styled 'span' element ? (#191)

I think what is important is that the browsers A) don't produce pre-HTML5 content and B) that they behave similarly C) that what they do makes sense. The prioritization should be in that order (A, B, C). In this case, after A has been solved, B is important, C not so much. It would be good to have Firefox behave like the other two, but given that almost all of execCommand is not used by known editors that run in unpatched browsers, it's not that important what it does, really.

The question about subsequent text is whether the inline node that holds the styling is `inclusive` or not. The right answer to that really depends on what the semantic purpose of the styling is. JS editor frameworks have settings for specific styles to either be inclusive or not inclusive [1]. The JS editors know what the semantic purpose of the styling is - the browser do not. For example for the style is normally inclusive for italic and bold, but not for links. A "link" may just be some text that is styled with an underline and with an event listener listening for a click on them to then create a popup within the page. it's really impossible for browsers to tell what is appropriate behavior in any given situation - maybe the green color applied in your example is meant to show that it's a link. Maybe it has a similar function as bold. 

That's why browsers should just focus on doing the same thing rather than try to do the right thing. That way JS editors have an easier time modifying their behavior without having to write special code for each browser engine.


[1] http://prosemirror.net/docs/ref/#model.MarkSpec.inclusive 



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/191#issuecomment-481410216