[MUSIC PLAYING]
DAVID J. MALAN: So by now, you probably understand how the internet
itself works.
And recall that we've discussed how payloads, how packets,
are transmitted from points A to B across the internet.
But we haven't really dived in deep into what's inside of those packets
just yet.
We did make mention that inside of those packets,
if they are being sent by the protocol called HTTP,
is a language called HTML--
a markup language, not a programming language--
in which web pages are marked up-- that is, written.
In other words, when you make a web page,
you have to write in a certain language.
That language is called HTML, HyperText Markup Language.
And it's not a programming language, in that
it doesn't have loops and conditions and functions and so forth.
It's a markup language, in that it has tags.
Tags that tell the browser how to display your information.
Tags that tell your browser how to format information,
and ultimately, how to render a whole web page.
In fact, let's go ahead and do this.
Let's start right off by making our very own web page.
But much like with Scratch, where we had an environment in which
to begin programming, so with web pages are
we going to need some kind of environment
with which to create those web pages.
Now, we could, on a Mac, use TextEdit.
We could, on a PC, use notepad.exe.
You could even use something like Microsoft Word
if you saved it in the right format.
But that would not be generally the best thing to use,
as in the case of programming languages, are
their best tools to use for the trade.
And so we're going to use, in this case, an environment
called CS50 IDE, which is based on an open source
platform called Cloud9, which is a web-based IDE, Integrated Development
Environment.
Now, what does that mean?
That means, much like in the scratch application, where you had a place
to write code and to see code and to run code, ultimately,
so in CS50 IDE do we have that same ability.
But rather than programming with puzzle pieces,
here, we are going to write web pages using this language HTML
and using, ultimately, my keyboard.
So here's what CS50 IDE looks like when you first open it up, perhaps.
You'll see, on the left-hand side, a folder containing
any files that you might have.
And of course, the first time you use the environment,
odds are you won't have any files whatsoever.
In the top here, we're going to have a big area where
we can open up tabs in which to edit the files, like our HTML files.
And at the bottom, we're going to have something called a terminal
window, which we won't necessarily need all the time,
but it's this terminal window that provides you
with low-level access, a command line access,
to the underlying computer, which, in this case,
is a Linux computer running an operating system specifically called Ubuntu.
And long story short, what you have in CS50 IDE is a Cloud-based service.
Someone else out there happens to be running--
in Amazon's Cloud, for instance-- is running
a whole bunch of servers on which you will ultimately have an account.
And within that account can you write files and then
view them on the worldwide web.
So let's make our very first web page.
I'm going to go ahead and do the following.
I'm going to go ahead and create a new file by clicking this plus
and saying new file.
I'm going to go ahead save it as, say, hello.HTML.
And in this file, I'm going to go ahead and do the following.
Open bracket, exclamation point, doc type, HTML.
And then down here, I'm going to do open bracket, HTML, close bracket.
And you'll notice something fancy just happened.
Even though I only typed the first half of that line,
the second half magically appeared.
And that's because CS50 IDE, like a lot of integrated development environments,
will try to finish your thought for you.
It will infer from context what you're probably
going to type after whatever it is you just typed
to try to help you type fewer keystrokes, ultimately.
And indeed, you'll see soon that this was exactly what I
was going to type ultimately.
But first, I want to type a few more things, as well.
Inside of this red tag, so to speak, HTML,
I'm going to do open bracket, head, close bracket--
it to finish that thought.
And in here, I'm going to do open bracket, title, close bracket.
And then a simple title like "hello" comma "world."
I'm going to go ahead, then, and below this head tag,
do open bracket, body, close bracket.
Again, my thought is completed and I'm just going
to write, for now, the same thing--
"hello, world."
Now let's tease apart what, in fact, is going on here.
Well, the very first line of this file is the so-called document type
declaration.
This is just a simple line that you can pretty much copy and paste
that just tells the browser, ultimately, hey, browser,
here comes a web page written in, specifically, version 5 of HTML.
HTML has been around for some time now and humans have constantly been
changing it, have been improving it.
And so we're up to the fifth--
we're up to HTML version 5.
And now here, below that, are a whole bunch
of seemingly red tags, as I keep calling them,
that are sort of like directives to the browser.
Each of these tags tells the browser, really, to start doing
or to stop doing something.
So here on line three, we see open bracket, HTML, close bracket.
This is like telling the browser, hey, browser, here comes that web page
that I promised.
And so accordingly, you might be able to infer now
that on line four, insofar as it says head,
this is like the file telling the browser,
hey, browser, here comes the head of my web page.
The top of my web page.
And then, after that, comes the body, so the rest of the web page.
So much like we humans have heads and bodies, top and bottom,
similarly do web pages have heads, which are generally encompassing the title
bar or the top-most area of the window, and then the body, which is really
the essence of the page itself.
But within the head, notice there's something else.
And in fact, the indentation here implies--
though it's not strictly required--
implies that there's some kind of hierarchy.
So much like the head of the page is inside of the HTML page
itself, so is the title inside of the head of the page.
Now, what is the title of this page?
Well, even if you've never seen HTML before,
you can probably infer that the title of this page
is going to be, literally, "hello, world," our go-to sentence whenever
we need some initial words.
And as for the body of the page, very, very little going on here.
But here we have, in the body of the page, just "hello, world."
So at the end of the day, this is going to be a really simple web page,
but it's going to ultimately say "hello, world."
Both in the title across the title bar, the tab,
as well as in the body of the page itself.
Now, not all of these tags are like the others.
Some of them say open bracket, something, close bracket.
But a few of them have open bracket, forward slash, then the word, then
the close bracket.
So here's a forward slash, forward slash, forward slash, forward slash.
And notice, as the hierarchy suggests, these are symmetric.
If HTML is the first tag that I opened, notice
how it's the last tag that I closed, so to speak.
Or you might say start and end here.
And so together, everything between those HTML tags,
open and close, start and end, is an element-- an HTML element.
And inside of that, of course, are two elements, head and body, each of which
is defined by a start tag and an end tag.
And then the head further has this title element, with its open and close tag.
So not all HTML tags we'll see are going to work quite as symmetrically as this.
Some of them don't really need end tags.
And we'll see some of those exceptions, or you
might encounter some more on your own.
But this general paradigm is really what defines HTML.
It's just some pretty explicit tags that you don't have to write in red.
This is just CS50 IDE highlighting, in red,
those tags so that they stand out vis-a-vis
the actual content, like "hello, world" of your web page.
But you're pretty much, when writing HTML, just telling
the browser what to do and telling the browser when to stop doing that.
Hey, browser, that's it for my title.
Hey, browser, that's it for the head of my page.
Hey, browser, that's it for the body.
Hey, browser, that's it for the web page itself.
Now, what is this thing going to look like, ultimately?
Well, if I open up this file, not in CS50 IDE, per se,
but in an actual browser, like Chrome or Safari or Edge or the like,
I'll actually see the following.
Here, for instance, is a Chrome window.
I've opened up hello.html in this browser window.
And sure enough, notice at the body of the page, do I see "hello, world."
And at the top of the page in the tab is the head,
specifically, the title, which of course, is "hello, world," as well.
But this, of course, isn't all that interesting.
There truly isn't all that much going on in this particular example.
So let's actually begin to use some of the building blocks
that you yourself have seen in existing web pages on the web
and see if we can spice things up just a little bit.
So for instance, the first thing I can think of doing
is maybe writing a web page that has an image inside of it.
So first, let me go ahead and create a new file.
And I'm going to call this one, say, image.html.
And in advance, I've also had the wherewithal
here to spend a little bit of time, as I am want to do,
to download a photograph of a cat from the internet,
which I've called here cat.jpeg.
And my goal at hand now is to spice up my first web page into my second
by embedding in it this cat photo, as you might find elsewhere
on the internet.
Now, to speed things up, I'm going to go ahead and just paste
the contents of that previous page.
I'm going to re-title this as just Image.
But now, in the body of the page, I want to have not text, like "hello, world."
I want to actually have the image of a cat.
And you might be inclined to just do something first like cat.jpeg,
but of course, that's not going to put an image there.
That's literally going to put the letters C-A-T dot J-P-G there,
so I don't want that.
So I probably need some other tag to say hey, browser, put an image here.
So how might I do that?
Well, it turns out that much like there's an HTML tag, a head tag, a body
tag, and more, there is an image tag, though not quite spelled
as you might expect.
Humans like to be succinct, and so instead of calling it image,
it's just I-M-G.
But this, too, isn't obvious yet as to how I
should specify what image to put there.
Well, it turns out that HTML fundamentally supports not
just these tags or elements, but also attributes thereof.
In other words, you can influence the behavior of a specific tag
by passing it, essentially, a key value pair, formatted as attribute
equals quote, unquote, "some value."
And so in this case, it turns out-- succinctly, again--
that the source of my image-- not spelled source, but S-R-C--
should equal quote, unquote, as promised, "C-A-T dot J-P-G."
Now, it doesn't quite make sense to close this tag
and then put something there and then--
rather, to close this start tag, put some words,
and then close the tag itself.
Because the image is really either there or it's not there.
There's really no notion, conceptually, of starting an image,
doing something, and then ending the image.
You either start and end the image all at once,
or you don't put it there at all.
And so I don't want to do this.
I, instead, want to tell the browser, you know what?
This is an empty element.
It has no content, no children, nested inside of it.
And so I can actually put that forward slash inside of the open tag,
but at the very end, just like that.
It's not strictly required, but it should make more clear the fact that we
do indeed have some balance here.
Everything that is opened is also eventually closed.
So let me go ahead and save this, go ahead and open my browser again.
And this time, we see, in image.html, a very grumpy cat.
Now, there are some minor aesthetics here you might notice.
There's this big white border around it.
And that's just because the browser's default is often to put a bit of margin
around it.
We can control that if we want.
But at the end of the day, all this adorable web page
has is an image embedded inside of it.
So what's really going on here now in the context of the internet itself?
Well, again, CS50 IDE is in the cloud, so to speak,
and it is running a web server.
And that web server is what's spitting out these web pages requested via HTTP.
So when I just visited this page, something slash image.html,
that's like my laptop having sent one of those virtual envelopes,
inside of which is a message like, getme image.html, "get"
being that operative, capitalized word or verb, from our discussion
of the internet itself.
And the response that's coming back from the web servers, specifically CS50 IDE,
is apparently an HTML file called, literally, image.html.
And the browser, upon receiving that file,
is showing me not the text inside that file, but rather,
because the browser knows that anytime a file ends in .html,
it should actually parse the file, read it, top to bottom, left to right.
And then show me the rendered version of the page,
the visualization of what that markup is telling the browser to do.
So as before, when the first example was just telling the browser,
hey, browser, print out "Hello, world," now, the web page,
image.html, is saying hey, browser, put an image here,
the source of which happens to be cat.jpeg.
And again, I uploaded, in advance, cat.jpeg to the server.
I could have uploaded any number of photos.
Maybe ones that I took on a vacation or maybe something
that I found, with someone's blessing, online.
But the point is that both the HTML page and that image live on the server.
And so what is the browser actually doing?
Well, let's do this.
Let me go ahead and open up Chrome's Inspector,
as you might have seen before, and then, specifically, the Network tab.
And let me go ahead, then, and reload the page.
And what you'll see is that three HTTP requests just happened.
Specifically, if I zoom in here, the first HTTP request that my browser sent
was for a file called, as we expected, image.html.
And luckily enough, all is well, status 200.
And remember, that is the opposite, so to speak, of 404.
200 means OK, all is well.
So that's good.
And then notice, the browser, pretty intelligently,
sent a second HTTP request to the server saying,
hey, browser, get me cat.jpeg, as well.
Why?
Because the HTML referenced it.
And so this is what's nice about web pages, in general.
You don't have to put everything in the file itself.
Rather, you can reference other files, like cat.jpeg,
and others we'll soon see.
And the browser is smart enough when it parses that HTML file,
reads it top to bottom, left to right.
If it notices the name of other files or other URLs,
it will automatically download those, as well,
so that everything can be displayed all at once.
Now, I don't like the looks of this last one, this red one-- favicon.ico.
It turns out that there's a convention on the web such
that if your server has a file called favicon.ico,
most browsers will display it to the user.
Typically, in the tab these days, so that next to the title of the tab
is also some image that came from the server.
Now, we've not gotten that far.
We've not created our own custom icon as Harvard.edu
might have a Harvard crest up top.
We have no such file, and that's to be expected, then,
that we don't get 200 for that request.
We instead see 403, which means unauthorized,
which is to say the browser can't find the file
and it also doesn't seem to be authorized to even access the file.
Because we haven't even created it in this case, anyway.
And so the browser is just presumptuously, and in some sense,
incorrectly requesting this file now.
But again, it's become convention, if not protocol,
to actually look for this file.
So that, in and of itself, not worrisome at all right now.
Well, let's go ahead and do a couple of more examples
to see what more HTML can do, besides just images of cats on the internet.
Let's go ahead and make an example, this time, involving a link.
Let me make a new file.
I'll call it link.html.
Let me start with the content that we have here,
just so that we don't have to retype it all.
We'll rename, or re-title this page Link.
And instead of having an image like this,
let me go ahead and create our own web page that has a hyperlink,
so to speak, to some other web site.
Specifically, let me go ahead and do this.
Search for "Ahref," quote, unquote.
And now follow along if you could, https://www.google.com/search?q=cats,
close quote, close bracket, cats period.
So a bit of a mouthful.
And I did know what I wanted to type there, so I did it pretty quickly.
But let's see if we can visually parse this and then
look at the result in a web browser.
So in the body of this page is apparently
the sentence, search for cats.
But what's going on there?
So I have just some English here, "search for."
And then notice "cats" is here, and then the period.
But interspersed in that sentence is some markup.
And so, indeed, we can have inline markup, inline HTML,
whereby it's interspersed with actual content or text
that we want to display on the screen.
This tag here here's a new one.
It's the Anchor tab, also abbreviated as just A, probably
because it's just so common.
This is how you make an anchor, or a link, in a page.
Href, a little cryptic, but it means hyper reference.
So this means, to what file or to what URL should this link refer or go to?
And then the URL in question, I kind of made this one up
off the top of my head, though I've used this certainly before.
It turns out that if you search for cats on Google, essentially,
this is the URL that Google ends up bringing you to.
And I've deleted some of the distractions that might otherwise be
the additional parameters in the URL.
But then after the close quote is the close bracket.
And then in white here, C-A-T-S.
So it turns out, this is how you make a hyperlink in a web page.
You have the text of the link here.
Cats is going to be what the human sees.
But in the href attribute do you put the URL to which you want a link.
So there's this duality here.
And now that I've saved the file, let me go over
to my browser and visit link.html, and we'll see a super simple web page.
Indeed, it's super small by default. Up here, search for cats.
But notice, as is the case in browsers, they
tend to have a default color scheme and formatting mechanism for links.
In this case, it's blue and underlined, and so that's very enticing.
Let me go ahead and move my mouse over the word cats
and click and hold my breath.
And indeed, we have a whole bunch of cat search results.
So this really is the essence of the web,
and really, the overarching purpose, originally,
of the web to hyperlinked related resources.
And so I can lead the user from one place to another place on the internet.
In this case, it just happens to be a destination of cats.
Now, we can do so much more.
And indeed, what's exciting about HTML is
that, frankly, at this point in time, we pretty much
know all of the fundamental structures.
There are so many more tags, or elements, that we've not yet looked at.
We'll take a look at a few more, but in general, learning HTML
is much the process of reading up online, looking
at how other web pages are made, and generally, keeping up with the times
as new features are added and new versions of the language
have come out over the years.
But what's important is this fundamental structure
of web pages having a head and a body, having
tags, specifically-- some of which can have attributes--
and closing those tags as is appropriate.
The rest is just building up our vocabulary.
So let's go ahead and take a look at a few pre-fabricated examples
that just hint at the expressiveness of HTML
and some of its additional features.
Voila.
1, 2, 3, 4, 5, 6.
So for some reason, it gets super small by the end of it,
but indeed, that's the purpose of these headings.
So much like a text book tends to have chapters and sections and subsections
and so forth, often which are typically formatted in decreasing size
to sort of convey their decreasing status as a section heading, similarly
is H1 through H6 meant to be used for exactly that kind of purpose,
where H1 is typically big and bold, as for the start of a chapter
or the title of some document, whereas H6 is much smaller, but still boldface,
thereby conveying some semantic meaning, as well.
So what else can we do with HTML besides this?
Well, let's go ahead and open up, say, paragraphs.html,
a web page that follows this same structure, but now has a bit
more content to it?
Specifically, we have the HTML tag, as before, and the head tag.
This time, though, I've been a little proactive.
I've added a metatag.
And there's actually a number of different use cases for these meta
tags.
In this case, it's essentially making this web page mobile friendly.
It turns out, when you make a web page, typically, by default,
if you open it up on an Android phone or an iPhone,
it actually might seem super small.
And not just because the device is small,
but because the web page doesn't necessarily
know that it is being viewed on such a small device.
So via this line here, this meta tag whose name is Viewport,
can I actually proactively tell a browser,
as on an Android phone or an iPhone, to dynamically resize itself somewhat
to make the text bigger, knowing that the device screen is smaller
than it might usually be.
Now, in the body of this page is three new elements, all of which
are the same paragraphs.
And again, abbreviated as P, not paragraph written out.
But indeed, we have an open tag and a close tag,
inside of which is just some placeholder Latin text that
has no semantic meeting here.
But it's just a nice placeholder to show if you
want to have three separate paragraphs, you can separate them
with these paragraph tags.
Let's take a look.
Inside of paragraphs.html is this effect here.
You, indeed, see the line break, as is apparent here,
and you have three of these things total.
Now, it's worth noting the following.
HTML and browsers, in turn, will only do what you literally tell them to do.
So if I do not tell the browser to make three separate paragraphs, as
with this trio of open and close tags, and if I remove those tags,
go back to this web page and reload, notice what happens.
In CS50 IDE, I still had those Latin paragraphs as distinct paragraphs,
such that I hit Enter a couple of times to give line breaks in between them.
But HTML, and in turn browsers, take things very literally.
If you don't tell the browser, put a line break here
or if you don't tell the browser, make this a full-fledged paragraph,
it's not going to for you.
In fact, it's going to look at any white space, so to speak,
any tabs, any carriage returns, any spaces in your web page.
And if you have multiple such spaces in a row,
the browser is typically, by default, going to ignore all of that whitespace
except for just one instance of it.
One space, and not two.
One space instead of multiple new lines.
And so here, everything seems to be blurring together
incorrectly because I haven't told the browser, literally,
what I want it to do.
However, if I restore those tags as they once were, save the file, and reload,
now I have back the three paragraphs, as was intended.
Well, let's take a look at a couple more examples.
For instance, this one here enlist.html.
This, too, similar structure.
So notice the pattern that's starting to emerge.
But this time, in the body of the page, do
I have UL, which succinctly stands for unordered list.
And inside of which is a whole bunch of LI Elements, list item, list item,
list item, inside of which are three arbitrary words
that computer scientists tend to use when they have nothing else to say.
Foo, bar, and baz, much like x, y, and z might be used, by default, in algebra.
And so here, we have in unordered list of three elements
and it's unordered in the sense that it's
going to be rendered by default in a browser,
typically with bullets, one after the other, as opposed to seeing the number
one, then the number two, then the number three, which
would be an ordered list.
So for instance, if I go ahead and open this list.html file,
we should see exactly that--
three bullets, foo, bar, and baz.
However, if I proactively go in here and change this not to an unordered list,
but an ordered list with OL, and then reload the page,
notice that the browser automatically handles the numbering for me.
And this is nice as a feature.
Much like Microsoft Word and Pages and other editors
can do this, too, when you're writing an essay or a document,
so can a web browser figure out for you how much data you have,
and then render or number it accordingly.
Let's look at a slightly more involved example for a table.
Now, the example at hand is kind of arbitrary.
So let's actually look at the result and then work our way
back as to how we did it in table.html.
You might notice on your phone, you have a keypad, typically,
that looks like this.
1, 2, 3, 4, 5, 6, 7, 8, 9, and then some symbols, along with 0 at the bottom.
And this is laid out, it would seem, in rather tabular form.
But how can I get everything to line up in these four rows and three columns?
Well, I can do this with HTML.
Let's go ahead into the file itself and see
if we can't read this top to bottom.
So we have the body of the web pages, as always, inside
of which, now, is a table tag.
So hey, browser, here comes a table.
And then, a little cryptically, here's how it's laid out.
TR stands for table, row.
So this is like saying, hey, browser, here comes the first of my rows.
And then, inside of that is three TD tags, table data.
And this is pretty much like saying, hey, browser,
here comes three columns, or cells, really, within a row.
TD1, TD2, TD3.
We can put it at the top-left, the top-middle, and the top-right.
And then, hey, browser, that's it for the first row.
This close TR tag means that's it for the first row.
And of course, right below that is another TR tag that says,
hey, browser, here comes another row, a second row.
And that's how we get the 4, 5, and 6, the 7, 8, and 9, and then
the star, the 0, and the pound sign.
And so the net effect, to be clear, is this.
So at some point, the nesting can become a little involved
and the pages are getting a little more complex.
But again, if you look at each piece in isolation
and build up this page via baby steps, so to speak-- much
like in Scratch, where you wouldn't want to necessarily implement
a whole program all at once, you want to implement individual features of a web
page one piece at a time-- can you begin to build
up all the more sophisticated examples.
And indeed, let's go there right now.
Thus far, all of these examples have been very static.
Even the example involving the link to some Google search results
was kind of sort of dynamic, but it was someone else's dynamism.
But we can make our web page even more interactive
than just a blue underlined link.
In fact, the most common UI, or user interface, mechanism on the web
is probably an HTML form, something that has a button you can click
or a dropdown menu can choose from, or a text box that you can type into.
I mean, odds are, most every day, you use
some aspect of a form, whether it's to search, whether it's
to submit some information to a web site, whether it's to log in
or any number of other use cases.
So how can we now, using our understanding of HTML fundamentals,
reimplement the super simplest front end interface to something like Google.com?
Can we build our own Google, but use Google's database
so we don't have to build the whole thing ourselves from scratch?
Well, I dare say we can.
I'm going to go ahead and create a new file called search.html.
Just to get me started, I'm going to paste my original "hello, world"
example in there.
But I'm going to quickly start to change it as follows.
Inside of the body of this page, I'm going
to go ahead and use a new tag altogether called form.
I'm going to specify that this form has an attribute of action,
where action is going to be where this form should submit its information.
I know, just from experience, that I can send information to, for instance,
www.google.com/search.
And the method I want to use--
if you recall from learning a little something about HTTP--
is that the method I'm going to use is gets.
A little confusingly here to be written in lowercase instead of all caps,
but it's one and the same.
That same verb that we've seen inside of the virtual envelope
sent from a browser to a server.
Now, inside of this form, I'm going to have a couple of inputs,
one of which is going to have a name of q because it turns out--
as you might have glimpsed from that cat example--
turns out that Google search uses an HTTP parameter, an input in it's URL.
It's called q for query.
The value of which is whatever the human has typed in.
So it turns out I can do value--
whoops.
And the type of this input, we'll see, should be text
because it's something the human is going to type in.
This, as we'll see, is just going to be a text box.
It does not need a close tag, per se, so we'll
keep it an empty element with that slash inside of the very same start tag.
But I'm going to want one other input.
This one is going to be a different type.
It's going to be a button whose purpose in life
is to submit the form by default to a server.
And the value is just going to be, oh, something like search, and similarly
will I close that one.
If I now save that and open my browser to search.html,
you'll see it's a super simple interface.
It's not nearly as nice as Google.
Though, frankly, Google doesn't have all that much more than this.
They just have a little bit more formatting and a little more
color and everything is centered.
But I dare say this is the essence of Google.com's home page, wherein I can
search for most anything on the web.
This is a text box and so I'm going to move my cursor over that.
And this time, let's make a more interesting result
so it doesn't all look pre-fabricated.
Let's go ahead and search for dogs this time.
So I've typed in this input to the text box.
I'm now going to click the other input, which, again, is a Submit button.
Click Search, and voila.
I have made a web page that somehow submits information that the user has
typed in to another web page.
And if I look at the specific URL that I'm now at, as by going out of full
screen mode, notice that the URL I'm at is indeed www.google.com/search?q--
for query-- =dogs.
And so this is what's powerful about understanding
these fundamentals of HTTP and, now, HTML.
You can begin to reconstruct so many of the familiar features that we've seen.
And indeed, though there's a lot more complexity
visually on a web page like this, you can
start to imagine, perhaps, how Google is structuring things underneath the hood,
or how your favorite website is actually built in HTML.
I mean, maybe this is some kind of paragraph here and another paragraph
here.
These blue links, they lack underlines, but maybe they're still hyperlinks.
Because I certainly know, from experience,
I can click on these search results and end up at other web pages.
So it would seem that there are ways to customize the aesthetics of a web page
so it doesn't look quite as boring as all of my own examples thus far.
And now over here, clearly, there's a whole bunch of image tags,
it would seem.
So here, too, Google's using some of these same fundamentals.
But they've got a lot of experience.
They've spent a lot of time laying everything out.
So there's certainly a more rich user experience here.
But we can learn even from their experience.
In fact, as before, and let me go to Chrome's Inspector by right-clicking
or control-clicking on the web page itself.
And instead of going to the Network tab, let
me stay on the Elements tab, which is typically the default.
Now, there's definitely way more tags and attributes here than we've seen.
But let me go ahead and just zoom in on this.
And you'll notice what Chrome and other browsers
are really good at doing is parsing HTML,
and not only showing you the web page, as we
were seeing a moment ago with all the dogs,
but you can also see what's going on underneath the hood.
And even if Google's HTML source code, so to speak,
is really a mess and maybe there's very little indentation--
very little whitespace, such that it just looks like a big blob of text--
Chrome and other browsers will pretty print it for you and even syntax
highlight it, so to speak, using these disparate colors that
aren't in the file itself.
It's just being displayed as such so that the tags and the attributes
and the text all jump out separately.
And even though Google is a pretty well-oiled machine,
notice that they, too, just use the same fundamentals that you, perhaps,
now understand all the better.
HTML tag, head tag, body tag.
Some tags, for sure, we haven't seen yet.
Div, which is a generic container, a rectangular region of the page,
called the division, that you can then style, as we'll see, as you see fit.
No script and script.
This has to do with actually adding programming
code in a language called JavaScript.
More on that in just a bit.
And then if we scroll down further, we'll
see more and more content down here.
A lot of divs in their particular page.
But we can zoom in on any of these elements
and actually see-- for instance, let's do this.
This second link here, "Dogs from Animal Planet."
Let me control-click or right-click on that, click Inspect.
And what's really cool is that Chrome and other browsers
will immediately jump to that element in the page.
And notice, we can infer how this page is structured.
Besides all these divs, which are just, again,
creating these rectangular regions, notice here's an H3.
So that's one of those medium-sized headings that Google is using.
Inside of here is Ahref.
And now notice, this is kind of a crazy long URL.
But it turns out, if I click that URL, it's going to redirect me
to "Dogs on Animal Planet."
It doesn't seem to be AnimalPlanet.com, though, which is a little suspect.
I do see AnimalPlanet.com here, but notice,
there's all this craziness up front.
Well, it turns out that often, though not necessarily always,
companies like Google are actually going to monitor what links you're clicking.
So in a simple world, this href would just be AnimalPlanet.com/dogs
or whatever the URL is.
But no, this URL, as implied by this slash at the very beginning,
is actually referring to Google's own servers.
So even though you might think, OK, Google knows what I searched for,
but they don't know what I'm clicking on because they don't have a partnership
with AnimalPlanet.com, perhaps.
Mm-mm.
Even when you click these Search results are
you sometimes going to find yourself going back to Google
and then ending up at AnimalPlanet.com.
It just happens so fast, you don't realize that Google just
logged what you clicked on.
Now, why would they do that?
Why add this intermediate step between you and the destination you care about?
Well, one, analytics.
Two, making search results better.
Three, advertisements, potentially.
In any of these cases, Google is gleaning more information
from your behavior because now, they know they just
showed you 10 results relating to dogs.
If you clicked on the second result before you clicked on the first result,
maybe the results weren't that good.
Maybe, for subsequent visitors who also want to search for dogs,
maybe they should start showing the Animal Planet link first instead
of the actual first link that you saw.
And so here, there can be a nice feedback loop.
But again, realize there's a privacy implication.
But by understanding HTML works, and by understanding
the simplest of tags and attributes, can you
deduce for yourself, what is going on and are you,
indeed, comfortable with such yourself?
Now, Google's web page is, of course, so much more visually interesting
than any of the things I've done thus far.
And that's in part because they're better designers,
but also in part because they're using a language we, ourselves,
have not looked at yet.
It turns out that intermingled in HTML--
in many, if not most, web pages today--
is another language called CSS, cascading style sheets.
Now, what does this mean?
Well, it turns out that though we focus on the canonical web page looking
a little something like this--
with tags and attributes and actual text,
for instance-- it turns out that there's some other tags we haven't yet seen,
but that Google and others are certainly using.
One of which is the style tag, which can go in the head of the web page,
alongside the title.
And it's with this style tag that you can actually
implement some fancier aesthetics.
You don't have to just go with the blue, underlined default links
that a browser typically gives you.
You don't have to just go with big, bold, black text for H1
and small, bold, black text for H6.
You can override those settings, as well, just like Google apparently
has with their H3 tag.
It turns out, too, you can also embed these styles
not in the web page itself, but in a second file.
But we'll get there in just a moment by way of these examples.
So let me go into CS50IDE, and let me go ahead
and open up CSS0.html, CSS, again, denoting cascading style sheets.
And let's take a look at this example.
It's a pretty simple web page for a guy named John Harvard, who
has three components to his web page.
And there's many different ways I could implement this page,
but I've tried to mark things up, so to speak,
in a semantically-compelling way, in a self-descriptive way.
So this web page, inside of the body, has three main sections.
One called Header, one called Main, one called Footer.
And I didn't make those words up.
It turns out, in HTML5, there are these and yet other tags
that you can use to structure your page and actually
provide hints to the browser as to what is the main part of the page.
What is the header of the page, not to be confused with the head of the page,
and what's the Footer of the page.
These three things-- header, main, footer--
all belong inside of the body of a web page, as per the definition of HTML.
But notice what I've done, and it's not great practice,
so we're going to have to clean this up.
But notice, in the header of my page, I have John Harvard
as the owner of this home page.
In the main portion of the page, it says, "Welcome to my Home Page."
And at the footer, it's got his copyright, John Harvard 1636
or whatnot.
Now, what do you see that's different here?
Well, odds are, a new attribute is jumping out at you.
Style.
And notice, this is, indeed, an attribute.
It's not a tag that we saw a moment ago, foreshadowed in the CSS example.
So we'll come back to the distinction there in a moment.
But you can perhaps infer what this style attribute is doing.
As the name suggests, it's styling the HTML elements,
so it's changing the aesthetics of it from the default.
And you can probably infer from this green or yellowish text
that the first header has a font size of large, whatever that means,
and the text alignment should be centered.
Meanwhile, the main part of the page should have a medium font
size, also centered, and the footer should
have a small font size, also centered.
So let's look at the spoiler.
What is the net effect of all of these attributes?
Well, it's to create a web page that's arguably the nicest of the ones we've
done thus far.
Still pretty simple.
But we have here, John Harvard.
It's pretty big.
Welcome to my home page, kind of medium.
Copyright John Harvard is a little smaller.
So three relative sizes, but all of them are centered.
So it turns out, what we have just done and what
you have just seen is an example of CSS, cascading style sheets.
Specifically, these are CSS properties, the format of which
is some property name, literally a colon, and then the value thereof.
And if you want to have multiple properties, multiple key value
pairs, so to speak, you just separate them by semi-colons.
And just for good measure, and for symmetry,
I kept a semi-colon on the end.
It's not strictly necessary, but this way, all of my properties
has the same structure in all six of these distinct locations.
So that's kind of nice that it follows this pattern,
but it's also a little messy in that, now, I've got HTML, I've got English,
and I've got CSS.
It's all just kind of getting very sloppy, I would say.
And there's also some redundancy here, right?
If you take a look at these three styles, there's a commonality to them.
Text align center, text align center, text align center.
Wouldn't it be nice if we could somehow factor that out and not type it
identically three separate times?
Indeed, there is.
If I open up a slightly different version here,
CSS1 now, notice the page is structurally the same,
but I've cleaned it up a little bit.
And how have I done that?
Well notice, I'm leveraging some inheritance, so to speak,
in so far as the body tag is a parent, so to speak,
of header, main, and footer.
It's a parent conceptually, in that header, main, and footer
are all inside of that element before it's closed later on down here.
But aesthetically, too, it's imperant as per my indentation,
that it's also a child, too.
It's indented inside of the body tag.
Though, again, the browser doesn't care about indentation.
All this indentation and nice, pretty spacing is just for us
humans to better visualize things.
But what's key is that I factored out this commonality up here to a style
attribute on my body tag.
And in so far as that is the parent of these three children elements-- header,
main, and footer--
that text align center now applies, by the definition of CSS,
to all of those children.
So I've cleaned things up a little bit.
Now if I want to left align or right align my text,
I just change it in one place and not three places.
And that's representative of the kind of thought process and design
process that goes on.
Never write something three times, let alone copy/paste something three times,
if you can design it better and factor that out and write it, for instance,
in just one place.
But we can do better.
In fact, I am not loving how I am now co-mingling my data, my text in English
here, with my metadata like main and footer and header, and the stylisation
thereof.
One, this feels messy that I'm co-mingling my data
with the presentation of it, so to speak.
Two, it's going to make it harder for me to work with a colleague, who
has a much better sense of design than I,
and it would be really nice if he or she actually
wrote all of the CSS properties-- deciding
on the font size and the colors and the spacing and the alignment--
and just let me assume that they will take care of that much more beautifully
than I could.
And three, it just makes it really annoying to maintain.
Because now, if I want to change the aesthetics of my web page,
I have to go searching through my file, which, for fancier web pages,
it's going to be much longer than this relatively short file.
And it just doesn't feel very maintainable, so to speak.
So let me propose CSS2--
our third version, zero index, to be clear--
where I've done the following to the HTML.
I've kind of reworked it.
And you'll see that there's no mention of CSS, per se, now.
Notice, instead, I've introduced a new attribute, which also exists in HTML5,
called class.
And class is a way of defining groups of one or more CSS
properties that can apply to any number of tags or elements in a web page.
So for instance-- and I could've named these things anything
I wanted, but I came up with what I think
are pretty compelling, pretty semantically appropriate
names for these classes.
Body is going to have a class of centered.
Header is going to have a class of large.
Main is going to have a class of medium.
Footer is going to have a class of small.
Again, could have called that foo, bar, and baz, x, y, z, but none of those
would really be descriptive.
So I've instead invented classes called centered, large, medium, and small.
And I deliberately chose large, medium, and small
to line up with the font sizes.
But also, just conceptually, I want it large, then medium, then small,
so it flows conceptually, as well.
But what is centered, what is large, what is medium, what are small?
These are words of my own creation, technically, here.
I need to scroll up to see what these classes actually look like.
Notice here, now, is that style tag, not attribute.
In the head of my web page is a style tag,
inside of which now are four keywords--
.centered, .large, .medium, and .small.
And the dot is deliberate.
So as odd though it is, the dot signifies
that this is the name of a class.
So class equals quote, unquote something corresponds to dot something
when defined up here inside of the style tag.
Now, you can kind of read what's going on here.
The only piece of new syntax, really, is these curly braces,
which we have seen in other programming languages, perhaps.
So .centered has the following group of properties.
Text align center, semi-colon, so just the one.
The large class has a font size of large.
The medium class has a font size of medium.
And the small class has a font size of small.
And that's it.
If I now go into this web page in a browser and open it up,
aesthetically, it's still exactly the same,
but now it's better designed, arguably.
But you know what?
This creation of classes doesn't even feel necessary because, notice,
I already have uniquely identifying words in my web page.
Again, to be fair, this is a pretty simple web page,
so I'm kind of getting lucky here.
But notice that if I already have a tag called header that completely
encapsulates John Harvard, and main already exists, and footer already
exists, this feels kind of lame that I also
need to come up with three arbitrary, but descriptive words like large,
medium, and small just to stylize these tags which already have unique names.
So it turns out that with CSS, cascading style sheets,
you don't have to use just style attributes or a style tag with classes.
You can also select, so to speak-- select being an operative word
in the CSS world--
you can also select elements by way of their name,
not just some class on them.
So in fact, let me go ahead and do this in our final example here,
or our fourth example here of CSS3.
And you'll see, in this file, that I've now removed the class altogether.
Now this web page is getting really, really tight.
I am only using as many characters or words
as I strictly need to make this web page happen.
And honestly, just at first glance, look how much more readable
the page is without these longer lines, without all the style attributes.
Now the data in the page, the content--
John Harvard, welcome to my web page, copyright John Harvard--
is really jumping out at you.
And yet, we're still styling it in fundamentally the same way,
but this time, using a different selector.
If I scroll up to the top here, notice now,
I don't have any mention of the dot, I just
have the word "body," which corresponds to the HTML tag called Body.
I have the word "header," corresponds to the HTML tag header.
And main and footer, the properties inside of which are exactly the same.
But I haven't introduced unnecessary overhead of classes.
Classes have value.
They do have value, especially if you want to reuse them elsewhere
and your web page is more complicated than mine.
But the key here is that even though we have all of these building blocks,
we don't want to necessarily build the biggest web page we can.
It's often compelling to build at least close to the smallest web page
if that lends itself to better readability-- just easier for me
to read it and understand it.
If that lends itself to better maintainability--
if I and a colleague can now collaborate on this because there are just fewer
distractions, and there's fewer lines of code to maintain and fewer lines
of code to potentially make mistakes in--
all of this is pretty compelling.
But what isn't really compelling is how I'm still
kind of co-mingling my CSS properties with my HTML.
Indeed, in this and many contexts in the world of technology, computer science,
and programming, there is this generally accepted practice
that you want to separate your data from your presentation.
The contents of this web page have nothing
to do, fundamentally, with the bold facing, the font sizing,
the coloring of that actual content.
That should all be kept separate for any number of reasons, one of which
is just, again, the maintainability of it,
long-term, and the cleanliness of the files.
So as per our canonical example a bit ago,
in CSS4 do we introduce this other tag that you might have just glimpsed
called Link, which remarkably confusingly, is not a hyperlink.
It is the way in which you tell a browser to load another file--
a .css file, typically-- that contains your CSS properties to be applied
to this file.
So it's not a hyperlink.
That's the Anchor tag, the A tag, as before.
But the link tag in the head of a web page allows you to specify this.
An href, which references the file you want to include.
Again, not link to, but pull in.
And then the relationship, which is stylesheet.
So theoretically, this link tag could be used for any number of things,
but we most commonly see it used for style sheets.
So I've pretty much just written this verbatim,
and then changed the name of the file that I've created.
And the file I created in advance, just to keep things named similarly,
is css4.css.
Let's open that file, css4.css.
And in this file, do you see, pretty much, the exact same contents
of our previous example, but no style tag, just
the text of that CSS selector, body, and its property with the curly braces.
And then the same for header, main, and footer.
So the end result is, if I open up css5.html,
just like 0 and 1 and 2 and 3 do we see exactly the same thing.
But again, the progression here has been toward better and better, or cleaner
and cleaner, design of the otherwise correct content.
All right.
So we've only scratched the surface of the actual tags that exist in HTML,
and the actual properties that exist in CSS.
But again, we've covered the fundamentals.
What the structure of a web page is, what
the structure of a CSS property is.
And so, from here on out, filling in the blanks
really amounts to looking at an online reference, a printed book,
looking at existing web sites, googling as needed for answers to questions.
Because what you now hopefully have in your toolkit
is a fundamental understanding of what a web page is, how you can structure it,
and how you can go off and continue to add features.
But at the end of the day, these pages still, with this tool kit,
remain pretty static.
You know, we have kind of some dynamism, in
so far as we can send users to other websites that
might look much better than mine, and we can send users input,
even if something like Google and like Google's database
provide more information for the user from its own search engine.
But wouldn't it be nice if we could have a little more interactivity
on our own website?
And wouldn't it be nice if we could make sure
that the user has typed something incorrectly before we just blindly send
it over to some server?
And it turns out that even though HTML is not a programming language-- again,
it's just a markup language that tells a browser how to render information.
It doesn't have logical constructs like loops and conditions
and variables and more.
And just as CSS, too, is not a programming language
because it, too, lacks those capabilities, for the most part,
there's another language that we can introduce here.
And indeed, the front end of the world wide web, so to speak,
what you and I as humans see, is typically
composed these days of a trio of languages.
HTML and CSS, and the third is JavaScript.
If you've heard of the language Java, no actual relationship,
it's simply similarly named.
But JavaScript is the de facto standard for web browsers
when it comes to writing programs that run not on the server,
but in the client's computer, so inside his or her own browser.
And this is what makes it a little different from languages like C and C++
and Java, pretty much, and other languages, still, like Python and Ruby,
which are typically-- though not necessarily-- executed server-side.
In a browser, JavaScript is the language to which you have access.
And so how do we go about writing programming code in a web page?
And frankly, why would we want to do that?
Well, let me go ahead and open up this example here.
Dom0.
DOM stands for Document Object Model.
And before we actually get into how this code works,
let's look at what this code does.
In dom0.html is, quite simply, this form.
I'm going to go ahead and click Submit.
Oops, nope.
I'm going to go ahead and type in, say, my name and click Submit.
And oh, my god, it says hello, David.
That's amazing.
It's dynamic.
It literally said what I typed in.
Well, OK, David wrote the page, so maybe this isn't all that compelling.
So let's try another.
Let me go ahead here and type in, say, a colleague like Zamyla's name.
Submit.
Oh, my god.
It supports Zamyla, as well.
Now, maybe I wrote the web page and just I added support for David and Zamyla.
But no, this is actually a generalized solution
to the problem whereby, much like I could do in Scratch or C
or Python or other languages, this web page is getting user input
and then producing output on the screen dynamically.
It's a little cryptic, in so far as it displays
in this ugly pop up on the screen.
And frankly, the browser is asking me if it
wants me to prevent this page from creating additional dialogs.
Because you might remember the yesteryear where the pop-up windows
were all the rage on the internet.
And indeed, browsers have gotten smarter about blocking those and actually
asking you, hey, wait a minute, this page is putting up a number
of prompts-- two, in this case--
are you sure you want to let it keep doing this?
But that's just a feature of the browser.
And that window will look different in Firefox and Chrome
and Edge and Safari and other browsers still.
But how does this work?
This is just an input and this is just an input.
And previously, these inputs whisked me away to Google.com,
where I saw a whole bunch of dogs as search results.
But now, I'm not going to Google.
I'm certainly not seeing any cats or dogs.
I'm instead seeing David's name and Zamyla's name
and anyone else's name that I type in.
So how is that working?
How is, somehow, the web page grabbing the data that I've typed in
and doing something with it?
Well, it's doing this by way of, yes, some HTML in the page,
but also, now, some JavaScript.
And to get to this point, let's introduce the following.
This is the Document Object Model, or DOM.
Which is just a fancy way of saying this is the family tree like structure
that you can think of as being underneath the hood of any web page.
There has been, since the start of our examples,
an implied hierarchy to all of our web pages.
Besides the doc type declaration up top, there
has been this so-called root element, HTML,
inside of which there's always been two children, head and body, inside
of which there were zero or more other children, like title.
And the indentation and the nesting implies
that there is some kind of hierarchy.
It reads from left to right, but really, if you flip that around 90 degrees,
and again, think of HTML as the head, all of these other tags
are kind of conceptually below it, a la a family tree.
And indeed, if you think of this being the document itself,
like the file, the root element of which is HTML, this thing here, HTML, again,
has two children, so we can kind of dangle those off like you would
a family tree, two descendants, head and body.
Body, meanwhile, just as some text-- "hello, world"-- and I've drawn it,
or circled it with an ellipse here, just to kind of convey that this content is
not like this.
These rectangles are elements, open and close tags.
This is just text at the very leaves of this tree.
Meanwhile, head does have another child, title,
as per the rectangle, in then it, too, just has some raw text,
like "hello, world."
So you can think of, that is to say, a web page as yes, being hierarchical,
but also as being a tree.
And if you recall, among the data structures
in a computer scientist's toolkit, is this thing called
a tree that can look quite like this.
And there might be more than this many children.
It might have more than two children still.
But there's this way of representing in a computer's memory,
or ram, exactly what's being sent to the browser over the internet as just text.
So upon receiving an HTML file, when I say
a browser is reading it top to bottom, left to right, that is true,
but it is also building up, in its own memory, a data structure that
looks quite like this in RAM, in memory, so that the browser can
navigate that web page as needed.
Now, why might it need to navigate the web page?
Well, once you introduce JavaScript does it
become really compelling to be able to look at not just
the raw text, but the individual nodes, so to speak,
the rectangles and ellipses in the tree.
But we need to introduce this tag here, the script
tag, where we can put our JavaScript code in the head of our web page here.
But we'll see this can go in different places.
Here then, is dom0.html.
At the very top of the body, notice, is a tag we've seen once before, form.
But notice it's got a new attribute we've not seen, on submit.
And you can kind of guess what this means.
On submit, do the following.
But what's the following?
Well, notice that inside of quotes here is some funky-looking syntax.
And if you've programmed before, you might recognize these
as being a function call and then a return statement.
But what does that mean?
Greet, it turns out, is a function, an action, a verb.
It's a puzzle piece like, say, for instance, in the world of Scratch.
And return false just means don't do your default behavior.
So jumping the gun, what is the default behavior for a form on the internet?
Even as we've seen it before and as you've certainly used it before?
Well, it's to submit whatever you've typed in to the server.
You're registering for a web site, you click Submit, goes to the server.
If you're logging into a web site, you click Submit,
it should go to the server.
You're searching for dogs on the internet, you click Submit,
it should go to a server.
By saying return false here, this means, don't send anything to the server.
Keep the user locally to our HTML page.
And that's the goal of this particular demonstration.
So what are the inputs for this form?
Well, one is called name, and its type is text.
And the other is of type submit.
And I've added another attribute here just to make things prettier,
called placeholder.
And this is how you get some gray--
literally, placeholder-- text that the user sees kind of as instructions.
Now, what is greet and what is going on here?
Well, let me scroll up to the top.
But before I do, realize that per this attribute,
on submit, when this form is submitted, the greet function should be called.
The greet action should be taken.
The greet puzzle piece, if you will, should be executed.
So what is the greet action?
This is a function that does not come with JavaScript,
doesn't come with browsers.
I invented it up here inside of this open and close script tag.
Notice that, per the purple word, function, greet is indeed a function.
And now I'm using this built-in other function called alert.
This does come with JavaScript.
This does come with my browser.
It doesn't create very pretty alerts.
It's what creates that ugly dialog window we saw a bit ago.
But when I say alert, notice this cryptic-looking string of code.
And for today's purposes, it suffices to know the following.
So quote, unquote, "hello" comma, space.
Is going to print exactly that on the screen.
So quote, unquote, and whatever's inside is
going to get displayed on the screen.
The plus is a little funky here.
It's not for arithmetic or addition.
It is for concatenation.
This is telling the browser, hey, browser,
print out the word "hello" comma, space, and then append to it--
concatenate onto it-- the following.
And this one is a little more cryptic.
document.getElementById quote, unquote, "name" dot value.
It's kind of a mouthful, but let's think about what's going on here.
Document is a special object, a special variable-- a global variable,
if you will--
inside of which is a whole bunch of functionality
that comes for free with your browser.
Some of that functionality-- another action--
is called getElementById.
Well, what does that mean?
Element-- we've heard this term before-- refers to an HTML tag,
or really, the open and the close tag and everything inside of it.
Name is in quotes here, so that probably has some special meaning.
More on that in a moment.
And then .value is probably the value of that element, whatever that means.
So what is name?
Well, let me scroll back down lower in the file.
And notice what's going on down here.
I took care earlier, when defining this input,
to give it not just a type and a placeholder,
but a unique identifier called name.
Could have called this anything-- foo, bar, baz, x, y, z-- but again,
none of those are very descriptive, so I called it name.
And this is important because I knew, preemptively, I
want to be able to get at that element directly
and I don't want to confuse it with any other,
so I want that identifier to be unique.
And I want to be able to get its value.
Its value being whatever the human typed into that input box.
And so because I have ID equals name here, and because I'm saying hey,
browser, get the element whose ID is name.
And then hey, browser, go get its value.
This is the way that my browser is dynamically going into the DOM--
the document, that tree structure--
finding the element in that DOM whose ID is name.
And then looking inside, hey, browser, what did the user type in?
And so what comes back is D-A-V-I-D or Z-A-M-Y-L-A,
or whatever the human has typed in.
And that gets, again, concatenated on to the end of this partial phrase.
What gets concatenated onto the end?
Well, here's another plus.
Here's a quote, unquote exclamation point.
So this was just my way of making the alert friendly.
Hello, David!
Hello, Zamyla!
We have three separate substrings, or phrases, being concatenated together.
So hello, comma, space, whatever the user's name
is, and then that exclamation point.
And then some of this other stuff, like the parentheses
and the semi-colon, these are just features of the language itself,
JavaScript.
This is some of the syntax that scratch, for instance, does not have,
but some languages, like C and Python and C++ and Java,
do have some other syntax like this that is sometimes necessary.
But for now, let's focus really on one of the most fundamental ideas, which is
a browser's programmatic capability--
ability to do something by programming-- to get at data inside of a web page.
And it's doing that not by searching the web pages HTML.
Because again, the HTML that comes from server to browser is this.
There is no mention of David, there is no mention of Zamyla,
inside of this file.
That is dynamically provided by the human user
once this web page has been rendered.
And D-A-V-I-D and Z-A-M-Y-L-A is this text that ends up being stored
in the tree structure, the DOM structure,
that code like this in a language called JavaScript allows us to access
on demand.
Now, much like we improved, iteratively, the design of our CSS,
let's similarly do a bit of that refinement using JavaScript, as well.
Let me open up DOM1.html and propose a somewhat different solution
to the same problem.
Notice in this example, I again have the form element as before.
But I've also added one other unique identifier.
And again, there's different ways I can do this.
I have chosen to use IDs, but two this time, whereby
I've given my form a unique identifier.
Again, could call this ID x, y, z, foo, bar, baz-- anything I want.
I only have one form in the page, so I decided to keep things simple,
and I just uniquely identified the form as form.
But even that isn't all that compelling.
But it's at least specific.
So now, if I scroll down to the script element,
notice that this time, the script tag is below the form.
It's not in the head.
It's actually in the body toward the very end of my body,
below the form itself.
And notice somewhat new syntax here.
So this line here, you can perhaps reason
through what it's doing, although it's a little bit of a different approach.
document.getElementById quote, unquote "form."
So as before, this just means hey, browser, give me the HTML element whose
unique identifier is form.
So that refers, of course, to the one form.
And then, this is a new property.
Before we used value.
Now I'm using on submit.
So it turns out that there is a property in the world of JavaScript
associated with an HTML form that you can access by way of this syntax.
So this is a way now of saying hey, browser, associate
with the on submission of this form the following function.
And again, a function is just a puzzle piece that is a call to action.
It's just a verb.
It's a set of instructions that you want to be executed.
This function doesn't happen to have a name, but that's fine.
The curly brace here and the curly brace here just
mean this function is two lines long.
What does this function do?
Does the exact same thing.
Notice this alert line is exactly the same,
and notice that I'm returning false down below here, so as to short circuit
the submission of any data to a server.
I'm handling all of this inside of my current web page.
So what have I done that's different now?
Well, notice, just like I iteratively improved my CSS,
and I removed from my HTML any mention of CSS properties-- which, again,
just felt like it was getting messy to co-mingle these multiple languages--
so have I, with this example, taken a step of removing from my HTML any
mention of on submit relegating this other language--
JavaScript, this time-- to be inside of its own tag.
Previously, it was the style tag for CSS.
Now, it's the script tag for JavaScript.
But I've taken a step toward separating my data from my presentation,
and now from my logic or business logic, my programming code.
And I've specifically, as an aside, put the script tag below my form tag.
Because it turns out, browsers, as fancy as they might seem,
are pretty dumb, in that they only do what they're told,
and they only do it in the order in which they're told,
top to bottom, left to right.
And so if I were to try to call this code, whereby I'm associating
this function with the submission of this form,
if I tried to put this code up here, mm-mm, it
wouldn't work because the form doesn't exist yet.
Only once the browser has read, from the top, through this portion of the file
does that form exist in its memory-- in the DOM, the data structure, the tree
that it's building up.
At which point it then makes sense to associate
this JavaScript function, this event handler,
so to speak, with that particular element.
So this was deliberate.
But again, that's a finer detail than is fundamentally necessary to,
perhaps, follow along here.
But just as we did with CSS, whereby we completely separated our presentation
from our data by moving our CSS to a secondary .css file,
so can we leverage that same principle here and completely separate the logic
of our code from the data that it is accessing by relegating the contents
of this script tag, essentially, to another file, something ending in .js,
for JavaScript, by convention.
And indeed, in dom2.html do we have a file that does exactly that by moving
to the head of the page, in this case, the script tag-- dom2.js--
inside of which is not only those lines, but a couple of others
that ensure that even though the script tag is in the head of my web page
right now, it is ultimately going to be executed later,
once the whole DOM has been rendered.
Alternatively, we could also move this script tag to the bottom of the page
still.
All right.
But this is not a particularly common case,
to visit a web page that asks you to type in your name
and then it just says, hello, David, or whatever your name happens to be.
I mean, typically, when we have seen programming code being
used in a browser, it's for pretty fancy features like actually checking
that I've typed in all of the fields to a form when registering for a website
or making sure, when I am registering for a website,
that both of my passwords actually match.
And yet other applications still with JavaScript.
So let's take a look at a few other examples,
these involving actual forms that are meant to be submitted.
For instance, here is form0.html.
In this case, notice that I have an HTML form that
doesn't have an action or a method because I
actually, for demonstration purposes, don't really
want this to be sent anywhere.
In fact, there is nowhere to actually send it
because I don't have the backend of a database to store this information.
All we care about is this front-end.
And notice I'm asking for a few things.
The email of the user, their password, their password again, and then I
want them to agree to some terms and conditions.
And so we'll see a few new features here of HTML forms.
Not only do we have a text box, as we've seen before for their email address.
Turns out, there's also type equals password that's still just a text box,
but if you've ever noticed why password boxes have bullets or dot dot
dots instead of seeing your actual password, just for privacy sake,
this is how that actually happens.
This one, too, for the confirmation, is also of type password.
But notice, I've given it a different name.
The name of the first field is email, second is password,
third is confirmation, but I could have called
it password two or something else.
And then, lastly, I agree to the terms and conditions.
Notice, it's of type checkbox so that it's something
the user can click on and off.
And I'm just calling that arbitrarily, but reasonably, agreement.
And then lastly, I have a Submit button, whose value or label is register.
And then, this is very simplistic formatting.
I'm just using line breaks.
BR is the line break element.
So it doesn't give me a full-fledged paragraph,
as would be appropriate for sentences of text.
It just makes sure that each of these things ends up on a new line, the line,
therefore, being broken with BR.
All right.
So what opportunities are there for validation, so to speak?
Form validation being the buzzword here.
And what mistakes, in other words, might a user make?
Well, they might not type in one of these fields.
And I want them to do something with all four of these.
So I could check, did the user fill out the whole form?
The user might type their name or an invalid email
address because of some typographical error, they forgot the at sign
or they misread what they're supposed to type.
So maybe there's an error there.
Password, maybe it's too short.
Maybe it doesn't have enough letters or numbers or punctuation
or all those annoying things that websites typically
impose for security's sake.
Maybe they typed the password fine the first time,
but they made a typo the second time, so they don't match.
And the website wants to make sure, when you're
registering, that you remember what your password is.
And if you typed in two different ways, unclear
which one should be your actual password,
so we might want to check for that.
And then, of course, because of our lawyers or whatever,
we want to make sure that the user checks that check box.
And so we want to make sure that the human took
that deliberate action of making an unchecked box
checked before they click Register.
So a bunch of juicy opportunities to actually validate the user's input.
There are no validations in this file.
There is no JavaScript in this file.
This is just HTML.
So if I click to register the Submit button on this page, what I typed
or what I didn't type would get sent to the server, blank or not.
So I want to add some logic to this and I
want to see how you might go about implementing this kind of logic.
So let's look at form one, which is a addition to this file of the following
lines.
Again, the particulars here won't necessarily matter in great detail.
Take away from this the overarching principles
that we're now applying via this intersection of JavaScript code
and the web page's DOM, Document Object Model, its tree.
First line of code in my script tag here is
to get, from the document, the element whose ID is form, just as before,
and it refers to the one and only form in the page.
Then I'm doing form.onsubmit, so this is a little more succinct than last time.
But you can infer from this, well, if you have a variable-- as in algebra, x,
y, or z, but in this case, it's called form--
and I'm associating with it's on submit listener, we'll call it,
the following function, this is just a very succinct way
and JavaScript of saying hey, browser, when that form is submitted,
execute the following lines of code, the function.
And there's a bunch of lines.
There's not just two this time.
It's a dozen or more.
So what are these lines doing?
Well, here, you'll find that each of these chunks of code
follow pretty similar structure.
If the forms, email fields value equals quote, unquote-- so nothing--
if the user typed in nothing, alert the user,
you must provide your email address.
And then return false to make sure that the form does not get submitted.
Now, there's some weirdness here.
One, parentheses.
Two, double equal sign.
Not a typo.
Long story short, in many programming languages,
equal actually means copy a value from one side of the expression to another.
Equals equals means check for equality.
So it just turns out that the same symbol
is used for two different things, so they separated them semantically
with double, in this case.
So that's how we check that these are actually
typed in his or her email address.
What if we scroll down here?
Same kind of validation, but for a different field.
If the passwords value is blank, yell at the user, you must provide a password.
If the passwords value does not equal the confirmations value--
so if those two password-related text boxes are not the same--
an exclamation point equals sign means not equal.
So there isn't really a way on your keyboard easily to type
the equal sign with a slash through it.
So what most programming languages do is an exclamation
point, which typically means not or invert, equal sign,
so it does not equal this.
So if the password does not equal the confirmation thereof, yell at the user,
passwords do not match, and then return false.
And then down here, lastly, this one, too, is a little cryptic,
but it gives you a taste for what's possible.
If it is not the case, per the exclamation point, that the form's
agreement checkbox is checked--
which is a Boolean expression, if you will, as per our time with Scratch--
if it is not checked, then yell at the user,
you must agree to the terms and conditions.
And so this represents the checking that the user has actually checked that box.
So there's any number of other things we can do.
And there's any number of ways we could implement this same kind of code.
Indeed, we could use the libraries, code that other people have written,
to make this much easier so we don't have to implement all of this ourself.
And it turns out we're still going to have to
and we're still going to want to implement these same kinds of checks
on the server, just in case a user slips by
and maybe their browser doesn't have JavaScript enabled or something.
We're still going to want to validate all of this data server-side.
But for the most dynamic, immediate experience,
checking things in the client using JavaScript code
allows the user to get an instant feedback before he or she even clicks
the submit button and sends the data to the server, which, especially
on a mobile device, can take some time.
It's not nearly as immediate as actually running some programming
code in the browser.
But if all of these tests pass, notice how
this last line is return true, which means hey, browser, submit
the form to the server.
And again, I didn't configure this example with an actual server,
so it's still not going to go anywhere.
But it would if we actually added an action attribute
and a method attribute to the form as a result of this return true.
Now, of course, this might all look pretty cryptic.
We've dived in pretty deep quickly to not only HTML and CSS,
but now we're using a third language to actually manipulate that whole world.
But realize that JavaScript, though the syntax of it
might be a bit cryptic at first glance, and while some of this
might not have gone down so easily, realize
that the ideas that are possible within this world of JavaScript,
in this domain of web pages, is really not all that different from Scratch.
For instance, recall that in Scratch, we had this adorable purple puzzle
piece, by which you could say, quite simply, "hello, world."
Well, in JavaScript, as we've seen, you can still say the same,
but it's a little more cryptic.
The syntax is, of course, textual and not graphical.
But at the end of the day, the functionality is essentially the same.
Alert, open parenthesis, quote, unquote, "hello, world," close parenthesis,
semi-colon.
So again, there's absolutely some syntactic overhead there.
There's definitely some complexity, textually.
But the idea is exactly the same.
Recall, too, that in Scratch, if you wanted to do something forever,
you might pull out the forever puzzle piece, inside
of which might be one or more blocks that you want to execute forever.
Well, in JavaScript, we can implement this same idea
using this block of code, while true alert "hello, world."
Different ways to do this.
And indeed, alert is really just for the context of a browser.
There's other ways to do this in, say, the context of a terminal window
or a black and white prompt.
But in this case, this is the JavaScript way of saying to do something forever.
If you, instead, want to do something not forever,
but a finite number of times, like 10, you
can translate the Scratch blocks above to the JavaScript code
below, using keywords like var and more semi-colons and a less than sign
and the like, but this is a so-called for loop,
as opposed to the earlier while loop in JavaScript.
So syntactically, more involved, but fundamentally, the same idea.
Meanwhile, if in Scratch, you wanted to assign a variable like counter,
initially, the value is 0.
And then forever just print it and then increment it by 1.
In JavaScript, at right, you could do the same with a bit new syntax,
combining some of these same ideas.
And then if you wanted to do something conditionally in Scratch,
you might borrow an if else block and then another if else block,
so as to nest them inside of each other to create a three-way fork in the road.
You can do the same in JavaScript using some code like that at right there.
Now, we have only scratched the surface here of JavaScript 2.
But much like some of our takeaways thus far have been with HTML,
can we mark up a document on our data for presentation.
With CSS, can we stylize that presentation,
getting the colors and the font size and the thickness and the positioning just
the way we want it, just right.
So with JavaScript can we do all that and more because with JavaScript do we
have programmatic access to the DOM-- the Document Object Model,
the data structure, the tree--
that represents that web page in memory.
And though we have just used JavaScript here
for some relatively simple examples, whereby
we grabbed the values from the DOM and we
checked those values in order to validate them,
so could we actually dynamically change the color of a web page
or the positioning of something on a web page,
or even add new content to a web page.
Indeed, by way of JavaScript or other technologies
like Ajax, which allows you, with JavaScript, to make
HTTP requests on the internet for more data
so that you can then embed more data on your web page.
For instance, if you've ever used Facebook Messenger
and you're noticing that you get a chat message and another chat message
and another chat message from one or more friends,
you're still staying on the same web page.
You don't have to reload the page in order to see your new messages.
They just dynamically appear.
That is because Facebook is using JavaScript that's constantly
running, as in a forever loop, and it's constantly asking the server,
does David have more messages?
Does David have more messages?
And if so, it injects them dynamically onto the page
by manipulating the DOM for Facebook's own site.
Similarly, if you're a Google Chats user or Google Hangouts
and you're getting dynamic output that way,
similarly as JavaScript, creating that dynamic experience.
If you use Google Maps or Bing Maps or any number of mapping tools, whereby
you initially see maybe your location in the world,
but you can click and drag and search for other places around the globe
and then immediately see tiles, or map pictures,
of where those places are in the world, that is thanks to JavaScript.
Because, as in the case of searching and validating a form,
so are all of those map-based web sites listening for your textual input
and, as soon as you hit Enter, searching their database for the result
and then updating the contents of the page in real time,
sometimes with the fanciest of animations,
which are also the result of JavaScript and perhaps some CSS.
So it's with this trio of languages, HTML and JavaScript and CSS,
ultimately, that you can create some wonderfully immersive user
experiences and wonderfully immersive user interfaces.
But we haven't necessarily considered with too much detail
what kinds of devices users are using.
We did give some thought to friendliness on mobile devices,
at least so far as it goes with font sizing,
but we haven't really given any thought to offline access to data, if that's
indeed something we want to support.
We haven't given some thought to this scalability
of our websites and our code, so that if we have not just one user, like me
here, but 1,000 users or 10,000 users or a million users,
what are the implications for my server?
What are the implications for my code?
If my code is just a little bit slow, does it now
begin to feel slow for all of my users and, in turn, of my customers?
So now that we have the ability to put code on the internet and the ability
to put web pages on the internet, now we're
going to have to start to give some thought as
to how to put them on the internet well and in a scalable way,
in a redundant way, in an available way.
But for that, we first need to make a number of choices
around the languages we use on the server, the frameworks or libraries
that we use, and indeed, what technology stacks we deploy.