Long time automation developer here (just for context).
It's been bugging me for quite a while that the dev tools in chrome used to find elements just don't seem to work as I expect. Hopefully someone can point out what I'm doing wrong.
Looking at , say, sauce labs page: https://saucelabs.com/blog/selenium-tips-finding-elements-by-their-inner-text-using-contains-a-css-pseudo-class
ok now that page has div's and anchors
and indeed I can do find ('a') or find('div')
but why do I have a problem using classes or id's ?
The find() method refers to window.find(), a non-standard API for the browser's built-in Find function. It does not find web elements the same way Selenium or Capybara do, and so it does not parse the input as a selector.
You find elements with selectors in Chrome DevTools using document.querySelector() or document.querySelectorAll(). There are no special methods in Chrome DevTools for this, however it does provide the $() and $$() aliases (respectively) to save you time and keystrokes.
You can use jquery code in chrome console, for example if you want to find something with class of "foo" you can write $('.foo') or a id of "bar" you write $('#bar')
You can read all about it here
Also you can just google what you want "Jquery how to find a div with id"
I've created a simple example http://jsbin.com/yifekigo/21/edit. It works in Chrome and does not in Firefox/Safari. It will work in Firefox if I change <nest-row mCols="{{mCols}}" y="{{y}}"></nest-row> to <nest-row mCols="4" y="{{y}}"></nest-row>.
How can I get Firefox and Safari to pass the value of mCols from nest-grid through to nest-row?
EDIT: See Scott's comment on his answer for the use of domReady as a workaround.
Sadly, on Firefox/Safari/IE, the DRY Polymer syntax is not supported in the main document. IOW, you must do:
Polymer('nest-grid', {...
instead of
Polymer({...
Again, this is only true for calls like this in the main document (which typically includes JsBin and friends). Polymer elements in imports can use the DRY syntax on all platforms.
Sorry for the trouble.
I want to use some new HTML5 form attributes and input types on a webpage. Some browsers already support them, others don't and never will. Thats why I want to use Modernizr - and thats were my trouble begins.
To my understanding, Modernizr alone is not a polyfill but a script that can test if the browser is capable of some new HTML5 / CSS3 stuff. If necessary, a polyfill can be loaded which "emulates" these features so they can be used in non-supporting / older browsers. This is correct I guess?
Regarding the testing / loading: Whats the correct or best way to load polyfills with Modernizr?
In the documentation I found this:
Modernizr.load({
test: Modernizr.geolocation,
yep : 'geo.js',
nope: 'geo-polyfill.js'
});
but some pages also do it like this:
if (Modernizr.touch){
// bind to touchstart, touchmove, etc and watch `event.streamId`
} else {
// bind to normal click, mousemove, etc
}
Also, how do I actually get to know how these feature detects are called? Something like Modernizr.geolocation surely exists for every feature detect?
In the Modernizr GitHub repository, there are also many user contributed feature detects. How do I implement these into my version of Modernizr? Or is it the best to just use their builder?
In Safari, the HTML5 form validation works, but there is no UI for displaying error messages. Basically, the feature is just half implemented. That's why Modernizr gives a false positive in Safari, like already mentioned here: https://github.com/Modernizr/Modernizr/issues/266
Apparently someone fixed this with such a custom test, but I still don't understand how to use it.1
The two techniques you're seeing are both valid.
In the case of the yep / nope version, this is the ideal way of loading a polyfill that is to be included from a separate file. This doesn't have to be Javascript -- it can also be a CSS file as well.
In the case of the standard JS if() block, this would be more useful if you had a block feature-dependent code in the same JS file that you wanted to switch in or out depending on whether the feature was available.
So both variants have their place.
However, you may also see the if() block option being used to include separate JS files, because the yep / nope syntax was not available in some earlier versions of Modernizr. Yepnope is actually an entirely separate library that has been incorporated into Modernizr in order to make the syntax for loading polyfill files more readable.
Re your question about how to know what the features are that Modernizr can detect, the answer is, of course, in the Modernizr documentation.
Look in the docs (http://modernizr.com/docs/) for the section entitled "Features detected by Modernizr". This has a list of all the features detected, along with the name given to it by Modernizr.
Re the broken feature detect you mentioned -- the ticket you linked to was marked as closed nearly a year ago, and it looks from the notes on the ticket as though the code for the improved test have been added to the main Modernizr code. Make sure you're running the latest version, and double-check whether this is working for you.
Starting with Modernizr v3, using Yepnope through Modernizr.load() has been deprecated. A good alternative is to use jQuery:
if (Modernizr.geolocation){
console.log('match');
} else {
// load polyfill
$.getScript('path/to/script.js')
.done(function() {
console.log('script loaded');
})
.fail(function() {
console.log('script failed to load');
});
}
I would like to do validate elements WITHOUT using any validation plugin. To start with, I defined:
<input type='number' required="required" id='amt_elmt' name='amt_elmt' />
But I can still type any text in this control (I expected only number can be typed inside it); it accepts blank value also.
What additional code might be required?
as others have mentioned Forms 2.0 or the new HTML5 input types are not supported by all browsers (see this link).
I recently answered another question dealing with the HTML 5 form elements. None of my desktop browsers (FF, Chrome, IE) or my mobile browsers (FF, Android default browser) attempted to validate that I was using numbers, or restricted it to numbers.
Your best bet is a javascript client side validations like jquery.validate or any other number of libraries to accomplish validation.
Edit: The link is to Microsoft's validation library that comes with Visual Studio but you can download it from there website and it works quite well. I can post code on how to use it if you need it
Edit2: Codez http://jsfiddle.net/qxsS8/
Number is an HTML5 input type. This is not yet correctly supported by all browsers, in most browsers you will be able to input anything.
If you want to block anything but numbers while users are typing you are going to need JavaScript on key presses.
If you want to validate after posting if only numbers are used you can use either JavaScript or PHP for this.
Add Javascript event handlers for the events you want to handle (i.e. onkydown, onkeyup, ...). In those functions you can access the value of the input and remove the chars you don't want.
You could use standard HTML5 form validation. Then to support older browsers use this Library:
https://github.com/ericelliott/h5Validate
This will use JavaScript to add support.
All you need to add into your page is the following code:
<script src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.min.js"></script>
<script src="jquery.h5validate.js"></script> // You will need to host this somewhere
<script>
$(function () {
$('form').h5Validate();
});
</script>
It works across:
Desktop: IE 9, 8, 7, 6, Chrome, Firefox, Safari, and Opera. Tested on Windows 7 and Mac.
Mobile: iPhone, Android, Palm WebOS
Finally I found out that using javascript (and maybe jquery) is very flexible.
(No dependency, no third-party error, which is hard to solve for the programmer, who does not know plugin's logic).
link to "javascript only form validation tutorial"
This link proved to be very useful.
This may be helpful to others, hence posting as a separate answer to my own question.
When using the xhtml1-transitional.dtd doctype, collecting a credit card number with the following HTML
<input type="text" id="cardNumber" name="cardNumber" autocomplete='off'/>
will flag a warning on the W3C validator:
there is no attribute "autocomplete".
Is there a standards-compliant way to disable browser auto-complete on sensitive fields in a form?
Here is a good article from the MDC which explains the problems (and solutions) to form autocompletion.
Microsoft has published something similar here, as well.
To be honest, if this is something important to your users, 'breaking' standards in this way seems appropriate. For example, Amazon uses the 'autocomplete' attribute quite a bit, and it seems to work well.
If you want to remove the warning entirely, you can use JavaScript to apply the attribute to browsers that support it (IE and Firefox are the important browsers) using someForm.setAttribute( "autocomplete", "off" ); someFormElm.setAttribute( "autocomplete", "off" );
Finally, if your site is using HTTPS, IE automatically turns off autocompletion (as do some other browsers, as far as I know).
Update
As this answer still gets quite a few upvotes, I just wanted to point out that in HTML5, you can use the 'autocomplete' attribute on your form element. See the documentation on W3C for it.
I would be very surprised if W3C would have proposed a way that would work with (X)HTML4. The autocomplete feature is entirely browser-based, and was introduced during the last years (well after the HTML4 standard was written).
Wouldn't be surprised if HTML5 would have one, though.
Edit: As I thought, HTML5 does have that feature. To define your page as HTML5, use the following doctype (i.e: put this as the very first text in your source code). Note that not all browsers support this standard, as it's still in draft-form.
<!DOCTYPE html>
HTML 4: No
HTML 5: Yes
The autocomplete attribute is an enumerated attribute. The attribute
has two states. The on keyword maps to the on state, and the off
keyword maps to the off state. The attribute may also be omitted. The
missing value default is the on state. The off state indicates that by
default, form controls in the form will have their autofill field name
set to off; the on state indicates that by default, form controls in
the form will have their autofill field name set to "on".
Reference: W3
No, but browser auto-complete is often triggered by the field having the same name attribute as fields that were previously filled out. If you could rig up a clever way to have a randomized field name, autocomplete wouldn't be able to pull any previously entered values for the field.
If you were to give an input field a name like "email_<?= randomNumber() ?>", and then have the script that receives this data loop through the POST or GET variables looking for something matching the pattern "email_[some number]", you could pull this off, and this would have (practically) guaranteed success, regardless of browser.
No, a good article is here in Mozila Wiki.
I would continue to use the invalid attribute. I think this is where pragmatism should win over validating.
How about setting it with JavaScript?
var e = document.getElementById('cardNumber');
e.autocomplete = 'off'; // Maybe should be false
It's not perfect, but your HTML will be valid.
I suggest catching all 4 types of input:
$('form,input,select,textarea').attr("autocomplete", "off");
Reference:
http://www.w3.org/Submission/web-forms2/#the-autocomplete
http://dev.w3.org/html5/markup/input.html
If you use jQuery, you can do something like that :
$(document).ready(function(){$("input.autocompleteOff").attr("autocomplete","off");});
and use the autocompleteOff class where you want :
<input type="text" name="fieldName" id="fieldId" class="firstCSSClass otherCSSClass autocompleteOff" />
If you want ALL your input to be autocomplete=off, you can simply use that :
$(document).ready(function(){$("input").attr("autocomplete","off");});
Another way - which will also help with security is to call the input box something different every time you display it: just like a captha. That way, the session can read the one-time only input and Auto-Complete has nothing to go on.
Just a point regarding rmeador's question of whether you should be interfering with the browser experience: We develop Contact Management & CRM systems, and when you are typing other people's data into a form you don't want it constantly suggesting your own details.
This works for our needs, but then we have the luxury of telling users to get a decent browser:)
autocomplete='off'
autocomplete="off" this should fix the issue for all modern browsers.
<form name="form1" id="form1" method="post" autocomplete="off"
action="http://www.example.com/form.cgi">
[...]
</form>
In current versions of Gecko browsers, the autocomplete attribute works perfectly. For earlier versions, going back to Netscape 6.2, it worked with the exception for forms with "Address" and "Name"
Update
In some cases, the browser will keep suggesting autocompletion values even if the autocomplete attribute is set to off. This unexpected behavior can be quite puzzling for developers. The trick to really forcing the no-autocompletion is to assign a random string to the attribute, for example:
autocomplete="nope"
Since this random value is not a valid one, the browser will give up.
Documetation
Using a random 'name' attribute works for me.
I reset the name attribute when sending the form so you can still access it by name when the form is sent. (using the id attribute to store the name)
Note that there's some confusion about location of the autocomplete attribute. It can be applied either to the whole FORM tag or to individual INPUT tags, and this wasn't really standardized before HTML5 (that explicitly allows both locations). Older docs most notably this Mozilla article only mentions FORM tag. At the same time some security scanners will only look for autocomplete in INPUT tag and complain if it's missing (even if it is in the parent FORM). A more detailed analysis of this mess is posted here: Confusion over AUTOCOMPLETE=OFF attributes in HTML forms.
Not ideal, but you could change the id and name of the textbox each time you render it - you'd have to track it server side too so you could get the data out.
Not sure if this will work or not, was just a thought.
I think there's a simpler way.
Create a hidden input with a random name (via javascript) and set the username to that. Repeat with the password. This way your backend script knows exactly what the appropriate field name is, while keeping autocomplete in the dark.
I'm probably wrong, but it's just an idea.
if (document.getElementsByTagName) {
var inputElements = document.getElementsByTagName("input");
for (i=0; inputElements[i]; i++) {
if (inputElements[i].className && (inputElements[i].className.indexOf("disableAutoComplete") != -1)) {
inputElements[i].setAttribute("autocomplete","off");
}
}
}
I MADE THIS WORK IN 2020!
I basically create a css class that applies -webkit-text-security to my inputs.
Here's the link to a more recent discussion:
https://stackoverflow.com/a/64471795/8754782
This solution works with me:
$('form,input,select,textarea').attr("autocomplete", "nope");
if you want use autofill in this region: add autocomplete="false" in element
ex:
<input id="search" name="search" type="text" placeholder="Name or Code" autcomplete="false">
Valid autocomplete off
<script type="text/javascript">
/* <![CDATA[ */
document.write('<input type="text" id="cardNumber" name="cardNumber" autocom'+'plete="off"/>');
/* ]]> */
</script>