I would expect the widget’s draggable attribute when set to no to be rendered as a draggable="false" attribute to the rendered HTML <a tag, but that does not happen.
If however I force the "draggable=“false” attribute in the HTML tag using the browser’s developer tools, I get the desired behaviour (the link is not draggable):
Create a tiddler (e.g. “NoLinkDrag”), tagged with $:/tags/Stylesheet, containing:
.nodrag a { user-drag:none; -webkit-user-drag:none; }
Then, in your content, you can write:
@@.nodrag <$link to="HelloThere"/>@@
This method works for any link syntax (e.g.,[[sometiddler]] or automatic CamelCase links such as HelloThere) and can be used to wrap an entire section of content to disable dragging for all links in that content.
Thanks @EricShulman; probably workable, though in my plugin, the attribute would be conditionally set, so slightly simpler for me to use as e.g. <$link ... draggable={{{ [[conditionalfiltergoeshere]] }}}>.
Do you happen to know why it is not carried through by the widget into a draggable="false" attribute in the HTML <a ...> tag?
In fact, it almost feels as this attribute doesn’t have any effect in the <$link widget…
The $link widget does process the draggable="no" widget attribute to prevent TWCore handling of drag-and-drop, but the browser itself is still allowing the underlying <a> HTML element to be dragged anyway. You can see this by comparing the tooltip that is displayed when dragging.
If you write
<$link to="HelloThere"/>
then the TWCore processes the drag and the tooltip is just the link text.
However, if you write
<$link to="HelloThere draggable="no"/>
then the TWCore drag handling is bypassed but the browser drag handling is setting the tooltip to show both the link text AND the underlying URL (at least, this is what Chrome does).
Thus, this would seem to be a legitimate bug in the TWCore’s $:/core/modules/widgets/link.js code, which could be fixed by applying the solution that you’ve already identified. I suggest you open a GitHub issue and submit a pull request for this code change.
In the mean time, a suitable workaround is for your plugin to define a stylesheet shadow tiddler containing
In this context, “capitalized” means that the first letter of the first word should be upper case, but the rest of the sentence should be lower case (except for proper nouns, of course). I’ve fixed your PR title.
Also, with a few exceptions here and there, we generally don’t include comments in the TWCore code. I expect that someone will tweak your PR to remove those comments before it is incorporated into the codebase.