Menu
[B][I][FONT=Arial Narrow][SIZE=4][COLOR=”#B22222″]
i made that JavaScript Code and it suppose to say a pop message when i click “Click me” Without type anything, and when i type it suppose to write what i typed in the text box, but still don’t work i dont know what is the reason,,,,
i already checked the code in Validator and it say there is no errors,,, hope any one give me a notes.
here is my code below
[COLOR=”#0000CD”]
[Code]
<!DOCTYPE html>
<html lang=”en”>
<head>
<meta charset=”UTF-8″/>
<title>JavaScript Test</title>
<script type=”text/javascript”>
function substitute() {
var myValue = document.getElementByID(‘MyTextBox’).value;
if (myValue.length == 0) {
alert(‘Please Enter A Real Value In The Text Box!’);
return;}
var myTitle = document.getElementByID(‘title’);
myTitle.innerHTML = myValue;}
</script>
</head>
<body>
<h1 id=”title”>JavaScript Test</h1>
<input type=”text” id=”MyTextBox” />
<input type=”submit” value=”Click Me” onclick=”substitute()” />
</body>
</html>
[/COLOR][/COLOR][/SIZE][/FONT][/I][/B]
Edited it so I can read it.
<br/>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8"/>
<title>JavaScript Test</title>
<script type="text/javascript">
document.getElementByID = function(ad){
return document.getElementById(ad);
}
function substitute() {
var myValue = document.getElementByID('MyTextBox').value;
if (myValue.length == 0) {
alert('Please Enter A Real Value In The Text Box!');
return;}
var myTitle = document.getElementByID('title');
myTitle.innerHTML = myValue;}
</script>
</head>
<body>
<h1 id="title">JavaScript Test</h1>
<input type="text" id="MyTextBox" />
<input type="submit" value="Click Me" onclick="substitute()" />
</body>
</html>
[code=html]
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8"/>
<title>JavaScript Test</title>
<script type="text/javascript">
function substitute( fm ) {
var myValue = fm.MyTextBox.value;
if (myValue.length == 0) {
alert('Please Enter A Real Value In The Text Box!');
return false;
}else{
document.getElementsByTagName("h1")[0].innerHTML = myValue; // you use this method accessing tags in the DOM
}
return false;
}
</script>
</head>
<body>
<form name="" action="javascript:;" onsubmit="return substitute(this);">
<h1>JavaScript Test</h1>
<input name="MyTextBox" type="text" value="" />
<input name="Submit" type="submit" value="Click Me" />
</form>
</body>
</html>
[/code]did you try this code in browser developer mode ?[/QUOTE]
<br/>
<!DOCTYPE html>
<html>
<body>
<p id="intro">Hello World!</p>
<p>This example demonstrates the <b>getElementById</b> method!</p>
<p id="demo"></p>
<script>
document.getElementByID = function(ad){
return document.getElementById(ad);
}
var myElement = document.getElementByID("intro");
document.getElementByID("demo").innerHTML =
"The text from the intro paragraph is " + myElement.innerHTML;
</script>
</body>
</html>
[code=html]<!DOCTYPE html>
<html>
<body>
<p>Hello World!</p>
<p>This example demonstrates the <b>getElementById</b> method!</p>
<p></p>
<script>
window.onload = function(){
myElement = document.getElementsByTagName("p");
myElement[2].innerHTML = "The text from the intro paragraph is " + myElement[1].innerHTML;
}
</script>
</body>
</html>[/code]why noone still tried jQuery?[/QUOTE]
People [U]should learn[/U] to use form elements and DOM elements properly. You should only use the[B] .getElementById() [/B]when no method exists of accessing that property or DOM element.
[/QUOTE]
there is an advantage to using the right tool for the job... [/QUOTE]
[code=html]<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>JavaScript Test</title>
<style>
.oops::after {
font: bold 1em sans-serif;
color: red;
content: 'Please Enter A Real Value In The Text Box!';
}
</style>
</head>
<body>
<h1>JavaScript Test</h1>
<input type="text" placeholder="Change Hello World!">
<button>Click Me</button>
<p></p>
<p>Hello World!</p>
<script>
document.querySelector('button').addEventListener('click', function() {
var a = document.querySelector('input'),
b = document.querySelectorAll('p');
if (a.value.length == 0) {
b[0].className = 'oops';
}
else {
b[0].className = '';
b[1].innerHTML = a.value;
a.placeholder = "Change " + b[1].textContent;
a.value = '';
}
});
</script>
</body>
</html>[/code][CODE]
<!DOCTYPE html>
<html>
<body>
<p id="exmp">Hi! I'm some <b>innerHTML!</b></p>
<script>
alert(exmp.innerHTML)
</script>
</body>
</html>
[/CODE]@Kevin2 : agreed on point 1. Thank you for saving me the effort of typing that out ?[/QUOTE]
I'm a fan of the querySelectors, too, but only in special cases where the elements are otherwise hard to get at.[ ... ][/QUOTE]
I guess it mostly comes down to preference.[/QUOTE]
the global namespace[/QUOTE]
I'm yet to find a browser that chokes on the following - can anybody? [ ... ][/QUOTE]
Since this train has already derailed, some highly opinionated thoughts:
[LIST=1]
[*] Unless one is submitting form data/input values to be processed on a server [B]<form>[/B] and [B]<input type="submit">[/B] are inappropriate. The form/inputs/script will work and validate either way. Validity and workability are not the point(s). If one is using HTML to state what something *is*, this is not a form, and nothing is being "submitted".
[*] Over the last year to year-and-a-half I've become a fan/proponent of [B]querySelector[/B] and [B]querySelectorAll[/B]. Part of the reason is that they use CSS selector syntax for the elements being targeted and I'm a lot better with CSS than JS ? . For a "real" form with name attributes on the form elements you could use [B]querySelector('input[name=myInputName]')[/B] for those elements with unique names, or for radio buttons [B]querySelectorAll('input[name=myRadioButtonName]')[/B] which is the rough equivalent of [B]getElementsByName('myRadioButtonName')[/B]. No IDs needed for the inputs, just name attributes. How is using the DOM different/better (other than my caveat below)?
[*] With the possible exception of debugging, [B]alert()[/B] should never be used. [/LIST]
With those thoughts in mind, here's a modified mashup of some previously posted code for demo purposes:
[code=html]<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>JavaScript Test</title>
<style>
.oops::after {
font: bold 1em sans-serif;
color: red;
content: 'Please Enter A Real Value In The Text Box!';
}
</style>
</head>
<body>
<h1>JavaScript Test</h1>
<input type="text" placeholder="Change Hello World!">
<button>Click Me</button>
<p></p>
<p>Hello World!</p>
<script>
document.querySelector('button').addEventListener('click', function() {
var a = document.querySelector('input'),
b = document.querySelectorAll('p');
if (a.value.length == 0) {
b[0].className = 'oops';
}
else {
b[0].className = '';
b[1].innerHTML = a.value;
a.placeholder = "Change " + b[1].textContent;
a.value = '';
}
});
</script>
</body>
</html>[/code]
Caveat: If you even care (I don't) IE8- does not recognize CSS3 selectors using querySelector/querySelectorAll. But then those versions also don't recognize getElementsByClassName. Choose your poison.[/QUOTE]
Other than the <b> tagset showing in the alert it works on everything I have on Windows 10 (Chrome, Firefox, IE11, Edge, webkit Opera).[/QUOTE]
what do you think that document.getElementsByClassName() is for CSS and document.getElementsByTagName() is for?[/QUOTE]
querySelectorAll('.myClass') = getElementsByClassName('myClass')
querySelectorAll('input') = getElementsByTagName('input')while a set of form inputs will work without the form tag, it is however, proper HTML to use them[/QUOTE]
and especially one where inputs will be used to submit a form.[/QUOTE]
Most ¬my form isn't submitting¬ problems are solved by adding a <form> tag and adding the minimum tags of name, action, method and when needed enctype are solved by having them.[/QUOTE]
I would like to know where this mindset arose about placement of scripts, they have and always will be an item that is in the <head> tags and if and only if needed in the body or before the end of the <body> tag, people don't seem to realize that it holds DOM up because putting your script in the body or at the end of the document is holding the DOM from completion even though items are available to access ONCE they have been parsed in the browser, it does not mean that they are available across the board UNTIL the DOM has fully loaded... I will let that float for a while.
[/QUOTE]
Well, of course you will see the <b> - we are asking for the innerHTML - if we were asking for the innerText/textContent the <b>'s would not appear[/QUOTE]
But it's not just about perception. We're entering a new age of hardware where mobile is starting to lead the pack considerably. We should be developing with the idea in mind that some users will only ever see our pages on their phone because their phone/tablet/phablet/whatever is going to be their only internet-enabled device. And more processing power requirement means more battery drain which for some parts of the world is a real problem.[/QUOTE]
until the processors and batteries catch up, we're back in a position we were at 30+ years ago - having to think about every byte of code and trying to do things as efficiently as possible.[/QUOTE]
One of my neighbors, who is about 31-32 years old, is also one of the most "connected" people I know. But until sometime last year his sole source of internet was his phone, on a cell connection. Then he got a good deal on a new phone which came with a cheap tablet. Finally got a home internet connection and a wireless router and at some point got a wifi-enabled printer. Still no "real" computer. That neighbor is the future. If we are not developing for him we're failing.[/QUOTE]
Nope.
DOM parsing ceases to parse if a script is within any other part of the body of the HTML document, if you defer the loading of the script until the DOM has loaded, meaning that if your script is placed in the body and is deferred, DOM is parsed then JavaScript is loaded and parsed.
If you go the traditional method, the script is in the head, which is loaded and parsed first, because the script is there in the body, there's no fetching of it and it is ready to go.
There was another articles about the way DOM is parsed in the parsers and it is basically this: The document is loaded, looked at, items initiated, the DOM is parsed and then rendered and scripts are parsed and rendered as well when encountered.
Basically the script should reside in the head of the document as it has always traditionally been. You only put code inline or at the end if absolutely needed.[/QUOTE]
OK, let me amend my previous post.
Yes, there are far too many "mobile" site versions which choose to remove content in the misguided thinking that doing so somehow helps those using smaller screen devices. Many news websites can be lumped into that category.
However, if a developer puts the needs of those users up front, there is no reason a site can't have everything on it that the desktop version of the site does. None! On one site I rebuilt a couple years ago the only difference between desktop and "mobile" versions is that the navigation menu on the left side of the desktop version becomes a slide-in/slide-out menu when you click on a "hamburger menu" icon. That's it! All content is there. I did increase the size of some "tappable" things such as links to make them touchscreen friendly.[/QUOTE]
No. Read the page again. [B]The HTML file will be parsed until the script file is hit[/B]. So if the script is in the head the parser will remain at the head level until all the script has been parsed, at which point it will move on to the body.
defer and sync are two newish attributes for a script tag that solve certain problems, particularly those where external scripts depend on other external scripts. That's a whole other discussion, and of course if you add the defer attribute to an external script in the head then you will end up with more or less the same result as putting it at the end of the body with a speed gain because the script will be parsed while the body is being parsed and not execute until the DOM has been constructed. But please don't take this to mean that a script will be defer'd just because it is sitting in the head. In fact the opposite is true.
It's all very simple and really not worth the extended discussion. You are very welcome to put your scripts wherever you like, but trying to pass off antiquated methods as optimal with the only reason being "that's the way it was always done" is not correct in my view.
There's a very simple reason for making sites mobile-friendly out of the box and that is that Google now penalizes sites that aren't mobile friendly. Although I do agree with Kevin2 here - responsiveness should be done with CSS, and as little playing around with the HTML and JS as possible.[/QUOTE]
0.1.9 — BETA 5.18