This a pretty simple question (I assume). Probably a repost, but I couldn't find the answer here... so here we go.
I have a checkbox on a page that I want to default to "unchecked" (unless I specify otherwise in my php).
When I refresh the page, if the box was checked, it will stay checked which is no-bueno because checking the box adds a dom element to my page via a function attached to the box. So the problem is if I refresh, the box is still checked, but the dom element doesn't exist (because I haven't fired the function and I don't want to unless the user checks the check box) but the box is ALREADY checked and I end up in opposite land where UN checking the box creates my dom element and checking it removes it.
Basically, the question is...
Is there a way to default a checkbox to unchecked without javascript?
BTW I haven't checked (no pun intended) in any browsers other than FF 3.5.10
See http://weblogs.mozillazine.org/gerv/archives/2006/10/firefox_reload_behaviour.html
(first comment):
It’s done that way on purpose so if you tap the refresh button you
don’t lose your work. There’s an entry in Bugzilla somewhere that’s
been WONTFIXed asking for a regular refresh to always reset the form
entirely. Basically it’s a backwards-compatibility thing — every
browser since NS1.0 (maybe even Mosiac) has done that.
Dynamically-generated pages don’t even reset themselves, though if the
expiration is set to 0 and you hit the back button it will give you a
fresh form. Also, if the form itself changes (add or remove elements,
change the action, etc.) the for will reset on a reload. I haven’t
tested it, but setting the form name to something random (assuming you
don’t need the name for JS access) might just work. Like ”> in PHP.
As you said, forcing a refresh clears the form, and resetting it does
too. Would something like do
what you want (again, not tested)?
this works for ie
autocomplete="off"
Sure:
document.getElementById('my_checkbox').checked = false;
Oops, I missed the part about no JS. As far as I know, Firefox retains page state on refresh, so I guess there's no other way.
In fact, you just have to add the <form> tag with attribute autocomplete="off":
<form autocomplete="off">
<label for="checkbox">
<input type="checkbox" id="checkbox">
</label>
</form>
You can use the parameter autocomplete="off" directly on the input tag
Related
I need to remove the browser's autofill/suggestion feature.
This autofill is disabled using autocomplete="off" in Textfield component. once I do that this brings browser's auto fill feature
In Edge, If I turn off the "Save and fill the personal info" option in "Settings/Profile/Personal info" the above suggestion is not shown. Is there any way without turning off that setting I can remove the autofill feature using Material UI TextField property or CSS property "input:-webkit-autofill"
If autocomplete fails to work, most likely it's a bug or for some reason, react is preventing the attribute from being modified.
However, I know a simple way to bypass by changing the type attribute to something random, where the browser can't understand what it should ask from the user and therefore, the browser can't prompt an autofill.
For example on a standard HTML input tag:
<input type="inputText"/>
This will still treat it as an input field, however, it will not attempt to autofill.
Its browser functionality which you cant handle from code level. If you want to prevent it than you have to made setting changes in browser
Turning Off Autofill in Chrome
Click the Chrome menu icon. (Three dots at top right of screen.)
Click on Settings.
In the "Autofill" section, expand the area for which you wish to disable Autofill.
Toggle the setting OFF if it is on. The system will automatically save your settings.
More details found here => https://support.iclasspro.com/hc/en-us/articles/218569268-How-Do-I-Disable-or-Clear-AutoFill-AutoComplete-Information-
So for html you can simply put autocomplete="new-password" in your
Auto-complete="off" can also be used nut it has some drawbacks.
Banks and other security institutes turn auto complete off .Problem is user change frequently their passwords and fields and use simple passwords to remeber.So auto complete is good feature in these cases.
But you can try this solution if you want .I hope it will work fine
<input type="password" autocomplete="new-password">
you can add autocomplete="off" to your form or input but many modern browsers do not support autocomplete="off" for login fields
but you can prevent it using autocomplete="new-password"
Preventing autofilling with autocomplete="new-password"
for more information check this link
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#the_autocomplete_attribute_and_login_fields
Its most likely a bug, the solution I've found works best is to have auto-complete have a hard coded random value which will prevent a user from using auto-complete...
Try this:
<input type='password' name='pass' autocomplete='password' />
In terms of the auto-complete value you can have anything you want there.
New edit:
<script>
// Execute this code when page is
// totally loaded
$(document).ready(function () {
/* Setting the autocomplete of
input field to off to make
autofill to disable */
$("#name").prop("autocomplete", "off");
});
</script>
If you have a link nested in a label element, clicking the link does not update state of the associated checkbox. Tested in recent Firefox and Chrome. This used to work 100% – I personally used this approach long time ago; also there are numerous topics on how to prevent the old behavior from happening.
I think that this has something related to GDPR maybe. A lot of cases where you put a checkbox agreement and a link to T&C for example, clicking on the link to open the T&C doc was checking the checkbox, while you may not agree with the conditions.
I have searched for any information when/why this was introduced as well as for potential workarounds, but I was not able to find anything.
<label>
<input type="checkbox" />
<!-- click here will toggle the checkbox -->
I agree with
<a href="terms">
<!-- however, click here will NOT toggle the checkbox -->
Terms & Conditions
</a>
</label>
This used to work before. As I said, most probably this was adopted by most vendors in order to patch the undesired effect of opening T&C for reading and "agreeing" at the same time with them. Unfortunately I was unable to find any proof for that.
Anyone having some info? Any workaround in plain HTML (no JS)?
Had the same issue and have found out that you couldn't solve it correct because of links are made only for navigation but not for checkboxing. Browser wants go throw the link first instead filling checkbox. You can write the link outside you checking area.
I recently faced to a strange bug (or something) in IE behavior is described blow. (For quick conclusion, read the bottom of the question titled "edited").
suppose i have an input tag in the middle of some other div tags:
<input type="text" name ="foo" id="foo" value="2" onfocus="alert('foo')" />
You expect browser to alerts when ever input get focused, right? every browsers work as desired except IE. So i decided to play around it a little bit.
First, I edited the script using F12 developer tool in IE, And put a harmless space-bar after onfocus="alert('foo' ) Then it worked!!!.
Every time i edit some where in the onfocus statement, from then on, the browser work as expected. but when refreshing, it gone.
Then i put <input> tag in outer div And it Worked.
My first guess was that
may be event suppressed/stopped to propagate some where in the middle.
So i used this code to track event chain. the event captured/bobbled like a charm. But this code used addEventListener() function in order to log every propagation and traverse.
Then i put <input> tag back in to the middle <div> but this time, I used addEventListener() function to attach handler to focus event, And again It Worked. But for this particular situation, I rather not to use addEventListener().
It's good to know that, outer DIVs are loaded on page-load but inner 'DIVs' are loaded by an ajax call.
So my second guess is that:
May be there is a bug with ajax loading content in IE
It's also good to know that, it doesn't matter what event do you call, It just stop working!!!.
By the way, I'm using IE 11.0.32
Any suggestion/explanation about what just happened
And any idea about what to do to get IE work with event attributes would be appreciated.
------------------------- Editted -------------------------------
After some more investigations, i understand that IE shows this behavior when i put <script> tag in my .cshtml file.
For instance, <input type="text" name ="foo" id="foo" value="2" onfocus="alert('foo')" /> <script></script> wont work. but without <script> tag, It'll work.
It seams, It'll delete onfocus event from DOM, and when a change has made, then it'll put it back in to the element.
does any one have this experience?
I found that <input type=“search”> only works in Chrome and IE, but not in Firefox.
How can I make <input type=“search”> show the cancel button (x) in Firefox?
Webkit derived browsers put in an x to clear a value. Firefox does not. However firefox supports this feature, but it does nothing about it and you need to style it your self to show the X button in firefox.
Following link will help you to achieve the goal: HTML Textbox with a clear button in Pure CSS and without JavaScript
While the accepted answer is working as it can be seen in the codepen,
I feel the need to explain how this is working and what to be aware of.
As it took me quite some time to get it working as expected.
For anybody who was wondering how the clear is working type="reset" is causing this. Read more about it here
elements of type reset are rendered as buttons, with a default click event handler that resets all of the inputs in the form to their initial values.
This brings us to the second point of what to be aware of.
As the docs explains, the input or button of type reset will only work within a form. However, this creates a problem when having multiple inputs in a form, as all of them will be reset.
Another cavity would be the fact, that while fixing the clear button on firefox this will now produce multiple clear buttons in all the other browsers that do have support for it.
A little feature is that the css content also accepts a url(). This means that for instance custom svg's can be used as a clear icon.
I currently have a form like so:
<form action="#">
<select {if $isPostRequest}disabled="disabled" {/if}size="1" name="locale"
onchange="location.href={if $languageToggleNoUser}'{$currentUrl|escape}{if strstr($currentUrl, '?')}&{else}?{/if}setLocale='+this.options[this.selectedIndex].value{else}('{url|escape:"javascript" page="user" op="setLocale" path="NEW_LOCALE" source=$smarty.server.REQUEST_URI}'.replace('NEW_LOCALE', this.options[this.selectedIndex].value)){/if}" class="selectMenu">{html_options options=$languageToggleLocales selected=$currentLocale}</select>
</form>
It currently causes a WCAG 2.0 error, as all forms need a submit button.
I'm wondering how I could change this code to include a submit button. The code for the onchange option is quite convoluted, and I don't understand it.
Thanks.
WCAG 2.0 does not require to have a submit button. What you link to is a technique, which is informative (not normative), and it’s only one of possibly many ways to achieve the guideline 3.2.2.
So it can be conforming to have no submit button, for example when
the user has been advised of the behavior before using the component
Related technique: G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
The important thing to note here is that a change of content does not immediately mean a change of context.
From a 3.2.2 guideline perspective, your select box is highly likely to be perfectly fine.
A change of context means a really drastic change. Something like when the user selects an option in the select box, focus is shifted to a different section of the page. Also things like causing a full page refresh or opening a new tab will also fail this criterion.
WCAG "change of context" definition
major changes in the content of the Web page that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously
Changes in context include changes of:
user agent;
viewport;
focus;
content that changes the meaning of the Web page.
Note: A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).
Example: Opening a new window, moving focus to a different component, going to a new page (including anything that would look to a user as if they had moved to a new page) or significantly re-arranging the content of a page are examples of changes of context.
So if all you are doing is modifying some content elsewhere on the page and not messing around with the users focus point, you are doing everything just fine from a 3.2.2 guideline perspective.
You are currently failing in another way though
There is one thing that is causing your select box to fail accessibility. It is lacking a label. This is a fail against guideline 2.4.6 Headings and Labels. The lack of a label means that users will not know what the select box is for.
<form action="#">
<label for="unique-id">Label for select box</label>
<select id="unique-id" {... all that other junk ...}>
{...<option> elements...}
</select>
</form>