We are aware that the autofocus-attribute works only on Page Load & Reload Page.
Use-case:
I have 2-input fields in a form and the first input field has the autofocus-attribute and when the form initially loads the field has the focus [expected behavior].
Now, I click on the second input field and simply close this form.
I launch the form again (cached form comes up) - the focus persists on the second field - I want a workaround/solution where the focus remains in the first field even for a cached form in html.
A sample code
<input type="text" #myInput id="first" autofocus>
<input type="text" id="second" >
Is there a workaround for cached form to bring focus to the first input element every time?
I have tried the .focus() on the element under ngAfterViewInit() alongside have tried explicitly called the method right after the first input field (which would only work if there is only one input field in a form, because the focus doesn't move to the other field), (i.e.)
<input type=text" #myInput id="first> {{ myInput.focus() }}
Related
I'm working on an HTML form for a web app. I'm adding the enterkeyhint attribute to indicate and navigate to the next input until the last one submits the form.
The problem is that enterkeyhint doesn't navigate to the next input if its type is type=text.
This happens on Chrome/83.0.4103.101 for Android 7. In Safari the hints button appears but they all do nothing.
Example:
<form (submit)="submitForm()">
<div>
<label>Name</label>
<input type="text" enterkeyhint="next" inputmode="text" />
</div>
<div>
<label>Email</label>
<input type="email" inputmode="email" enterkeyhint="next" />
</div>
<div>
<label>Comments</label>
<input type="text" />
</div>
</form>
Focusing on Name input, the Next button doesn't do anything.
Focusing on Email input, it navigates to any next input (Comments)
Now, if I change the type=email for type=text it doesn't navigate to the next input.
Similar behavior happens for type=tel. It does navigate to the next input of the form.
Am I missing something to make this work?
Thanks
enterkeyhint is just a hint to the browser what to display on the virtual keyboard, but you need to implement the actual behaviour yourself. See for example Focus Next Element In Tab Index, or How to focus next input field on keypress if your DOM is simple enough that the input fields are siblings with the default tab order.
From the spec:
The enterkeyhint content attribute is an enumerated attribute that specifies what action label (or icon) to present for the enter key on virtual keyboards. This allows authors to customize the presentation of the enter key in order to make it more helpful for users.
There is nothing in the spec to suggest that enterkeyhint actually affects the behaviour of the Enter key.
When I open my website I want to automatically start typing in my form instead of the default browser search bar.
from the scren:
I want to start typing in the Google bar for example.
scrn
There is an autofocus attribute in Html 5
<input type="text" autofocus>
From MDN:
This Boolean attribute lets you specify that a form control should
have input focus when the page loads, unless the user overrides it
(e.g. by typing in a different control). Only one form element in a
document can have the autofocus attribute, which is a Boolean. It
cannot be applied if the type attribute is set to hidden (that is, you
cannot automatically set focus to a hidden control). Note that the
focusing of the control may occur before the firing of the
DOMContentLoaded event.
When a user loads my page, the first element to become active in the browser is one of my menu buttons.
I have a search box (form field) on my page that I want to be the first thing active.
What I mean by "active" is that when the user pushes the tab button, it cycles through all the elements on the site, right. And if users use tab on my site they have to cycle through all the menu buttons before coming to the search field.
Is there a way to say to the browser, "make this field the first active one on page load"?
So that when the page has loaded, the user can start typing in the search field right away.
Thank you.
You can use autofocus for that. Using javascript you can do
document.onload = function() {
document.getElementById("textField").focus();
}
OR
you can directly use it as follows
Search : <input type="text" name="search" autofocus><br>
You can read more about it here and can try it out here.
It will be best option for case
<input type="text" name="YourSearch" id="YourSearch" autofocus>
I have the following form text input like this:
<input name="name" type="text" value="test" id="name">
It will not show the value, if I change the name attribute to something else it works. It is hardcoded and there are no javascripts interacting with it.
Update: It works fine in Internet Explorer and Google Chrome, won't work in Firefox.
Update 2: I was able to replicate the problem.
For example, in my localhost I access /blog/login, the input name shows the value test, which is hardcoded, if I delete the value and reload, without submiting anything, then input name will be blank as long as I reload. If I navigate again to /blog/login, the hardcoded value will be show again.
This behavior doesn't happens in IE and Chrome.
I apologize if this was a silly question, but this is really strange, I guess.
Browsers add names and ids of form controls as properties to the FORM. This results in the properties of the form being replaced.
Browsers also may add names and id's of other elements as properties to document, and sometimes to the global object (or an object above the global object in scope). This non-standard behavior can result in replacement of properties on other objects. The problems it causes are discussed in detail.
A problem occurs when a form control's name conflicts with the a property name of the FORM object.
For example:
Simple Unsafe Name Example
<form action="">
<input type="text" name="name">
<input type="submit" name="submit">
</form>
Result
The element with name="name" replaces the value of the FORM's name property. A similar type of conflict happens with the FORM's submit method and the element with name="submit'. Which will win?
In most cases, the form control wins and the FORM's property is replaced to have the value of the form control, or, if more than one form control has that name, the FORM's property is replaced with a NodeList containing those form controls.
However, in some cases, the FORM's property is not replaced to have the value of the form control with the same name. The examples in this page show that the result depends on the browser, the property, and how the control is added.
http://jibbering.com/faq/names/
I'm using some radio buttons to influence the behavior states of a jQuery widget.
That widget can be used in a form but, since these radios don't contain any actual data, I don't want them to submit noise to the server, or cause naming conflict to whoever will use the widget in his form.
Here are two potential solution starts, not yet satisfying though :
remove the name attribute : seems to work fine for other inputs, but turns my radios into checkboxes : it kills the link between them so selecting one doesn't unselect the others. Is there an HTML way (i.e. other than Javascript event) to bind them without a name attribute ?
disable the input : As expected, nothing is submitted, but the radios become grey and can't be clicked. Is there any way that they stay clickable yet unsubmittable, like disabled at submit time ?
As far as possible, I'm rather looking for a cross-browser solution.
Try call a function before submit, that disables the radio buttons.
function disableBtn() {
document.getElementById('idbtn1').setAttribute('disabled', 'disabled');
document.getElementById('idbtn2').setAttribute('disabled', 'disabled');
return true;
}
Then, in form:
<form action="file" method="post" onsubmit="return disableBtn()">
Try this:
<form>
<input type="radio" name="group1" value="1" form="">
<input type="radio" name="group1" value="2" form="">
</form>
This still uses the name attribute which is required for radio buttons, and it also leaves the inputs enabled for interaction. No JavaScript code, no during-submit patching of the document in hope that the submit will turn out fine and destroying the document before submit will leave no visible traces.
The form="" attribute indicates that these input elements are not included in their parent form. Actually you're supposed to put the ID of another existing <form> element in this attribute, but then again, by the HTML standard, you're probably not supposed to exclude radio buttons from a form. So this hack is the only solution to the problem. (Doesn't work in Internet Explorer, but what does today.)
I'm intending to use this method for radio button groups that are in a data table which is populated from a <template> element. In this case, there will be a radio group in each table row, so their number is unknown. But since the name attribute is the only way to build radio button groups, they'll need to get counting names assigned. Since the table data is put in a JSON field before submitting anyway, I don't need field names for a form submit. Radio buttons do need names for themselves, but this method will still exclude them from being submitted.