-
Notifications
You must be signed in to change notification settings - Fork 245
Conversation
Also I am working on #189 so do not merge this one just yet. |
Ahh, so this occurs when there is no selection. |
@@ -400,4 +400,21 @@ describe('commands', function () { | |||
}); | |||
}); | |||
}); | |||
|
|||
describe('createlink', function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The command name should be camelcased.
I just noticed this from MDN
It looks like this is not actually a bug from their perspective. |
Interesting. This is the trouble – there is no spec for commands! I’d love to get this added to the list of browser inconsistencies with an isolated edge case. Would you mind doing that? One option would be to disable the command if there is no selection, however then you lose the feature Chrome has… |
What's the expected behavior of this plugin?
Not sure what the best approach to be. Looking around
I'm not sure what the preferred use case should be. I'd like to ask around and see if folks are used to one or the other. (Honestly, my preference would be "if my caret is in a word and selection.collapsed = true, when the Link button is selected the whole word should become a link" but from the looks of it that might be prone to inconsistencies across browsers. So my runner up would be "Link button is disabled when selection.collapsed = true." Avoids the heuristics, better consistency + I think most people already have some text in mind they want to make into a link or they're willing to type it out real quick and then link it). |
I think a plugin (UX/UI) implementation of this should not be discussed here. Lets just concentrate on behavior of Maybe we could check if selection is collapsed and if it is.
But that seems rather complex. I would definitely prefer to keep the chrome behavior. Not sure what is the best path to get it. |
Sorry, wasn't trying to imply a UX/UI discussion. Was merely noting that the implementation of I get the idea of choosing the Chrome behavior, but then should |
@OliverJAsh Is there something stopping us from just using insertHTML? I may be overlooking something... |
I don't have a lot of background in this so that sounds like it'd make a lot of sense. Would running something like |
Looking at the browser inconsistency documentation, seems like it might come with some issues of its own. But still sounds like it could bring better consistency than |
You have a good point. If there will be usage for Would you like doing that? @cojennin |
Re. #190 (comment), I recommend reading how we commands are architected in Scribe here: https://github.com/guardian/scribe#commands. Similarly, we’ve patched many other browser inconsistencies: https://github.com/guardian/scribe/tree/master/src/plugins/core/patches/commands The command would still be called You can wrap your patch as a plugin for easy distribution. See the core patches (link above) for an example. |
You don't need to use |
OK, I did the patch and tests seem to be passing. I checked with blink source and there is only 4 lines for this. So I am pretty sure there is no extra magic going on behind the scenes. I also slightly modified the behavior of the selection. Now instead of selecting the link it just places the caret after it. |
// Place caret at the end of link | ||
var newRange = document.createRange(); | ||
newRange.setStartAfter(aElement); | ||
newRange.setEndAfter(aElement); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of interest, do you need to set both the start and end if the selection is collapsed? I’m never sure, but it would be good to familiarise myself with the API more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works both ways for me on Chrome/FF. I would guess undefined behavior as usual. 😫
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks as if range.setStartAfter
also sets a matching end container and offset. This isn't documented. The only spec for Range (2000) I could find is here, which doesn't specify what should happen in this instance: http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/ranges.html
If it’s something that just happens to be implemented in both Chrome and Firefox, we should probably stick with the spec and use setStartAfter
and setEndAfter
.
scribe.api.CommandPatch.prototype.execute.call(this, value); | ||
|
||
// Place caret at the end of link | ||
selection.selection.collapseToEnd(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem like it’s part of the same patch. What was your reasoning for this? Is this another browser inconsistency you're patching?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mentioned it in above comment. I pretty much by accident did it for the patched one. Then I did some scouting (Tiny MCE, Gmail, Google Docs, Medium) and I figured that this is more logical behavior. But that is of course matter of debate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If that’s what the big applications do, I think it would be good for us to do it!
This sort of thing isn't a patch, so I think it belongs as a Scribe command instead of a Scribe command patch (this is just an infrastructure we have for separating concerns in our code). Here are some examples of Scribe commands: https://github.com/guardian/scribe/tree/master/src/plugins/core/commands
Your command patch’s execute
method will be invoked by your command’s execute
method.
execute: function (value) {
scribe.api.Command.prototype.execute.call(this, value);
selection.selection.collapseToEnd();
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But when I add command into core/commands
it will be ignored by other higher lever commands like link prompt command. Because they declare their own commands!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It won't – they will just call your command: https://github.com/guardian/scribe-plugin-link-prompt-command/blob/master/src/scribe-plugin-link-prompt-command.js#L11.
This is good to go! If you want to implement the other changes proposed, please raise another PR. Thanks :-) |
Awesome :) |
Available in v0.1.11. |
Inserting link currently fails reliably on
BROWSER_NAME='firefox' BROWSER_VERSION='29' PLATFORM='WINDOWS'