What is the accesskey for enter in html?
For example in a button to trigger it using the keystroke "h" it would be accesskey = "h"
however accesskey = "enter" nor accesskey = "Enter" work
You can not use accesskey to trigger a button with Enter key
From Mozilla Docs:
The attribute value must consist of a single printable character (which includes accented and other characters that can be generated by the keyboard).
You could use js to listen for an enter keypress pretty easily as follows:
const enterBtn = document.getElementById("enter-btn");
enterBtn.addEventListener("click", () => console.log("clicky!"));
window.addEventListener("keypress", ({key}) => {
if (key == "Enter")
enterBtn.click();
});
<p>If you need to relax, press the
<strong><u>S</u></strong>tress reliever!</p>
<button id="enter-btn">Stress reliever</button>
However what you're probably trying to recreate is the form action of submitting on enter, you can read more on the Mozilla Docs
There is none. Per the MDN docs, "The attribute value must consist of a single printable character". The enter key is not a printable character.
It is also already in use as a keyboard shortcut for several significant UX interactions by default; assigning it to other uses would conflict with those expected defaults.
(Note also that this attribute "is seldom used because of its multiple conflicts with already present key bindings in browsers.")
Related
Every browser seems to treat pressing Enter as submitting a form. Is this behavior specified by HTML standards, or is it just commonly implemented by browsers?
Related though goes into much more detail about the exact behavior of buttons: Do all browser's treat enter (key 13) the same inside form?
The closest I've found, from https://www.w3.org/TR/html52/sec-forms.html#implicit-submission:
If the user agent supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text field is focused implicitly submits the form), then doing so for a form whose default button has a defined activation behavior must cause the user agent to run synthetic click activation steps on that default button.
This suggests that it's platform-dependent.
In the html standard
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#implicit-submission
you'll find this:
4.10.21.2 Implicit submission
A form element's default button is the first submit button in tree
order whose form owner is that form element.
If the user agent supports letting the user submit a form implicitly
(for example, on some platforms hitting the "enter" key while a text
control is focused implicitly submits the form), then doing so for a
form, whose default button has activation behavior and is not
disabled, must cause the user agent to fire a click event at that
default button.
Essentially: the first submittable button (belonging to the form) in the DOM tree will be triggered on "Enter".
I am having an issue with numeric inputs on payment forms. When users enters a dollar sign ($) into numeric inputs in Chrome, Chrome simply blocks the $. However, when users enters a $ in Safari, Safari highlights the error (outlines the input box in red), but allows the $ to persist. Then, when the user tries to submit the form, the form resets instead of submitting and confuses the user.
Is there a way to replicate the behavior in Chrome in Safari (simply block the $ but allow the user to keep typing)? Or alternatively, is there a way to allow the use of the $ and allow the form to submit?
Weirdly, I can't seem to find any info on this although it seems like it would be a common problem for folks using payment forms.
You could use Javascript / JQuery to only allow specific characters (eg. 0-9).
// Catch all events related to changes
$('#textbox').on('change keyup', function() {
// Remove invalid characters
var sanitized = $(this).val().replace(/[^0-9]/g, '');
// Update value
$(this).val(sanitized);
});
Source: Disable Text Entry in <input type="number">
Tell me how you get on and we can try figure something out if that doesn't work. I do recommend looking at the source I linked if it doesn't as there's a few alternatives but there are other ways to get around the specific issue of not allowing a user to enter the '$' character.
This may be a possible bug in Polymer: If I type in an input that has been typed in before, a series of autocomplete values may come up. If I select one using the up/down arrow keys and pressing the Enter key, the element's invalid attribute does not change to false even though the input is valid, however, the input element is stylized as being valid without the red text/underline.
If I tab or click outside of the element (onblur) it does not cause the field to validate. If I click back inside or tab back into the field, backspace one letter and retype, the elements invalid attribute will be properly set.
This has been tested with a regular paper-input and gold-zip-input in Safari 8.0.7.
Work around: As a possible work around, I would like to disable autocomplete for certain input fields. I can't find any documentation to do this. The HTML5 autocomplete attribute has no effect. Is there any way to turn off autocomplete in Polymer?
Is there an option highlighting all strings matching the actual selection in PhpStorm (like in SublimeText) ?
You can use Ctrl + Shift + F7 for this in PhpStorm.
This will highlight all usages of selected text.
Using built-in functionality: select text and hit Ctrl + F that will bring "Find in page" functionality: it will highlight all matches of selected text in this document. But it's not always convenient as you have to hit extra keys and have "find in page" bar open...
You can install and use BrowseWordAtCaret plugin that will automatically highlight word under caret in whole document (regardless of it's nature -- variable or just plain text) + you can easily navigate between all matches.
P.S.
You have mentioned that "I'm used to regularly change the name of an object property, an array key or a parameter name at multiple places in same document."
Consider using Refactor | Rename for variables/class members/etc -- it works across multiple files.
In a chrome extension, I've created tab properties that I'm trying to store with each tab. What is the best way to do this? I've looked into using localStorage, but it seems like there could be an easier way. The data is by no means permanent, it only exists as long as the tab does.
There's definitely no need to use localStorage. Without the notion "data is by no means permanent", one already knows that: tab IDs are unique within a session. From this fact, it follows that the data is non-persistent.
The best method to implement it is to maintain a hash of tab properties:
chrome.tabs.onCreated (optional, add initial info to tab hash)
chrome.tabs.onUpdated - (Add/) Update tab hash (URL is available)
chrome.tabs.onRemoved - Remove hash entry
Tab objects are not expensive: All properties are primitives (booleans, numbers, strings).
For instance (background page only):
var tabStore = {}; // <-- Collection of tabs
chrome.tabs.onUpdated.addListener(function(tabId, changeInfo, tab) {
tabStore[tabId] = tab;
});
chrome.tabs.onRemoved.addListener(function(tabId) {
delete tabStore[tabId];
});
IMPORTANT ADDENDUM to Rob W's answer.
Make sure to also listen to tabs.onReplaced as well, and update the tabStore accordingly.
chrome.tabs.onReplaced.addListener(function(addedTabId, removedTabId) {
tabStore[addedTabId] = tabStore[removedTabId];
delete tabStore[removedTabId];
});
Chrome can change the id of a tab under the hood without warning or signs. As far as I know, the only place that this happens is the Google "instant search" when you type in a search into the address bar. It may be an edge case, but if you don't track this, it could end up being a very insidious problem.