[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.
