Hi, for now the marksAcross() returns the array of all marks appeared in a range. a common situation in everyday using is, when you select a range of text, the menubar should display the shared or common state of that selection.
for example, helloworld , this selection have two marks in it, if you use marksAcross(), it will return both strong and em. But the more practical usage is to get the common marks, in this example, there’s none, so the strong and em button shouldn’t show as active state.
if the selection content is hello world
now there’s one shared mark: strong.
another situation:
what do you mean
this selection has no shared mark, because every word has it’s own mark ( or has no mark at all )
I think there could be a method like marksShared() or something, instead of returning all marks it returns the common marks.
The existing toggleMark command will first turn a mark off in the selection, if it exists, and only add a mark when it doesn’t occur in the selection. If you want to create a different UI, that works too, but you’ll have to write your own code to implement it.
I see.
the purpose of marksShared() is to find which marks that all nodes in the selection have, so you can toggle that mark. it’s the default behavior of most online docs like google docs. for example, this text:
I’m strong and I’m em
if you select the text above in Google Docs, your menubar won’t show active strong or em. and if you click the strong button, it won’t remove the strong mark of I’m strong, instead, it gives the whole selection a strong mark.
the behavior of toggleMark() is much simpler, it just remove the strong mark of I’m strong and do nothing to and I’m em. is this behavior designed on purpose?
because to me the way google docs behave looks more practical.
It makes it possible to clear a given mark from an arbitrary selection, which isn’t possible in the classic model.
I think what you want is a separate command, structured slightly differently than toggleMark. I don’t think I want that in the main distribution for the time being.
wow. I’d like to offer some feedback in the spirit of contributing to the community.
I am taken aback by your candor about what you want in the main distribution. I have read the github readme and contributing docs in which you state:
We aim to be an inclusive, welcoming community.
Your comments above sound neither welcoming nor inclusive.
I am new to this community and am not sure how architectural design decisions get made. I noticed that there is a nascent RFC process. Is the process uni-directional, as in, you ask the community for opinions on a change that you want to make, or is it bi-directional where the community can also request a change that you must endorse?
As someone early in the process of integrating ProseMirror as a mission critical component of a larger system, I must pause and reevaluate. Is this community one where anyone can contribute value to the larger community or one dependent on the heroic efforts of one man?
That’s too bad. I offered the original poster a road towards getting the behavior they want. If your definition of a welcoming community is a project that integrates every suggestion into the core library right away then no, this project might not be for you.
I can understand part of the reasons of marijn. any new modification to the APIs of an open source project will affect a lot of people who are using it, so the decision must be made carefully. after all ProsoMirror is not a full featured drop-and-use solution. I just think maybe other people may want what I want, if that’s not the case, I sure can write my own code and share with others, just not through the core library. No need to harm any one here.