📅 July 19, 2017
- Order of Execution
- Writing to the Page
- Where is the Error?
- Developer Tools
- Writing to the Console
- Relative Path
- Vivaldi Test
- Firefox Test
- Chromium Test
- Browser Discrepancies
NOTE: For this tutorial, remove the space between the < and script>. This is for display purposes on this page.
after the h1 element. Refresh or reopen the same file in a browser and watch what happens. (Pressing F5 on the keyboard will refresh the page in most browsers.)
Order of Execution
To test this, place the script section ABOVE the h1 text like this:
Open a new tab or close the existing page to see the effect. Refresh the page, and you should see the alert box display BEFORE showing the h1 text.
Writing to the Page
We could have written this text directly in the markup, but what if the text changes upon each refresh? Let’s try showing the current date to see dynamic text in action. In the document.write line, replace everything in the parentheses with new Date() as shown below.
<!DOCTYPE html> <html> <head> <title>Title Goes Here</title> <meta charset="utf-8"> </head> <body> <h1>Hello, Galaxy!</h1> < script> document.write(new Date()); < /script> </body> </html>
This displays the current date obtained from your computer’s system time. Each time you refresh the browser, the time will update (usually the seconds).
new Date() creates a date object that can then be used to grab specific parts of the date for manipulation and display. Handling dates, time zones, and time conversions is a lengthy topic, but for now, new Date() will grab the date quickly and easily.
“Does case matter?” Yes.
<!DOCTYPE html> <html> <head> <title>Title Goes Here</title> <meta charset="utf-8"> </head> <body> <h1>Hello, Galaxy!</h1> < script> document.WRITE(new Date()); < /script> </body> </html>
Where Is the Error?
Most browsers include debugging tolls called Developer Tools. Some include them only as an addon or extension. These tools display errors along with a wealth of other information that you can use to evaluate the efficiency of your web page.
In Vivaldi, Go to Tools > Developer Tools to open the tools window. Or, use the keyboard shortcut Ctrl+Shift+I.
Blank lines are counted, but the invalid code should be within tags.
Writing to the Console
<!DOCTYPE html> <html> <head> <title>Title Goes Here</title> <meta charset="utf-8"> </head> <body> < script> console.log('Showing content'); < /script> <h1>Hello, Galaxy!</h1> < script> console.log('All done'); < /script> </body> </html>
You can write debugging messages to the console at different parts of your code to view status information or your making.
If we use document.write() instead of console.log(), the messages appear in the browser window.
<!DOCTYPE html> <html> <head> <title>Title Goes Here</title> <meta charset="utf-8"> </head> <body> < script> document.write('Showing content'); < /script> <h1>Hello, Galaxy!</h1> < script> document.write('All done'); < /script> </body> </html>
If a group of pages, such as ten, require the same script, using , we would have to copy and paste the same code into each of the ten pages. If we need to correct errors (a process called debugging) or modify the code in any way, then we must edit the script found in every page. This is tedious and time-consuming.
document.write('Greetings from beyond the galaxy!'); alert('Even aliens use popups!');
If we refresh index.htm as it is, only Hello, Galaxy! will appear. We must tell index.htm where to find myscript.js in order to execute it.
We use the script element, but the opening and closing tags will be empty. Instead, we use the src attribute in the opening tag. Add this line below the h1 header in index.htm.
< script src="myscript.js">< /script>
The markup should look like this:
So far, index.htm and myscript.js should look like this:
Save all changes in both files and reload index.htm in the browser. Try opening the same index.htm in different browsers. The expected behavior might surprise you!
“Why is this happening?”
To explain why Vivaldi and Chromium showed the popup first while Firefox showed the popup last as written would require explaining how the browsers differ and how they are constructed — topics that enter another realm.
The point to keep in mind is that browsers might render parts of your page differently whether dealing with styles or scripts. There is no guarantee that a page’s appearance or behavior will be exactly the same in every single browser from different manufacturers.
What looks good in one browser, might appear so-so in another. Older browses might ignore features completely. Even modal dialogs appear different in different browsers, and there is no way to change this from within a web page.
“That is confusing and unreliable.”
Welcome to the world of web design. Web designers have struggled with browser discrepancies for years, and there is still no one-size-fits-all, write-once-run-the-same-everywhere solution.
“How can I make a page 100% compatible in all browsers?”
You can’t, but you can get very, very close. You can write a page — HTML, style, and code — so the result is almost identical in every modern browser. This requires hacks and workarounds — especially if you use a bizarre browser called Internet Explorer. Even then, there will still be differences.
The older the browser the worse the problem becomes. So pick a range of browsers to design for, and then fail gracefully for all others. To fail gracefully means to have a fallback plan or a minimal page result so users on older or incompatible browsers can still have some form of functionality to navigate your site.
For example, your fancy navigation menu bar might feature eye-catching, swirling cloud effects rendered using WebGL, but older browsers unable to render WebGL should display a list of plain, blue links instead.
Browsers are adhering to web standards better than before, but there is still room for improvement.
Moral of the story: Do the best you can, but do not expect 100% cross-browser perfection.