You’re missing something fundamental here. If you apply the listener to the search field element itself, then the event will be observed on the item that is creating it. The only reason you would need to wrap that listener in another listener is if you were putting your JavaScript in the head of the page. In that case, you have to wrap the field’s listener in a listener on the document itself, so you know when the document has finished loading.
This pen illustrates adding the listener on the search field:
If you were going to put the JS code in the page head, rather than at the very bottom of the page in the Before /body position, then you would need to wrap the handler like this:
document.addEventListener('DOMContentLoaded', function(){
document.getElementById('search').addEventListener('blur', function(){
this.value = '';
});
});
The outer one observes the page loading, and the inner one observes the form field blurring. It’s seriously easier to just move the code to the bottom of the page, though, and it means that you get a faster time to first paint on the screen.
You want to listen for these events as close to where they are emitted as possible. While the blur event will bubble out, and eventually reach the document, it’s just easier to listen directly from the input.
Walter
On Mar 1, 2017, at 8:07 PM, JDW email@hidden wrote:
This doesn’t work either…
//delete field contents and defocus when user clicks outside field > function blurMe(evt){ > if (evt){ > document.getElementById("Field").value = ''; > } > } > window.addEventListener("blur", blurMe, false);
James W.
dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk
dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options