accesskey adds html as text
UziTech opened this issue · 12 comments
setting the accesskey option adds a span around the letter as text.
The item name should be set by the programmer so that shouldn't be an issue. If the item name is dynamic then the programmer needs to scrub it before adding it to the context menu
yeah, the risk is low, but this is breaking change, and I think the accesskey's span element should be inserted with different way, instead of modifying the name property to HTML.
I'll make a patch shortly.
I disagree that the item name needs to be added as text.
I think it is more likely that the programmer would want to add html to allow styles then the programmer allowing the item name to be set by a users input.
there's 'html' type for that purpose, iiuc.
$.contextMenu({
selector: '#foo',
trigger: 'left',
items: [{ type: "html", html: "<b>Hello</b>", }],
});
Hmm, what i did notice though is that callbacks are not supported on a HTML type, which makes it a bit harder to use.
I guess, there should be another way to create selectable menuitem that parses HTML, that also works in form label and sub menu. The API should explicitly tell it's parsed as HTML (like, property name is html, or something like that) .name property name with HTML support is a pitfall.
Also, current .name way doesn't interact nicely with accesskey if .name contains HTML.
e.g. if .name contains "<b>" and accesskey is "b", it results in corrupted HTML.
so, there should be some way to suppress that replacement but keep accesskey still working.
Both issues could be fixed at once, couldn't they?
I agree with @arai-a here, we do need to have a look on how we can support using html in a different way. I'll be merging his fix.
I agree.
be careful though, parsing html is an extremely difficult game of cat and mouse as people find different strings that don't parse correctly. (unicode chars, etc.)
ah, I meant .html(...) with "parses HTML", as currently .name does.