[MUSIC PLAYING] DAVID J. MALAN: This is CS50.

And today, we transition from the

world of C and, with it, pointers and some of the struggles that you might have
felt over the past few weeks to a more familiar world, that of web programming. I'm
using web browsers and mobile devices and laptops and desktops and creating more
graphical and more interactive experience than our traditional command-line
terminals have allowed. And we'll see, though, along the way that a lot of the
ideas that we've been exploring over the past few weeks are still going to remain
with us. And we're going to see them in different ways. We're going to see them in
the form of other languages and other syntax. But the ideas will remain quite
reminiscent of what we did back in week 0. So TCP/IP is perhaps the most technical
way and the most low-level way we can quickly make the web uninteresting. But
you've probably, at least, seen this acronym somewhere, maybe on your Mac, your PC,
some setting maybe once upon a time. And this, actually, just refers to a protocol
or, really, a pair of protocols, languages of sorts that computers speak in order
to transmit information from one computer to another. And this is what makes most
of the internet today work. The fact that you can pull up your laptop and desktop
and talk to any computer on the internet is because of these protocols, conventions
that humans decided shall exist some years ago. And they just dictate how computers
intercommunicate. But let's make it a lot more familiar. In our human world, you've
probably, at some point, sent or received a letter. These days, it's perhaps more
electronic. But, at least, you've gotten one such letter from probably a human,
maybe a grandparent or the liked, or sent something yourself. But before you can
actually send that message to the recipient and put it through the US mail or the
international mail services, what needs to go on the envelope? AUDIENCE: Address.
DAVID J. MALAN: Yeah-- so some kind of address. And what does an address consist
of? AUDIENCE: Name. DAVID J. MALAN: Name. AUDIENCE: Where they are. DAVID J. MALAN:
Where they are. AUDIENCE: [INAUDIBLE] DAVID J. MALAN: So where they are might
include a street address and a city, a state, a ZIP code in the US, or a postal
code, more generally, and the country, if you really want to be specific. And so
all of that goes on the front of the envelope, generally in the center of the
envelope. And then what often goes on the top left-hand corner in most countries?
AUDIENCE: The return. DAVID J. MALAN: Yeah. So the return address-- so that if
something goes wrong, albeit infrequently, that letter can get-- make its way back
to you, and also the recipient knows just immediately who actually sent them the
no. So that is enough information to get a letter from point A to point B because
these addresses, these postal addresses in our human world, uniquely identify
houses or buildings or people, in some sense, in the world. So right now, we're at
45 Quincy Street, Cambridge, Massachusetts, 02138, USA. That is probably enough
specificity for anyone in the world to mail us a postcard saying "Hello world" in
written form and get it to this building. Meanwhile, if we wanted to send something
to the Science Center, 1 Oxford Street, Cambridge, Mass, 02138, USA, that's its
unique address. So it stands to reason that computers, including our own Macs and
PCs and Android phones and iPhones and the like, all have unique addresses, as
well, because, after all, they want to communicate. And they need to get bits,
zeros and ones, from point A to point B. But they're not quite as verbose as those
kinds of addresses. Computers have what you probably know as IP addresses, Internet
Protocol addresses. And this just means that humans decided years ago that every
computer in the internet is going to have a unique number identifying it. And that
number is generally of the form something dot something dot something dot
something. And, as it turns out, each of these somethings between the dots is a
number from 0 to 255. And now, after all these weeks of CS50, your mind can
probably jump to a quick answer. How many bits must each of these numbers be taking
up if the range is from 0 to 255? Eight. So eight-- and why is that eight? So 256
has been a recurring theme. And if you don't recall, that's fine. But yes, this is
eight bits, eight bits, eight bits, eight bits, which means the numbers that we
humans use to uniquely identify our computers on the internet are 32 bits in total.
Well, there's probably another number that can roughly come to mind. If you've got
32 bits, how high can you count, roughly speaking, from 0 to-- I heard a murmur--
AUDIENCE: Four billion. DAVID J. MALAN: Four billion. So it's roughly four billion.
And we brought that up in week 0 with a four billion-page phone book, imagining
that. So four billion is roughly what you can count up to with 32 bits. So that
means there can be four billion computers, devices, or anything on the internet,
uniquely identified-- small white lie because that's actually not quite enough
these days with all the devices and all the humans in the world. But we found
workarounds for that. Question? AUDIENCE: [INAUDIBLE] DAVID J. MALAN: But only half
of them at the time. No. So yes, if by 2023 or whatever year humans are projected
to be almost entirely online, and there's some-- billions and billions of people,
eight billion or so, then that's a problem for this system. Thankfully, as long ago
as 20 years ago did people realized, mathematically, this was going to be a
problem. And so there's actually a newer version of IP, Internet Protocol. This is
version 4 we're talking about, which is still pretty omnipresent in the world.
Version 6 actually uses not 32 bits, but 128 bits, which is massive. And I can't
even pronounce how big of a number that is. So we're thinking about it. And the
biggest companies of the world have already transitioned to using bigger addresses
rather than these 32-bit addresses. But these are still pretty common in almost any
device you might own or see on campus or elsewhere. So if you have a unique
address, that's enough to put on the front of the envelope. And it turns out that
if you're sending an email or a chat message or whatever, you, too-- your Mac, PC,
or phone-- has an IP address. So that's enough to put in the top left-hand corner,
conceptually. But you need one more piece of information. It turns out that on the
internet, there are servers, computers, that are just constantly listening for
people to connect to them, like us, checking our email and visiting Facebook and
Gmail and other such websites. And those servers, though, can do multiple things.
Google has lots of businesses. They give you email and web services and video
conferencing and lots of other internet-based services. And so humans also decided,
years ago, to identify all of these possible internet services with just unique
numbers-- names also, but also unique numbers. And it turns out that humans decided
years ago that when you visit a website, there's one more piece of information
that's got to go on this envelope, not just the server's IP address that you're
trying to connect to, but also the number 80 because 80 equals HTTP, acronym you're
surely familiar with by now. And that just denotes this is a web request. If,
instead, it said something like 25, that's SMTP, which is email. So that might mean
inside of this virtual envelope is actually an email message going to Gmail or the
like. And there's bunches more numbers. But the point is that there are numbers
that uniquely identify. So when Google gets a virtual envelope, just a whole bunch
of bits, zeros and ones, that, in some way, has an IP address on it as the
destination, it also knows, oh, is this an email or is this a video conference
message or is this a chat message or something else. So just to make this more real
then, if I'm going to go ahead and write this down, my IP address to whom I'm
sending something might be 1.2.3.4. Generally, then, I'm going to send it to, say,
port 80. Maybe my IP address is 5.6.7.8. And so an envelope-- I'll be at
[INAUDIBLE]---- and it's really just going to have those pieces of information--
the destination address, colon, and then the number of the service you care about,
HTTP or whatever, and then your own IP address, and more information. But the point
is both sender and recipient in dresses-- that's enough to get data from one
computer in the world to another. And there's so much more complexity. This is a
whole field in computer science of networking, if you like this kind of stuff. But
that's how, in a nutshell, the internet gets data from point A to point B. And this
envelope just represents a whole bunch of zeros and ones. But what's inside of that
envelope? And that's where we'll focus today and in the weeks to come. It's
actually content. It's the email you care about or the web page you care about. And
how do we actually decide what server we're connecting to? Well, typically, you
might go to a so-called URL, Uniform Resource Locator. A URL is just the address of
a server. And that's going to be the-- really, the ultimate recipient of that
envelope that we're trying to send. But this, of course, is not an IP address. This
does not follow the pattern something dot something dot something dot something. So
if all of us humans are constantly typing stuff like this into our browsers, yet
the whole story just told is about numbers and port numbers and low-level stuff,
where's the connection? Does anyone already know how you get from typing this to a
bunch of zeros and ones that are somehow addressed with numbers? DNS, I heard.
What's DNS? Yeah. So it turns out there's a technology in the world-- domain name
system, in fact. And DNS, Domain Name System, is just a type of service on the
internet that Harvard maintains and Yale maintains, and Comcast and Verizon and a
lot of the big players in the world, whose purpose in life is to run servers that
convert what are called domain names to IP addresses, and vice versa, so that when
we humans type in www.example.com into a browser, it's our Mac or PC or phone that
contacts a local server, a DNS server, on the local campus or university or
apartment or whatever, asks what is the IP address for www.example.com. And then
what your Mac or PC or phone does is it writes that address on the envelope. But it
puts a request for specific web page inside of the envelope. And when you get back
a response from that server, it's going to be your address that's on the front of
the envelope. And inside of the envelope is going to be the web page or the email
or the chat message or whatever it is you were trying to actually access. So let's
tease this apart into some of its components. First of all, this thing here
highlighted in yellow is officially the domain name. You've probably all used this
term before. It's usually something dot something. "Com" typically refers to
commerce or commercial, although anyone, for any purpose, can use .com. Back in the
day, very popular were .com, .net, .org, .edu, .gov, .mil. And these were all very
US-centric because it tended to be the United States that really kicked off this
use of the internet and DNS. But now it's certainly spread globally. And so there's
hundreds now of what are called TLDs, Top-Level Domains. They tend to be three or
more characters if they denote a word. And they tend to be two characters if they
denote a country, like US is United States, JP is Japan, UK-- United Kingdom, and
so forth. Those are just country codes that do the same thing. But what's this at
the front? Worldwide web, or www, here, more generally, is an example of what,
technically speaking? What is this? What does this mean? Yeah? AUDIENCE: Subdomain.
DAVID J. MALAN: It's a subdomain-- is one way of thinking about it. In fact, all of
you, many of you here, probably have email addresses of the form
college.harvard.edu or g.harvard.edu or the like. Those are subdomains. Harvard's
such a big place that they actually put everyone in different categories of
domains, otherwise known as subdomains. And that might be a word or a phrase that
comes before the domain name here. But it can also just mean the name of a server.
So if example.com is the company or business whose website you're trying to visit,
their domain is example.com. And they bought that domain name some years ago. And
they spent a few dollars every year, probably, renewing the fee for that. And they
have at least one server whose name is www. And that exists within their domain.
They might have dozens or hundreds or just one server. Each of them can have a
name. So this is generally called the hostname. So when it's an email address, it
often implies a subdomain, like a category of addresses. But when it's in a URL
like this, it means probably a specific machine or a specific set of machines--
conventionally, the web servers that the company runs-- doesn't have to be called
www. For historical purposes, MIT tends to use web.mit.edu. But almost everyone
else in the world uses www or nothing at all. It's not required. You can actually
just visit many websites without visiting any hostname. And it just works, as well,
thanks to DNS giving you the IP address. But what about the file you're actually
requesting? What does it actually mean to visit this URL? Well, on many servers,
this implicitly means, hey, web server, give me a file, just a text file, called
index.html. That's the name of the file, a text file, that you could create with
CS50 IDE or even Notepad or TextEdit on your own Mac or PC that contains a language
called HTML. And we'll take a look at that language in just a bit. And some of you
might have seen it before. But the language in which web pages are written is HTML.
And we'll give you the building blocks, conceptually and practically, for that
today. You'll use it over the coming weeks in many different contexts. But we'll
use it, ultimately, to create the contents of websites. But today, we'll focus
first on this, HTTP. Anyone know what that stands for? Yeah? AUDIENCE: HyperText.
DAVID J. MALAN: Yeah. HyperText Transfer Protocol. And honestly, in most of
technology, it's not so much what the acronyms represent that's all that important,
but, really, what the technology does. And in this case, HyperText Transfer
Protocol-- we'll see hypertext in a moment. That's another way of saying HTML.
Transfer Protocol-- P for Protocol-- that's another buzzword. So protocols are not
programming languages, per se. They are conventions. And we humans have
conventions, too. For instance, if I were to meet someone for the first time, I
probably wouldn't stand on stage and lean down like this to do it. But I might say,
hi, I'm David. AUDIENCE: Hi. I'm Stephan. DAVID J. MALAN: Stephan, nice to meet
you. And we have this weird handshake that was aborted prematurely there-- that we
have this weird convention-- us humans, at least in the US, of greeting someone
with a handshake. And Stephan just knew to do that, however awkwardly. And then he
disengaged because the transaction was complete. And that's not unlike what a web
server does. When you request a web page, you're sending a request to someone as
though you're extending your hand. You're expecting something in return. But in the
case of a computer, of course, it's like the web page itself coming back in an
envelope from point B to point A. So that's what a protocol is. We just have been
programmed to know what to do when we want to request a greeting or information and
get something back in return. It's like a client-server relationship in a
restaurant. A customer requests something off the menu. The server, the waiter or
waitress, brings it to them and, thus, completes that transaction as well. And
that's what the internet is, too-- clients and servers, browsers and servers,
computers and other computers, ultimately. So with that relationship in mind, let's
take a look at what's actually inside of this envelope. In the case of Stephan's
and my greeting, it was more visual. But in the case of a computer, it's going to
be more textual, literally. So inside of the envelope the, virtual envelopes, so to
speak, that your browser sends to a server when trying to request a web page, is
actually a message that looks like this. Thankfully, it's not terribly cryptic,
although the dot, dot, dot implies there's more contents inside of the envelope.
But the keyword here literally is gets, a verb. And there's other verbs that the
browser can use. And this one literally means, get me the following home page. What
home page you want to get? Well, the default one. This forward slash, as it's
called, just represents the default web page on a website. And in many cases, that
implicitly means an actual file called index.html, just a convention. It can be
called other things and not exist at all. But in many cases, that means,
implicitly, get me a file called index.html. And we'll see what that looks like in
a moment. Http/1.1 just means, hey, Stephan, I speak HTTP version 1.1. Hopefully,
you do as well. There can be other and newer and older versions of the same thing.
Notice down here, though-- whoops-- notice now here, though, that the hostname is
also in this envelope because it turns out that web servers can do multiple things
at once. And they can serve multiple domains. You don't need your own personal
unique server to serve a website. You can have tens, hundreds, thousands of
different websites all on the same server. And if any of you ever paid for your own
domain name or your own personal home page or the like, you are probably paying
someone for shared space on one server or more servers, not for your own personal
dedicated one. But again, this might implicitly mean the same thing as this. Give
me index.html. So what is it that actually comes back from the server? The server,
hopefully, responds with a message that looks like this. It responds with
confirmation of the version of the protocol it speaks. That's like Stephan saying,
yes, I speak HTTP 1.1 as well. 200 is a numeric code that signifies literally OK.
All is well. I understood you. Here is the information you requested. And Content-
Type, below it, is a more technical way of saying, the type of content I'm handing
back to you in my own envelope from point B to point A, or from Stephan to me, is
in a language called HTML that happens to be text. Why does it look like this?
Humans, years ago, just decided that this would be the sequence of characters that
computers literally send to communicate that information. So let's actually try
this in one case, maybe, for instance, with harvard.edu, and see what actually
happens to see what else we might see. So let me go ahead and open up Chrome, or
any browser, for that matter, that supports some kind of debugging and diagnostics.
And I'm going to do this. And you can access this in different places. I'm going to
go up to View, Developer, and View Developer Tools. This is something that comes
with Chrome. You sometimes have to enable it in Safari and other browsers. But
almost every browser these days has this capability. And you'll notice that this
just opened up a whole bunch of tabs at the bottom of my screen here that I'm going
to be able to use to actually explore what is-- did I kick something else?
Apologies. It's back-- won't step on there. So what is this going to allow us to
do? Well, notice there's a lot of features here. It's overwhelming at first glance.
But there's a tab here called Network. And it turns out that one of the features
Chrome gives to developers, which you now all are-- is software developers-- is the
ability to see
what's going on underneath the hood of a browser, to see what is inside of these
virtual envelopes that your browser has all those years been sending from itself to
servers elsewhere. So I'm going to go ahead and do this. I'm going to go ahead and
actually visit http://harvard.edu and hit Enter. And you'll see a whole bunch of
stuff happens, including the web page appearing at the top of the screen. I'm going
to ignore all of this stuff at the bottom except for the very, very first request.
If I zoom in on this, notice that highlighted in blue here is the very first
request, harvard.edu. And if I click on that, I'm going to see a little more
information at right. And if I go scroll down to what are called request headers,
the lines of text that were inside the message that my browser sent, this is
literally what my browser sent inside the envelope, unbeknownst to me, when I
visited harvard.edu. Thankfully, it confirms my prediction earlier, get/http/1.1,
because I requested harvard.edu's home page. Host is harvard.edu. Then there's the
dot, dot, dot, the stuff that we don't particularly care about today. But let me go
ahead and look at the response. So this was my request. This was my hand going out
to Stephan. Let's see what his or the server's response is by scrolling up to this,
which is called response headers. Harvard's server, fortunately, does speak the
same protocol as me, 1.1 of HTTP. But apparently, Harvard moved permanently. What
does that mean? I went to http://harvard.edu, not there. Where is it? Well, there's
a little more information here. There's a lot of dot, dot, dot, things we don't
care about. But if we focus on one that-- oh, location-- where is Harvard now,
apparently? Yeah, say-- AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Yeah. It looks like
Harvard "moved" permanently from http://harvard.edu to, and let me highlight it,
https://www.harvard.edu, with two notable changes. One, there's the www. And two,
there's also what that might catch your eye? S, which most of you probably know
these days means secure, and which implies encryption in the spirit of Caesar and
Vigenere, but much more secure than those simple ciphers. The information is
somehow scrambled now when I'm communicating between myself and harvard.edu. So
there's two decisions there. Harvard has decided that they want to allow and,
indeed, require users to visit their website securely so that no one-- no company,
no government, no family members-- can necessarily see what is being requested of
Harvard's website because that is scrambled information, much like using something
like Caesar or Vigenere. And Harvard also, probably for branding reasons, but also
partly for technical reasons, decided, we want you to think of our website as
www.harvard.edu. And it's a mix of marketing and technical for a few different
reasons, one of which is www we humans just all know means website. And if you see
harvard.edu-- this is less true these days-- might not necessarily imply as
obviously that this is a websites URL. Frankly, not too many years ago, even
advertisements and TV ads and printed ads and the like would even show http:// to
really make clear to viewers that this is a web address. But gradually, as more and
more people get on the internet and understand technology and URLs and the like, we
can just start dropping the stuff that is unnecessary clutter because all of us now
know intuitively, oh, harvard.edu-- it's probably a web address that I can just
type into a browser. And the browser or the server will finish my thought for me
and actually prepend the secure URL or the www or the like. So we still haven't
actually found Harvard, it seems. So let's do this instead. Let me go ahead and
zoom out and visit a different URL. Let me go ahead and, again, go to View,
Developer, Developer Tools, Network Tab. And now let me visit that more verbose
URL, more precise URL, and hit Enter. Again, a whole bunch of stuff gets
requested-- more on that some other time. But now, if I click on the first such
request and look at my response headers, you'll actually see, albeit in a different
format now, that the status of this request is 200, which, recall, meant--
AUDIENCE: OK. DAVID J. MALAN: OK. OK. So now these are two numbers that, honestly,
you've probably not really seen or cared all that much about, 200 and 301. But odds
are you've seen at least one other number when visiting URLs. For instance, besides
actually seeing 200 and 301, you've probably seen 404. Now, it apparently refers to
Not Found. But more in real terms, what does that mean? How do you induce that
error? AUDIENCE: The site doesn't exist. DAVID J. MALAN: The site doesn't exist.
You mistyped a URL. The web page doesn't exist. A system administrator just changed
the name on something or it's an old URL. Any number of reasons can mean that the
file was not found. That file might have been index.html or any other URL. But all
this time when you visited a website and you've seen 404, it's not clear, frankly,
why servers have been bothering to tell us 404. Most people don't need that level
of information. But it derives from that HTTP response, that first line of text
inside the envelope coming back from Stephan or the web server, more generally,
that says 404, Not Found. And that means the user probably did something wrong or
if the data has simply disappeared from the server. And there's so many more of
these things as well. And in fact, you might get responses, like we just did from
Harvard, supporting not just 1.1, but version 2 of HTTP. So just realize if you
tinker with your own Mac or PC, the messages might look a little different based on
your browser and the website. And that's just because things are evolving over
time. And versions are changing. But there's so many others of these. And this is
just a short, abbreviated list. 200 and 301 we saw. 404 you yourselves have
probably seen. 401 and 403 generally refer to you haven't logged in or you're just
not authorized to access information because it doesn't belong to you, for
instance. 500 you're all going to experience before long-- that 500 is Internal
Server Error, which is not so much the server's error as your fault and my fault
when we've written buggy code. So in the weeks to come, not this week, but when we
start writing Python code and SQL to talk to databases, we're all going to screw up
at some point. And a browser will often see a 500 error from a server if, indeed,
there's a problem with code. 418 doesn't actually exist. This was a April Fools'
joke, I think, in, like, 1988, where some people with a lot of free time wrote up a
whole formal specification for an HTTP status code, a 418, I am a teapot. And it's
still kind of exists in lore, internet lore. So those are just some of the numbers
you might see. But they're not all that technical if you just know where to look
for them and you know, as a developer now, what they signify for you. Yeah?
AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Good question. What's the difference between
200 OK and 302 Found? So 302, if you read into the documentation, would actually
tell you that this also induces a redirect, whereby, just like 301, when the
browser gets a 301 or a 302, the browser should be redirected to the new URL that
we saw in the header, so to speak, called location, colon, whatever it was. The
difference is that Moved Permanently means that the browser should remember that
this redirection is happening and stop bothering the server with the same original
quest. Just remember what the new URL is. 302 means found it, but don't rely on
this. Keep asking me again and again. So it's just a performance optimization so
you don't annoy the server unnecessarily in the case of 301s, which just costs time
and money, in some sense. So you might have heard about this before-- can only get
away with this Cambridge, not so much New Haven. Has anyone ever visited
safetyschool.org? AUDIENCE: Hey. DAVID J. MALAN: You're welcome to on your laptop
or your phone. So some very clever Harvard students, I think, years ago bought this
domain. Frankly, they've probably been paying, like, $10 or more per year ever
since just to keep this joke alive. But it's wonderfully illustrative because if we
go back to Chrome or any browser-- and let me go ahead and open up a browser tab
and go to safetyschool.org, Enter. Oh, interesting. Where did I get redirected?
AUDIENCE: Hey. DAVID J. MALAN: Hey. So the more interesting question for us is, how
are they doing that? Well, let me go back into the IDE for a-- or actually, let me
go into my browser and open up a new tab-- View, Developer, Developer Tools. Look
at the Network tab. And now let me go ahead-- whoops-- let me go ahead and visit
http://safetyschool.org. Enter. Scroll back up to the top, where I see the first
request. And you can see, more technically, if this doesn't take the fun out of the
joke, all these Harvard students did years ago was configure this domain name to
return a 301, Moved Permanently to Yale University. Now, it's only fair, especially
since the Yale students are watching this live right now from New Haven-- let's
take a look at one other site called harvardsucks.org. So this domain, too, does
exist. Let me clear that screen and go to http://harvardsucks.org. Enter. And this
is an actual website. So not only did these enterprising Yale students buy the
domain name, they've also been hosting the website for years since. There's a
wonderful YouTube video there that actually speaks to a very fun hack that they did
some years ago at Harvard-Yale, the football game. But you can see here, oh, that--
so there's a minor one. So harvardsucks.org actually now lives at
www.harvardsucks.org. But then you actually stay there. And so I encourage you to
go to this site, as well as the other, for all your Harvard and Yale shopping
needs. So that is HTTP.
HTTP is the protocol, the set of conventions, that browsers use when talking to
web servers. And it's the protocol that governs how those web servers respond to
the browsers. We've quantized this in the form of these virtual envelopes, which is
just a physical incarnation of the zeros and ones that are technically going back
and forth across the internet. But it's embodied in my handshake with Stephan,
what's really happening. I initiate. He responds. And it's like a client-server
type relationship. So how do you actually now do creative work? How do you make
yale.edu? How do you make harvardsucks.org? How do you make CS50's own website or
Google or Facebook? Well, what really matters now what's-- is what's deeper inside
of that envelope. In addition to these headers, this textual information, like 200
OK or 301 Moved Permanently, there's another language embedded inside of that
envelope, deeper down, called HTML, HyperText Markup Language. This is the
language, which is also text, in which web pages are written. And so if you've ever
visited a website on the internet, and I just noticed that Erin is doing that on
repeat, isn't she, what's-- you're looking at is a browser's rendering of HTML. So
HTML is just text. And we're going to see it in a moment. The browser reads that
text top to bottom, left to right, much like Clang reads your C code top to bottom,
left to right. But rather than convert your text to zeros and ones, what a browser
does is interpret it line by line by line. And it does what you say. So if you say,
hey, browser, put Erin's photo on the screen, it is going to do that. If you say,
hey, browser, write the words "staff" in big black text, the browser's going to do
that. If you tell the browser to lay out a whole menu, it's going to do that. And
we'll see, in just a moment, how you convey those terms. HTML is not a programming
language. It is, indeed, a markup language, which means it just lays things out
structurally and aesthetically. So the website here that we're looking at has a
bunch of images, all of which are what are called animated GIFs, which are very
much in vogue these days on Reddit and phones and iMessage and the like. But those
are just images, files, that are actually being transferred from CS50 server to
your browser. But if I go up to View, Developer, and now View Source, and you can--
could have been doing this all these years-- you can actually see the so-called
HTML that drives CD50's website. So this is all of the HTML, and I'm deliberately
scrolling fast through it, that implements that CS50 staff page. And if we scroll
all the way to the bottom, you'll see that 1,008 lines later is the web page done.
But it's just text. And, in fact, let me scroll back up to the top and just point
out a few salient details. You'll see familiar patterns in the examples we're about
to start looking at. The very first line probably is that, DOCTYPE HTML, which is
like a little hint to the browser that says, quite explicitly, hey, browser, the
document type you're about to see is indeed HTML. But the rest of the web page
follows a structural pattern. And you'll see that it's already nicely indented,
even though some of these lines are a little long and are wrapping. But you'll see
this convention, an open bracket, which is an angled bracket, like a less than
sign, the keyword html, maybe some pattern like this, lang equals en-us-- this
sounds like language-- a US English, maybe-- more on that in a bit-- and then this
close bracket, or a greater than sign, that completes the thought. Then inside of
that HTML tag, so to speak, indented beneath it, is this, the head of the web page.
The head of the web page something that you mostly can't see. It generally refers
to the tab at the top of the page and just invisible information. And if I scroll
down further, we'll see, really, the guts of the web page, which are in the so-
called body of the web page. So these things that I've just been highlighting,
albeit in a very big context of a big, 1,000-line web page, are just called HTML
tags. HTML is a tag-based language, a markup-based language, where you just say
what you want to appear where you want it to appear. So what does that actually
mean? Well, let's take a look at a simpler example in the form of this slide, which
is perhaps the simplest web page that you can make, this one here. This is perhaps
the simplest correct, syntactically correct, web page you can write that's saying,
hey, browser, the type of document is HTML. Hey, browser, here's the start of my
HTML page. Hey, browser, here's the head of my web page. Hey, browser, here comes
the title of my web page. Hey, browser, the title of this page shall be, for the
sake of discussion, "hello, title." But you could say literally anything there that
you want. But now things get interesting. And some of you have certainly seen HTML
before, and some of you haven't. But you can probably just infer, even if you
haven't seen HTML, what this tag is doing because it looks the same, but yet a
little different. So if this is saying, hey, browser, here comes the title, what is
this probably saying, intuitively? AUDIENCE: Just ends. DAVID J. MALAN: Yeah.
That's it for the title. Hey, browser, that's it for the title. So you might call
this a start tag and this an end tag, or an open tag and a close tag. Think about
it however you want. But in HTML, there's generally this nice symmetry. Once you
start something, you eventually finish it. And you do it in the right order. So you
do-- you start tags in one order. And then you close them in reverse order so that
everything is nicely symmetric. And indeed, the indentation, just like in C,
technically doesn't matter at all. You could have a really, really ugly web page
with no whitespaces whatsoever. And it would still work fine for the browser
because it doesn't care-- just much harder for us humans to read. So this
convention is to indent, just like in C, just so it's more clear what the hierarchy
or the nesting is, so to speak. This line here means, hey, browser, that's it for
the head. It's another close tag. Hey, browser, here comes the body of the page. So
much like head here, body here, most of the page's content is, indeed, in the body
of the web page. That's what you, the humans, actually see. And mostly in the head,
we'll just see things like the title and just a couple of other things in a little
bit. The message inside this web page is apparently, "hello, body," then close
body, close html. And that's it. So when I said earlier that inside of these
envelopes is just a whole bunch of text, all I meant was this. This is what's
inside of this envelope just below the protocol information, the HTTP information,
that just said 200 OK or any of those other messages. So when the browser receives
this envelope, it opens it up. It reads it top to bottom, left to right. And then
it literally interprets that file top to bottom, doing exactly what you tell it to
do. So how do we go about actually doing this? You can write HTML on any text
program. You can write it in TextEdit, on a Mac, on Notepad, on a PC. You can,
technically, use Microsoft Word or Google Docs. But that's out of context and bad.
Those give you features you don't want. But you generally want a text editor. And
we, of course, have a text editor in CS50 IDE. So let me actually go there. I'm
going to go into CS50 IDE. And I'm going to go up to File, New. And I'm going to go
and preemptively just save the file with the only file name I remember from
earlier, which was index.html. Just like C programs end in files called
something .c, HTML files often end in .html, sometimes .htm, but often .html. So
let me go ahead and click Save there. And now I'm going to go ahead and do a-- type
exactly that same code-- so open bracket, exclamation point. And that's the only
exclamation point we'll expect. The first line is, unfortunately, a little
different from all the others. Then I'm going to do open bracket, html, close
bracket. And you'll notice that, just like with C, the IDE tries to be a little
helpful and finish your thought. So it already closed the tag for me. Now it's just
on me to hit Enter to move it into place. Now I'm going to-- what came next inside
the-- uh-oh. What came next? The head-- so open bracket, head, close bracket.
Inside of head was-- yeah, title. And then I think it just said, "hello, title,"
though I could call that anything I want. Then below the head, but inside the html
tag still, was my body. So let me type that here. And I think I said, "hello,
body." So-- bdoy, boday. OK, body-- save. So now I have a text file in the IDE. It
seems to match up with what we showed as a canonical page before. Now we need to
load it in a browser. And this is a little paradoxical because I'm, obviously,
writing this text in a browser, and yet I need the browser to read it. So this is
just because the IDE, Integrated Development Environment, that we've been using is,
itself, web-based. That's just an incidental detail. The fact that I have written
this code in a file now is what's important. It could be in the cloud as it is. It
could be on my Mac. It could be on my PC. It could be on any other server on the
internet. The point is I need to access this file somehow. And so it turns out that
we're not going to compile it. There are no zeros and ones involved anymore. There
is no machine code. We're going to leave it just like this. HTML is interpreted,
literally, line by line, top to bottom-- no zeros and ones needed. But I am going
to need to run my own web server, not the IDE itself. I want to run, as the
developer, my own web server. What is a web server? It's like Stephan. It's just a
program sitting there, waiting and waiting and waiting for something to happen. And
that's something is, presumably, a request from a browser, at which point
it will respond with a handshake or, more specifically, with this file. So how do
I do this? Well, in the IDE, we actually include a free program called http-server.
All of the software in CS50 IDE is free and open source. So we've simply chosen
some of the most popular packages, one of which is called, literally, http-server.
And if I go ahead and hit Enter, you'll see somewhat cryptic information at first.
But let's see. It's starting up the http-server. It's serving dot slash. Well, what
does dot mean? This folder. So just serve up the contents of this current folder
that I'm in. Now it's saying it's available on this URL. And this URL's going to
vary by who is running this. If you're running it, you're going to see a different
URL. But what is interesting is the number-- turns out that, because this is my
little own personal web server, it's not using port 80, which I claimed earlier was
the default. It's using a different convention, 8080. 8080 is just a human
convention. It's not standardized in the same way. But this way, I can serve files
separate from the IDE because the IDE itself is actually listening on port 80, or,
technically, 443, because it's using HTTPS. And I don't want to confuse my files
with CS50 IDE's own files, the actual user interface that you're all familiar with.
So, just like Stephan can hear from-- say hello to multiple people and Google
servers can handle multiple services, so can my own IDE listen on multiple ports,
as they're called-- 80, 25, 443, or, in this case, 8080. So what does this all
mean? I'm going to go ahead and literally click on this URL, open it in another tab
on my browser, and you'll see somewhat cryptic output. But this is just a succinct
way of saying, here is the index, the listing, of slash, which is now the default
area of my website. I've got two folders, source 5, which is on the course's
website-- it's all of today's files in case we want to look them up without writing
them from scratch-- and then the file I just created, index.html. So if I go ahead
now and click on index.html, there we have it-- hello, body. And we don't see the
tab just because I full-screened Chrome. But if I actually remove that full
screening and zoom up to the top of the tab, you see "hello, title" there. And if I
go back into this file, meanwhile, and I say, "hello, body, nice to meet you"--
this one got weird-- now I'm going to go ahead and click reload. And now you see
this. Let's go ahead and take a five-minute break sooner, rather than later, so
that we can address the projector issue. And we'll be right back. So to recap,
there are more tags than just html and head and title and body. There's things that
give us images and sounds, certainly, and many, many, many other things. So let's
take a look more manually at just one or two other examples and then get a sense of
the whole menu of tags that might be available. Let me go ahead and create a new
file now. And I'll go ahead and call this image.html. And in anticipation of making
a demonstration now that has an image, to save time, I'm just going to go ahead and
paste the contents of the previous file. But I'm going to go ahead and get rid of
the body this time and start to actually embed an image in here. Now, in advance,
I've downloaded an image of Yale's own bulldog, Handsome Dan, in a file called
dan.jpeg. And I've uploaded it to the IDE in the same folder that index.html is in
and now that image.html is in. And you can include an image by using an img tag.
But you have to specify to the browser what the image you actually want to embed
is. And so to do this, as you may know, we have attributes. So just like the html
tag, as we saw earlier and can now see in the example here, has a language
attribute specifying English as the default language for this page to help things
like Google Translate and the like, so does the image tag get modified by this
attribute called source. It's just src and img because those are more succinct
representations of "image" and "source"-- saves us some keystrokes. And now I can
type in here dan.jpeg. And then, just for good measure-- well, rather, I can then
close the tag using the corresponding angle bracket, the greater than sign. But
whereas all of the other tags thus far have a notion of starting and stopping or
opening and closing, the image tag doesn't because the image is either there or
it's not. There's really no conceptual notion of starting an image and then
eventually stopping an image. But let's add one other detail. It turns out that
there's yet other attributes. So you can have zero or more on any tag. For folks
who have trouble seeing content on web pages and, indeed, rely on tools like screen
readers, there's actually attributes that can help in cases like that-- turns out
there's an alternative tag, or alt, where you can actually say, "photo of Handsome
Dan," which is a textual description of whatever it is you're embedding in the web
page. This way, someone who's not sighted but who has a screen reader that can read
that to them can actually understand what it is that's on the web page. So most
folks wouldn't see that unless you actually hover over it or have it spoken to you.
So let me go ahead and save this file, go back to the index of the web server that
I ran earlier with http-server, and now click on image. And voila. You'll see
dan.jpeg embedded in the web page. Of course, this web page doesn't actually do all
that much yet. And so suppose we actually wanted to link to one page or another.
Well, we can do that as well. Let me go back to the IDE, copy this same code, just
as a starting point, create a new file called link.html. And then in this file,
we'll start with the same contents. But let me get rid of that body and simply say,
for instance-- let's have people visit Harvard. So I could say visit https, for
secure, www.harvard.edu/, or maybe even without the slash-- it doesn't matter for
the default page-- period. Let me save this. Let me go back to the index of the web
server, reload so that I can see the new file, link.html, that I created, and now
click link.html. And voila. So it's a URL visually. But it's not actually
clickable. But that's because the browser's only going to do what you told it to
do. And all I've implicitly told it to do is display this black text here. If I
actually want to make it interactive, I need another tag. Well, it turns out in
HTML, there's an anchor tag, somewhat cryptically named. And it's also succinctly
written as a, for anchor. And with the anchor tag can you anchor at this point in
the page a link, or a hyper-reference, as it was once called, to that specific URL.
So that attribute, by convention, is called href, hyper-reference. That is the
destination to which you want to link. I can now close that tag. But I now need to
tell the user where they're going. So I could just say Harvard, for instance, and
put my period out there. Save the file. Go back to the tab here. Click Reload. And
now you'll see the dichotomy. I'm seeing one thing, Harvard. But if you hover over
it, and it's super small here, you can actually see, as a safety check, in the
bottom left-hand corner, typically, the URL that you'll actually be led to. Now, as
an aside, with this very, very simple feature of HTML, you can actually socially
engineer people, as is commonly done with phishing attacks, P-H-I-S-H-I-N-G. If
you've ever gotten some spam, either in your inbox or your spam folder, odds are
someone's tried to ask you for your username and password or for your money or for
your PayPal account. PayPal is especially a common target here. But you can see how
you can very easily, unfortunately, trick and mislead people, especially if they
don't necessarily understand some of these fundamentals. Let me go back here, for
instance, and say here-- well, there's nothing stopping me from doing this little
mischievous trick. I can change the href to Yale, but the text to Harvard, thereby
tricking someone. Ha ha. You're actually going to Yale's website instead. But more
maliciously, and in these phishing emails or spams that you might have been getting
over the past several years, you could imagine typing anything you want here, like
paypal.com. And then here could be www.SomeMaliciousWeb siteThatWantsYourMoney--
hopefully, that does not exist-- .com. Save. Reload the page. And honestly, most
people, myself included, are not going to always paranoically check where I'm
actually going. I'm just going to click on a link. And voila. You might not notice
the URL bar changing because you're being whisked away to some website. And
honestly, it's not all that hard to recreate websites. In fact, just to really
hammer this point home, let me go to paypal.com. And using today's primitives,
notice that you can go to View, Developer, View Source. This is the HTML
implementing PayPal's website-- looks good. Let me copy and paste that into, say, a
new file called paypal.html. Let me save that here. Now let me go back to my web
server, reload, open paypal.html. And voila. I have made PayPal. So it's not even
that hard to mimic where people think they are going. Now, intellectual property
issues aside, that I just copied and pasted someone else's website, this is clearly
not fully operational because what I don't have access to their database and their
code on the server and all of the intellectual property and business logic, so to
speak, that actually makes PayPal what it is. But HTML, the point is, is purely
openly accessible by anyone. It's not encrypted. It's not zeros and ones. But it
tends to be so aesthetic and structural in nature that that's not really the juicy
stuff in a business. But this technique can certainly be abused in this way. So
moving forward, just be more mindful of this because most emails you get these days
by a Gmail or any tool are themselves implemented
in HTML. Even when you're typing out a Gmail message and have never even thought
about HTML, that email is actually being sent underneath the hood as HTML. Why--
well, if you've ever used a bulleted list or a numbered list, if you do boldfacing
or italics or any of those aesthetic features in Gmail or other programs, those are
implemented as HTML, but just using nice, user-friendly interfaces. So you can just
click icons. You don't have to think about open bracket, something, close bracket.
But we could do that. For instance, if we go ahead and look at a few other
examples-- let me go ahead here and actually go back to our very first one,
index.html. And suppose I just want to really draw attention to "hello." I can
actually use the strong tag, which implies bold, typically. Save that. Let me go
back to the web server that I had open a moment ago. Click on index.html after
reloading it. And now it's a little subtle because it's small. But you can probably
see that "hello" is indeed boldfaced now. So if you've ever clicked the B icon in
Gmail, that's all it's doing. Underneath the hood, Gmail is taking your word,
hello, and secretly putting open bracket, strong, close bracket, and then the
opposite, the close tag, after it. And that's what it's sending to the recipient of
that message. So what else can you do? Well, let me go ahead and do this. Let me go
ahead and open up, say, a few files that I created in advance. One is called
paragraphs.html. And let me point this out first. So in paragraphs, I just have
three paragraphs of Latin text. And they are rendered, for instance, as follows. If
I go into source 5 and I go into paragraphs.html-- looks nice-- don't know what it
says. And, in fact, it's pretty much gibberish. But it's nice, three nice
paragraphs. But notice how pedantic HTML is. I actually had to use another tag to
achieve those paragraphs, even. If I only had, very reasonably, written these three
paragraphs like you might in Google Docs or Microsoft Word, it's just three
paragraphs. Indent each. Hit Enter, Enter in between them-- looks good. It's
wrapping because it's a really long paragraph off to the right. But that's fine.
And I save this. And I go to paragraphs and reload. Notice that it all bunches
together. Intuitively, why is that happening, though? What's the logic behind this
bug now, albeit an aesthetic bug? Yeah? AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Yeah.
Those additional spaces are not being accounted for. They're just being pushed
together because even though HTML does respect one space-- otherwise, everything
would be completely smushed-- it ignores multiple spaces, whether it's new lines or
tabs or multiple hits of the space bar. And it only does, ultimately, what you tell
it to do. So unless you explicitly, with tags in HTML, say, give me a new
paragraph, that's it for this paragraph, give me a new paragraph, else that's-- now
that's it for the paragraph, it's just going to clump them all together, maybe
separating with a single space, which is clearly not the effect we want. So just
remember that HTML is really nit-picky when it comes to that. And much like in C,
your code won't compile if it's not quite right. In HTML, it will display. But it's
not going to display quite right-- is the key there. Well, what other features does
this HTML have? The reality is-- we'll give you a general conceptual overview of
HTML today. We'll give you a taste of some of the tags. But the reality is this,
too, is the sort of language that you can really learn by doing and by looking at
online references or texts that actually summarize the various tags. But let's look
at least a few more. Let me go into now headings.html. And you'll see this-- turns
out that there are tags called h1, h2, h3, h4, h5, h6. These are very commonly used
on websites that have different headings, like big and bold, a little smaller and
bold, a little smaller and bold to do, like, chapter and section headings. CS50's
website is very hierarchical. If you look through the syllabus, you'll see lots of
different font sizes and boldfacing and the like. That derives from our using these
built-in heading tags. If I go ahead and open this in my browser, we will see the
effect. By default, h1 is big and bold. H2 is big, but not as big and bold. H3 is a
little smaller. H4, 5, and 6-- and this follows the paradigm in academic papers and
books that have chapters and sections and subsections and the like. You just get
this feature for free from HTML. Well, what else is there? Well, if you actually
have tabular data, things you want to lay out in rows and columns, well, it turns
out that HTML supports tables. Let's glimpse at this, too. And if I go into
table.html, in my browser, we'll see this effect. It's not all that interesting. I
kind of mimic the idea of a phone pad, where these numbers are lining up in columns
and in rows. But invisibly, this thing is actually laid out with tags. If I go to
the IDE and look down in here, you'll see some copy-paste of before-- html, head,
and body. But then notice here. Hey, browser, here comes a table. And you see,
albeit surrounded by unfamiliar tags, probably, 1, 2, 3, 4, 5, 6, 7, 8, 9, and then
the symbols down there. So let's just infer, because the reality is much of your
learning of HTML and soon another language, we'll see-- it will just be indirectly.
If you're curious as to how some web page is implementing some feature, you
actually look at its source code. And you infer, by example, how you could do the
same. So take a guess. If this tag, effectively, says, hey, browser here comes the
table, this tag here, even if you've never seen HTML, probably means table row.
Hey, browser, here comes a row in my table. This one's less obvious. But td, td, td
stands for table data or table cell. So, hey, browser, here comes a cell, another
cell, another cell, three of them in total. Hey, browser, that's it for this row.
And then repeat the pattern. So here's where HTML just gets a little mundane after
a while. Once you see the name of the tag and once you know what attributes, if
any, it supports, you just follow this pattern. That's it for HTML. There's start
tags. There's end tags. And sometimes, they're not even end tags, if they're not
needed. And there's attributes. And that's HTML. Now, if you want to be sure that
your code is correct, you have a few options. Let me actually go ahead and open up,
for instance, hello.html from earlier, just so I have a simple example-- or
index.html from earlier. Let me go to validator.w3.org-- turns out there's tools
out there that will just help give you feedback on whether or not your HTML is
valid, is correct. And this is useful because sometimes, it might look OK to you on
Chrome. But honestly, if your friend or family member visits the exact same page on
Edge or IE or Safari or Firefox, it might not look the same because the companies
that make those browsers sometimes disagree on how to render HTML. And so if it's
not 100% correct, you're only incurring more risk that something might render
incorrectly. I went ahead and clicked Check after pasting my code in. And this is
good-- document checking complete, no errors or warnings to show. So when it comes
time for Pset5 and you're dabbling with HTML, know that there are tools out there,
this one included, and we'll point you at it in the spec, that just helps give you
feedback on whether something is broken so that you can, with more confidence, know
that it's going to work OK. Well, let's make something a little more interesting
now. Let's re-implement Google, and not by this little copy-paste trick, where we
just copy their HTML and use it ourselves. Let's actually now make a user interface
that uses Google, in some way. So Google, of course, in all of its forms,
ultimately has a text box into which you can type information. And if I go ahead
and do this, it turns out that Google is generally going to redirect me to a
certain URL. If I search for "cats" and hit Enter, notice I got redirected to a
pretty cryptic-looking URL. There's a lot of metadata in there. There's a lot of
advertising information these days and all that. But it turns out, and I know this
just from experience, I could distill this URL into this. And it will still work.
So let me go ahead and hit Enter. Whoops. Let me go ahead and hit Enter after
simplifying this to question mark q equals cats. Enter. And indeed, I get the same
page of cats back. So what's going on? So the URL itself is not all that
remarkable. We've seen ww before. You've certainly used google.com before. This
means it's secure. It's speaking HTTPS. All of this now is old hat. It's not
requesting index.html because Google is dynamic. The content is constantly
changing. There's not some human whose job it is to update Google's home page every
day with HTML. So they, instead, have a piece of software running, written in
Python or C++ or Java or who knows underneath the hood that is just listening at
this address. So it doesn't have to be text files that humans created. It can
actually be a program. This one is called Search. And in just a week or two's time,
you, too, will write programs in a language called Python that can do the same
thing. But for now, we'll let Google do the heavy lifting. And notice the question
mark. If you ever see a question mark in a URL, this means to the browser, here
comes some user input, something that the user probably typed into the form, just
like I did "cats" a moment ago. And then you're going to see something equals
something, which indicates what the human typed in. Now, just because Larry and
Sergey, some 20 years ago, decided with google.com that this text box that we saw a
moment ago, the big box that's now positioned here-- they decided years ago that
the name for that text box is going to be q for query-- but you can call it
anything
you want. "Cats" is, obviously, what I typed in. The equal sign is just
associating the two together. So this URL just means to Google, hey, Google, run
the search program, passing in a user input name of q whose value shall be "cats."
And that is how Google knows what to search for, for any of us. And frankly, I can
search for "dogs," not even just by typing the word "dogs" in here. I can be a
little more precise and type it into this query because I now know Google's URL
format. And voila. Now I get search results for "dogs" instead. But that's it.
That's the basic building block that's been happening all this time. And even
though the URL a moment ago was longer and uglier, that was just uninteresting
detail. It's not the core business that the search is actually providing. So what
does this mean? I can actually now make my own user interface for Google by using a
few new tags as well. Let me go ahead and copy this, as a starting point. Let me go
ahead and create a new file called search.html. Just to save time, I'll type that
in there. And I'll call this search. And I'm going to get rid of the "hello" body.
So I just have a starting point. That's just the same HTML I'm copying and pasting
every time. Well, it turns out in HTML, there is a tag called form that will give
you a form for user input. And it turns out that inside of a form, you can have
different tags as well-- specifically, an input. And inputs have names. So I can
say name equals "q" to mimic Larry and Sergey's decision years ago, the founders of
Google. The type of this input is text. So it's not a button or a check box or
something like that. Those exist, too. It's just text. And then I want a Submit
button. And I just know, from having done this before, that I can get a Submit
button by doing type equals submit. And then the value of that is going to be
Search, which is the word I'm going to see on the screen. You would only know this
by having seen it by someone else doing it, looking at someone's source code,
reading an online tutorial. It's not necessarily obvious. But the pattern is the
same-- tag name, attribute equals something, attribute equals something, and so
forth. Well, now let me go ahead and save this, go into the web server, and reload
the index. So there's my search.html. And it's not quite as pretty as Google's. Let
me zoom in so it's bigger. But I do have a text box. And I have a button whose
label is Search. But I don't know yet where to send it. I need one more attribute
or two here. It turns out that I want this form to take the action of sending this
information to www.google.com/search, the search program on Google's server. But I
want it to use that special verb we saw a moment ago. And again, this was deeper in
the envelope. The method I wanted to use is get, in lowercase in this case-- so a
little low-level and technical now. But this just means that's the verb you should
use inside the envelope to get the web page. But that's it. I've told the web page
the action you should take is submit this form to this URL using get, the method we
saw earlier. Submit a parameter, as it's called, called q, with whatever the human
typed in. And then have it give us a Search button here. So let me save this, go
back to my page, reload. And now let's go ahead and search for "mice" this time and
click Search. And voila. There we have a whole lot of mice search results. But why,
is the question? Well, all I've done is, using HTML and an HTML form, is I've
generated the prescribed format of a URL, calling Google's Search program with a
input of q equals mice. And now, as an aside, if I did take more inputs, they would
be something like this-- something equals value ampersand something equals value.
Ampersands just separate these key-value pairs if you have multiple inputs on the
page. But the principle is ultimately the same. So it's pretty powerful. I've not
implemented Google, per se. I've implemented the front end, the user interface. And
in future, we can we maybe start to work on the logic behind the scenes. So any
questions then on HTTP and now the convergence with HTML? You feel comfy with HTML,
because we're about to move on to another language? Yeah? So all of my examples
have looked ugly thus far, except for PayPal. That looked pretty nice. But I just
copied and pasted it. So how do we begin to style our websites in a more compelling
way? HTML, at the end of the day, is mostly used for structure of a web page, just
laying out the data that you care about, the words that you care about, the images
that you care about. But the aesthetics that last miles, so to speak, of the really
pretty colors and the right font sizes and positioning things exactly where you
want them-- that is the job of another language called CSS, Cascading Style Sheets.
This, too-- not a programming language. It's entirely aesthetic in its nature. So
let's go ahead and take a look at an example. Let me go ahead and open up the same
web server as before, open up an example I saw early-- that I made earlier called
css0.html. Suppose that this is the home page that I want to create for John
Harvard. And notice I've got his name, big and bold, at the top. And I've got a
slightly smaller font in the middle and a slightly smaller font below it. But these
are just minor font size differences. It's all centered in the page here. How would
I actually make this website? Well, let me go ahead and go into a new file here.
I'll call it css0.html. Let me go ahead and paste my starting point, as before. And
I'll call this css0. And then in the body of this page is where I'm going to go
ahead and lay out that content. So as I recall, I had John Harvard. And then below
that, it was "Welcome to my home page! Copyright," and funky symbol-- so I'll just
do that for now-- "John Harvard." Save. So that's css0.html. Let me go ahead and
reload it back from my server. And voila. So what's wrong, aesthetically? It's,
obviously, all on one line. But why? How do I fix this, as before? Yeah? AUDIENCE:
[INAUDIBLE] DAVID J. MALAN: Yeah. So I could add the paragraph tags, just to put
these all on individual paragraphs. And the IDE sometimes can be a little annoying
because now I'm going in retroactively and adding this stuff. So it's trying to be
helpful. But then I have to delete it. So sometimes, this autocomplete can get in
the way. But it's an easy enough fix-- open p. Let me move this over here and move
this over here. Save. Go back to the browser. It's not going to change on its own.
I need to click Reload. And now-- better. It's a little ugly-- more whitespace than
I want. But it's closer, certainly. Let's clean up that copyright symbol. It turns
out there's some keys you just can't type on your keyboard. You could certainly
copy-paste it from elsewhere. But HTML, as an aside, supports what are called
entities. And these are numeric codes that are sometimes written in hexadecimal,
sometimes written in decimal, depending on your preference. And it's just a weird
number that represents a symbol. You couldn't, otherwise, type. Watch as I reload
now. So what happens to that copyright symbol? Now it's the one you might expect--
so minor detail. It's not all that interesting. But those do exist, as well, for
aesthetics. But this isn't quite what I want. And here is where CSS comes in. I can
lay out the structure of this page. Yes, I have my three separate paragraphs. But
they're not centered. Their font sizes are all the same. And there's weird gaps
there. This is where CSS can help. So let me introduce a few new tags instead.
These aren't strictly paragraphs. It's not sentences and sentences of text. This is
kind of like the header of my page. So let me actually rename this to header. This
is maybe the main part of my page. So let me rename this to main. And this is like
the footer of my page, I would claim. Now, it's a super simple website. But these
tags exist. And in the most recent version of HTML called HTML5, the world has
started moving away from generic tags, like p for paragraph, to more semantic tags
that are a little more descriptive that say, hey, browser, here's the header of my
page, annoyingly, not to be confused with the head of your page, which is, like,
the title. And, hey, browser, here's the main part of my page. Here's the footer of
my page. And we'll see why this is useful, if only because it describes my page a
little more compellingly. But it turns out that any HTML tag can have a style
attribute, which we've not seen before. And if I want to alter the font size of
this tag, I can say, make this large. And down here, I can say, style equals font-
size, let's say, medium. And then down here, I can say style equals font-size
small. And let me save that, go back to the browser, reload. And it's not centered
yet. But now it's kind of big, medium-- large, medium, and small, which is what I
intended the first time. So how can I actually add centering? Well, it turns out
inside of these quotes, you can use semicolons to separate multiple ideas. If I put
a semicolon here, I can now say, text-align center. And let me go ahead and copy
and paste that here and here. Save. And notice the pattern. There's a keyword, a
colon, and then a value. A semicolon separates it. Then there's a keyword, a colon,
and a value. That's the same pattern we're going to see. If I go back to the
browser, reload now, now we're on our way. Now it looks more like what I intended
it to look like. It took a little more effort. But thanks to CSS, I was able to do
it. So what I've highlighted here and what the IDE has highlighted in green is what
are called CSS properties, Cascading Style Sheets. CSS lets you deal with things
like centering and font sizes and colors and positioning and all the aesthetics I
alluded to earlier. And you just have to know what these key values are. Honestly,
I don't know
all of them, certainly. I always Google when I want to know how could I do
something with this type of tag. That's because there's a lot of online free
references that just shows you this. But they all follow the same pattern-- key,
colon, value-- maybe semicolon-- key, colon, value, and so forth. But even if
you've never written HTML before, you could probably argue that I am not making--
designing this very well. In C, too, you might have found fault any time my
instinct was to copy-paste. What is redundant in this example? AUDIENCE:
[INAUDIBLE] DAVID J. MALAN: Yeah. I'm centering all three, which honestly, it just
looks a little stupid. It literally was copied and pasted. And that should always
rub you the wrong way. So Cascading Style Sheets-- the first C in Cascading Style
Sheets, or the only C in Cascading Style Sheets, stands for Cascading, which
implies a hierarchy to it, too. So let me, actually, make a new example. Let me
call this css1.html. Let me paste that same exact code. But it occurs to me that
header and main and footer are all children of body, if you will. They're indented
inside. And you can-- you actually can use family tree references in the context of
HTML, where header is a child of body insofar as it's inside of her, tucked,
indented, inside of it. So if these all have the same parent, so to speak, let me
actually erase this from all three tags. And let me actually apply it to the parent
tag, saying, style equals text-align center because cascading style sheets, indeed,
cascade. So if you apply one property, like aligning in the center, to the parent,
it's going to cascade down on all of the children nested inside. So let me go ahead
and save this, go back to the listing, and open up css1.html. And voila-- no
aesthetic difference. But it's just better designed, like 5 out of 5 for design
now, but not necessarily because this is a little ugly, honestly. And we've not had
occasion to do this yet in C because we only had one language in C. It, generally,
is frowned upon to combine one language, like CSS, with another, like HTML. And
they might look very similar. And they're all in the same context. But this gets
annoying. And especially in the real world, some people might be better with
aesthetics than others. Clearly, from my examples, I'm not among those people. And
so I might want to work with a colleague or a friend who's much better at design
and colors and fonts than I am. And so I might want them to work independently of
me. I'll work on the structure of the web page or, if you will, my final project,
and let them actually contribute more of the aesthetics. So how can we begin to
decouple these things? Much like in C, we, at least, had header files. We could
factor out commonalities. Well, it turns out we can do this a little differently
from before. Let me go ahead and open up an example 2 that I made earlier called
css2.html. And let's scroll through this for just a moment. Notice now that in the
body of this web page, I've introduced a different tag-- rather, a different
attribute called "class." So it turns out that you don't have to just copy and
paste or type out manually all of these nit-picky font size changes and text
alignment changes. You can give them more descriptive names. And arguably, it's a
lot more readable to me and my partner to read the word "centered" and "large" and
"medium" and "small" and not see all the stupid colons and the semicolons and the
distractions. That's the stuff that's not interesting when writing any sort of
code. So where did these words come from-- centered, large, medium, and small?
Well, notice that they're all values of a class attribute, which is-- allows for
customization. Let me scroll up to the head of my web page. And you'll see, and
it's mostly whitespace because I just kept hitting Enter to clean it up-- notice
that inside of my html tag is, as before, my head tag. If I scroll down, there's
also still a title tag. But there's a new tag that I alluded to earlier among the
few you can put up there called "style." You can factor out to the top of your page
all of the stylizations that you care about. And you can do it as follows. Notice
here that I've literally written the word "centered" with a dot in front of it, the
word "large" with a dot in front of it, the word "medium" with a dot, "small" with
a dot. Those define classes. So CSS lets you define your own collections of
configuration properties. And you can give them names, just so it's a little more
descriptive and user-friendly. So you can define class, class, class, class. And
then inside the curly braces, which I've lined up here, just like in C, you can
have one property, two properties, 100 properties. But you can keep them nice and
orderly, away from all of your HTML, so that someone else can work on them or just
you can keep the aesthetics separate from the contents of your page. It's the
notion of separation of concerns. Keep the data separate from the presentation
thereof. AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Is there a library you can use
that's done this for you? Yes. And we'll see a little teaser for that in just a
bit. So where are I using these words, to be clear? Here, I'm saying give me a
class called centered, a class called large, medium, and small, each of which have
these respective properties associated with them. And then down here, I can just
use those words. And I don't have to get into the business of the semicolons, curly
braces, and all of that in my actual HTML. But it turns out I can do this even more
fancily. Let me open up css3.html, another example. In this case, notice what I've
done. Now my code is really getting pretty, relatively speaking, or from one
person's perspective. Now I don't have any attributes. This is just tighter. I'm
using fewer characters, fewer words, fewer lines of code. This is just, generally,
a good thing. It's less work. It's less to maintain, fewer opportunities for
mistakes. But I've gotten rid of, it seems, all of the aesthetics, but not
necessarily, because CSS, this second language, also lets you apply properties not
to tags by way of classes, but to the actual tags themselves. So if you only have
one body, it is safe to say, OK, CSS, apply to the body tag this or these
properties. Hey, browser, apply to the header tag this or these properties-- to the
main tag, the footer tag, and so forth. So I don't even need to complicate my world
with small, medium, large, and so forth. I can just apply those properties at the
top of my file to the respective tag names, whatever they are. And I could use the
p tag. I could use the image tag, the a tag, any of those. I can style them in
different ways. In fact, if you wondered or started to wonder how could you resize
an image, you can apply CSS to the image tag and say, make it this many pixels or
this many pixels, or something like that. Yeah? AUDIENCE: Is it bad design to then
keep pushing [INAUDIBLE] DAVID J. MALAN: Yes. Is it not bad design to just keep
adding more stuff to the top and pushing your actual content down and down and down
and just bloating the file? Yes-- which is a wonderful segue to our fourth and
final example here, which is css4.html. This example-- let me just zoom out. That's
it. This css4.html has even fewer lines of code and, indeed, no CSS in it
whatsoever. This is just the website I care about, the words and the data I care
about. All of the aesthetic stuff, while important, is relegated to a separate file
that you can probably infer is called css4.css. Unfortunately, and this was a
stupid design decision by humans years ago, the way you include CSS from a separate
file is, paradoxically, to use a link tag, not the a tag, which probably should
have been called the link tag. But you have a relationship of style sheet. So
sometimes, humans make poor decisions. This is one of them, I would say. But if you
just copy-paste and trust that this means, hey, browser, open up this file and use
those features from the file in this file, it's similar, in spirit, to C's hash
include mechanism. It just looks a little different. So what's in that file? Well,
you can probably guess, if I go into css4.css, it's just that same content. But I
factored it out, as you notes-- wasn't the best design to keep it all together. So
I can simply put it there instead. Any questions? Yeah? AUDIENCE: In the other one,
the fourth perfect one, the best one, what does "stylesheet" do? DAVID J. MALAN:
Good question. What does stylesheet do in this example? Short answer is that just
makes clear to the browser that the relationship between this file, css4.css, and
this file, which is the HTML file, is that of a "style sheet." So CSS, Cascading
Style Sheets-- it's a lot of words just to convey the idea of aesthetics. But that
is your style sheet, literally. It's an actual file that ends in .css that should
be applied to this HTML. Yeah? AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Better design
why? AUDIENCE: [INAUDIBLE] DAVID J. MALAN: It's really good question. So to
summarize, is it-- isn't it-- wouldn't that be better design, to have one file with
your HTML and your CSS, rather than two because things can get misplaced? Now
they're decoupled. There's not the same inherent link. Maybe, honestly. That is a
reasonable concern. Reasonable people will disagree. Generally, I would say that
the programming world has decided that separation of concerns is a good thing. So
keep your HTML in one file, your CSS in another file. Keep them in the same folder.
And, frankly, if you go losing your files in a folder all the time, the problem is
probably a-- is human problem, not a technical one. But you make a good point, too.
And you could argue, quite credibly, that you're just over-engineering this now. I
like it better altogether. And you'll see in CS50's website and Facebook and Google
and others-- sometimes,
you do see CSS together with HTML because humans decided this does make more
sense. But there are these mechanisms in place to facilitate collaboration, to
facilitate separation, so that you can keep things a little more organized in
separate files. Any questions then? So to recap where we're at, because this is a
lot quickly, HTTP is this protocol via which you can just exchange information from
A to B and B to A. HTML is the language in which web pages are written, that
structure of the web page, and actually have your data. And CSS lets you fine-tune
it. Now, I didn't fine-tune it all that much. I just centered it and changed the
font size. But honestly, we can very quickly get into the weeds of colors and
positioning and all of that. But that we'll do in sections and in Psets and in
googling and looking at online references that we'll point you to because it just
all follows the same patterns of tags with attributes and then CSS properties. So
even though you've not seen the whole vocabulary of CSS and HTML, you have seen the
entire structure, the fundamental concepts. So let's introduce then one final piece
of the puzzle and bring back to bear some of our programming capabilities of the
past several weeks. So it turns out that in the world of HTML and CSS, you can
actually introduce a programming language, as well, to make your websites even more
dynamic using something called JavaScript. Many of you have taken APCS and know
Java-- no relation. JavaScript was just a marketing decision to them-- call it
something similar to an already popular language. So JavaScript is a language used
in browsers, typically, to give you more control over the users' experience. For
instance, when you visit Gmail these days and you get a new mail, it just appears
magically as a new row in your inbox. You don't have to reload or keep clicking
Refresh to see your new mail. It just appears magically. When you're using Google
Maps or something, you can just click and drag and see more of the map. Back in my
day, you have to click a right arrow to go this way, a left arrow to go that way.
And the whole web page would actually reload. But JavaScript gives you logic and
programming capabilities in your users' Macs and PCs and phones that gets executed
not on your server, but on their browser, which means you can do many more things
by running code on their computers. So what does this actually mean? Well, in
JavaScript, fortunately, we have a language that's super similar to C. But it's
interpreted top to bottom, left to right. The browser just reads the instructions
in JavaScript and just does them. There's no compilation for you. There's no zeros
and ones. And so in that sense, it's just easier than C. Also, it has no pointers,
which also makes it easier than C. But it gives us the ability to alter a web page
once it's been delivered to a user. And we'll see what we can actually do with that
capability. But first, let's compare and contrast. You'll recall a few weeks ago,
in week 1, when we introduced C, we pulled up some Scratch we pulled up some C,
just to show that the ideas are still the same. Let's do the same real quick here.
So we went from Scratch to C. Let's now go to JavaScript with variables. So in C,
if you wanted to set a counter to 0 a la Scratch, you would literally say counter
equals 0, semicolon. But you would have the data type to the left. In JavaScript,
the code is almost the same. But you actually don't specify data types. You, the
programmer, don't worry about ints or floats or strings or all of that. You do
define the variable. And the keyword to use, though there's several options that do
slightly different things, is let. Add the thinking is let the counter equal 0,
please, if you will. But you don't specify the type, even though JavaScript
supports numbers and strings, and so forth. You just don't have to care about them
as much anymore. Suppose you want to update a variable. In Scratch, you would just
change the counter by one. In C, you would do counter equals counter plus 1,
semicolon. In JavaScript, you would do the exact same thing. Code is identical. In
C, you could also write this more succinctly as counter plus equals 1, semicolon,
if you recall. If you don't, that's fine. This is just shorthand notation. In
JavaScript-- same exact thing. In C, you could also do counter plus, plus,
semicolon to increment the value-- in JavaScript, same. So this is what's nice
about JavaScript. You already know much of it just by nature of having spent so
many weeks in the weeds with C. Suppose you had an if condition, like this-- is if
x is less than y. In C, we would write it like this at right. JavaScript syntax is
the same. If you had an if-else, syntax is the same. If else, if else-- syntax is
the same. If you want a forever loop, syntax is the same, while true. If you want a
for loop, syntax is almost the same. Let needs to be used instead. So this is C
because it says int i equals 0, and so forth. That's a data type. JavaScript-- I
just claim doesn't worry-- you don't need to worry about those data types. So in
JavaScript, you would instead say "let" instead. But otherwise, the syntax is the
same. So that's a nice starting point because there's nothing new to learn
syntactically. We just need to apply the same logic that we saw in week 0 and 1
since to HTML. So if this is a representative web page, albeit super simple-- this
is the one I brought up earlier-- how can we now start thinking about this web page
in a way that is conducive to programming it and actually changing it dynamically?
Well, let me propose that you think of this same web page as just a tree. And we
introduced trees just a week ago, albeit in the context of C. And frankly, in C,
they're a headache because you have to wire things together using pointers and
nodes and all of that. Don't worry about that now. It's the browser's job to build
this in memory or RAM for you. And indeed, when I keep saying that a browser, upon
receiving an envelope with HTML, reads it top to bottom, left to right, I haven't
said what it does with it. What it essentially does with it is it creates this data
structure in memory for you. And it is Chrome or Edge or Firefox or whatever
browser you're using that itself is written in probably C or C++ or some other
language. Some other human at those companies wrote the code that builds all of the
pointers and/or whatever is used to build this structure in memory. But this is
what the browser has in mind once it's read your HTML. And now that it's a data
structure in memory, you can make changes to it, just like last week, we were
inserting humans into our linked list, changing the data structure. The browser can
add more nodes or more tags to the page, dynamically. So if you run with this in
your mind, when you get a new email in Gmail, what is happening? Well, the web
page, when you first load it in Gmail, has a whole bunch of td tags, probably, or
tr tags, rather, for table row-- table row, table row-- each of which represents an
email, perhaps. When you get a new email, the browser is probably just adding
another tr node to this tree because notice the words here. Html lines up with this
tag. Head lines up with this tag. Body lines up with this tag. So it stands to
reason that when you get another row in your inbox with another email, someone is
just adding a node to that tree. And that someone is JavaScript, the language in
which you can control the users' browser even after they've loaded your web page
for the first time. So what can we actually do with this? Let's start simple, as
follows. Let me go ahead and just whip up, really quickly, a file called
hello0.html. And we'll do it, as before, with our DOCTYPE html-- my html tag here,
my head tag here. My title here will be hello0. And notice I've been moving these
to separate lines. You don't strictly need to do that-- just to keep the hierarchy.
The whitespace, again doesn't matter. But I'll be consistent there. And in my body
here, I'll say this time just "hello, world" by default. So that's a pretty simple
web page as well. Let's, actually, now make it interactive. All of my web pages
thus far have been static content, except for the Google one. But even that wasn't
so much interactive as it was the moment I hit Submit, it made the problem Google's
problem to deal with. Let's keep the user with me this time. Let me go ahead and do
this. Let me get rid of this form here. Let me create a new file now called hello1
as my next version. And let me go ahead and paste that same code. But this time,
let me have the browser be a little interactive. Let me go ahead and have a form
here because what I want is a text box-- type equals text. I'm not going to bother
giving it a name yet. And let me have another one called type equals submit. Save.
And let me go ahead and open up my server so I can see this file. This, I said, was
what-- hello1.html. So it's just a simple form. But there's no connection to Google
this time. Let me start to use this form interactively because if I have the
ability to program, I bet I could take the users' input and do something with it.
So how do I do this? Well, let me propose first that I want the human to type their
name into this form. And then when they click Submit, I want it to say "hello,
David" or "hello, Veronica" or "hello, Brian," whatever the name actually is, like
some of our C examples. So you know what? Let me write that function first. It
turns out that in the head of your web page, you can have not just the title and
not just style, but also a tag called script for JavaScript, for instance. And in
this tag, I can actually write code. And there's something a little different in
JavaScript. Instead of writing void greet as the name of my function and then
writing the body of my function here and then saying void here, for instance,
JavaScript's a little looser. If you don't want to take any arguments, just don't
mention them-- no mention of void. If you don't have a-- and actually, don't even
mention a return type. Just call it a function-- so slight difference from C. It's
a little lazier. You don't worry about input types. You don't worry about output
types. You just say, give me a function called greet. Well, what do I want this
function to do? Turns out in JavaScript, there's a function called alert that's
just going to pop up a window that says something in it. And I can pass, as an
argument to this JavaScript function, whatever it is I want it to say. So let's go
ahead and say "hello, world," semicolon. It's almost identical to C, again, except
that I'm saying function instead of a return type. And alert, apparently, exists.
And there's no sharp include or any of that that we typically had in C. It's just
literally in my browser right now. So let me go ahead and save that and go down to
the form tag here. And it turns out, on the form tag, there's a special attribute
called onsubmit. And as the word implies, it says when the form is submitted, on
the submission of this form, go ahead and execute this, greet. So I can actually
tell the browser, on submission of this form, to call a function that I wrote. And
now let me just preemptively write return false for reasons we'll come back to in a
moment, just to make sure this actually works. Now let me go ahead and save this,
go to hello1.html, open that up. And let me just change the title, for
consistency-- so hello1.html. And let me go ahead and say David, Submit-- hello,
world-- not really sure what the point of typing my name was. But it, at least,
seems to work as programmed. But obviously, where I'm going with this is I want to
display my name. So when the human has typed in their name to the box and clicked
Submit, that's triggering a submission of the form. But wait. When the form is
submitted, I'm calling greet. So it sounds like it's greet's job to figure out what
the word is that the human typed in. So how can I do this? It's a little cryptic.
And this is where now it becomes JavaScript-specific and not C. Let me go ahead and
define a variable called name. And let me use this fancy technique,
document.querySelector. And then in here, I'm going to need to specify what node in
the tree I want to select. So I'm actually getting ahead of myself. Let's look at
the HTML. At the moment, I've got a form tag and two input tags, neither of which
has a name. And I could fix that. But let me actually do a different technique.
HTML also supports unique identifiers. And you can give them literally that, unique
IDs. You can call it whatever you want-- foobar, baz, xyz. I'm going to make it
more descriptive and call it ID equals name because what I can now do up here in
querySelector is actually specify what it is I want to select from the tree. That
tree is called a DOM, or Document Object Model, verbosely. And I need to do one
last thing-- turns out, and you would only know this from experience, that if
"name" is the unique identifier of an element and not the name of a tag, I actually
need to prefix it with a hash, unrelated to C's hash. But otherwise, this function,
querySelector, is going to think that there's a tag called "name." So this means an
ID whose value is "name." It's a bit of a mouthful. But here we go. Once I select
that node from the tree, I want to get its value and set it-- I want to get its
value, semicolon. What is going on? First, recall from this tree here that whenever
the browser loads HTML, it has some HTML. It builds a tree structure therein. Each
of those nodes is selectable via this function called querySelector. What is
document? Well, it turns out in JavaScript, there's this special global variable
called document that refers to the whole document, the whole web page. Built into
that is a function called querySelector. That dot notation is reminiscent of C's
struct syntax. So you can think of document as a struct that represents the whole
page. Inside of it is a function, not just data, but a function, called
querySelector. You're going to see this all over the place in JavaScript, dots,
because people-- the JavaScript world is much more voluminous than C. So there's
lots of functions inside of other containers or structures. So with that said, this
is just saying, hey, browser, let me have a variable called name and store the
value of the node that has a unique identifier of name and get that by using this
function, select it. That grabs the rectangle from the picture and gives me access
to the value that the human typed in. Now, I'm not done with this. I need to
actually display that value. And it's not going to be correct to do this.
Otherwise, I'm just going to see "hello, name." So there's not this convention,
which we had in C. There's another way to do this. But I'm going to go ahead and do
it as follows. I'm just going to use concatenation. So this is not possible in C.
But in JavaScript, if you have a string on the left and a string on the right,
using plus will not add them together, which would make no sense. It will
concatenate them, like glue one to the other. In C, how would you do this? It is an
utter nightmare. In C, how would you do this? This would be an array of characters
on the left that has a null character at the end. This would be another array of
characters on the right with a null character at the end. Neither is big enough to
fit the other as well. So you'd have to allocate a new array of characters, copy
these in, get rid of the backslash 0, copy these in, keep the backslash 0, throw
those away. And then you have concatenated strings. That is so many damn steps in
C. And this is why no one likes programming in C. And you don't have to do it
anymore. In JavaScript, just use the plus operator. That does all of that for you.
But hopefully, you do have an underlying appreciation of what the plus operator is
actually doing underneath the hood because the computer is still doing the same
work. The difference is this week onward, we, the human, do less of that work
ourselves. So plus is an abstraction for all of that complexity. So if I didn't
mess this up, let me go ahead and save now. I'll go to the browser, reload, and
type in my name, David. Submit. And there we have it-- hello, David. Let's do one
more test. We'll try, say, Veronica. Submit. And voila. You'll notice that it's
trying to be helpful now, my browser. If I start D, then it sees autocomplete, or
V-- well, forgot about Veronica, apparently. Veronica-- let's see if we reload. V--
that's weird. Don't tell Veronica Chrome doesn't remember her. But we can turn that
feature off-- is the point-- by actually doing things like this. And you would know
this from the online manual. Autocomplete equals off turns off that feature.
Autofocus also does something handy. If you've ever been to a web page and you can
just start typing, Chrome and macOS highlights it in blue. That just means give
focus. Put the cursor there. If you don't have that, the web page starts like this.
And we've all visited websites, and I think my.hardvard's among them, where you
have to stupidly click there just to start interacting with the page. That is not
necessary. That's bad programming. Just using the tags can fix that kind of thing.
Questions? AUDIENCE: What if we have two IDs with the same name? DAVID J. MALAN:
What if we have two IDs with the same name? You should not. That is human error. An
ID, by definition, must be unique. And if you have two by the same name, the human
messed up. And what it does-- I don't know what the behavior is. It's probably
unofficially not documented or maybe it picks the first. Maybe it picks the last. I
don't know. But you shouldn't rely on it, anyway. Good question. Good corner case.
Other questions? Let me jump ahead to one example. And then we'll come back to a
fancier version of this. Let me open up a program that's in today's source 5
directory called background.html. It's got some familiar letters, which probably
stand for red, green, blue, probably. These are three buttons. And we've seen
buttons. We saw the Search button and the Submit buttons that I've created before.
But using JavaScript, I can do fun things like this. If I click on R, the web page
just changed. G, B, R, G, B-- this is now interactive. If you were just writing
HTML and CSS, you'd have to pick one of those colors and stick with it. But with
JavaScript, you can respond. And that's because a browser has lots and lots of
events happening all the time. Events include clicks or mice moving or dragging or,
in a mobile device, touching. So there's lots of things that a human can be doing
with a web browser. And you can write code that responds to all of those kinds of
events. And so let me actually go ahead and open up background.html and show how
this is working. So for the most part, it's just HTML at first. Here's the html
tag, the head tag, the body tag, and three new tags. This is another way of
creating buttons. And again, this isn't interesting. You learn this in the online
reference or manual. And it just tells you, here's how to use a button. It follows
the same paradigm-- tag name, attribute equals value. The label is just going to be
R, G, and B. And now this is where things get a little scary-looking at first. But
that's it. There's just lines of code here inside of the web page. Now, let's walk
through this line by line, even though it's a little verbose at first. So this
first line here says, hey, browser, give me a variable called body. And store, in
that variable, the node-- the rectangle, so to speak-- that has the name body. So
that is, pluck that rectangle out of the picture so that I have direct access to
it. Why-- because I'm going to manipulate it in just a moment. This is the scariest
the JavaScript will look for now. Document.querySelector hash red-- could someone
translate that into just English? What's that doing for me? AUDIENCE: Giving the ID
of red that you just-- DAVID J. MALAN: Yeah. Be a little more verbose. Someone
else? Hey, browser, select for me the node whose unique ID is red. That's fine.
Give me access to that node, the structure in memory. And this is where it's a
little weird. So it turns out that every tag in a web page or node in a tree-- the
DOM tree, so to speak-- Document Object Model-- can have event listeners associated
with it. And you would only know this from the documentation. But if you literally
say, go into this structure, this node, that represents the red button and get its
on-click value, what's cool with JavaScript, even though the syntax is a little
scary-looking, is you can associate a function with that event. So this is saying,
hey, browser, when the red button is clicked on, call the following function. And
what's new in JavaScript here is that this function, at the moment, has no name,
which is weird. You could technically do this in C. But we always gave our
functions names. But you don't really need to give a function a name if you don't
need to mention it ever again. And the detail that's happening here for us is this.
This says, hey, browser, on click, call this function. What does that mean in real
terms? Hey, browser, call all of the lines of code in between this open curly brace
and this close curly brace. So even if you're not comfy with the syntax, it just
literally means execute the following lines of code when this button is clicked.
This is what's known as an anonymous function insofar as it has no name. It's just
function, open paren, close paren. So you can probably infer what it's doing on
this line here. Let me highlight this line in blue. It's a little cryptic. And
again, I promise that you're going to see lots of these dots. But this is saying,
hey, browser, modify the body, or specifically, the style of the body, and
specifically, the background color of the style of the body, to be, of course, red.
And the rest of the code is copy-paste for now for green and blue as well. So what
is happening? Every time you click on one of those buttons-- R or G or B--
literally, this line of code is getting executed that I've just highlighted or this
line of code is getting executed or this line of code is getting executed. So even
though the syntax is, yes, admittedly, way more complicated than we've seen thus
far, the idea is relatively simple. Select the button. Tell it, on clicking, to
call this function. And it's fine early on if you just copy and paste this. And for
Pset5, you won't have to use any of this code. This is in-- preemptive look at what
you can do with an eye toward fancier features, like final projects and beyond. Any
questions then on this background example? Yeah? AUDIENCE: Why did we use the pound
symbol for red, green, blue, and not for body? DAVID J. MALAN: Good question. Why
do we use the pound symbol for red, green, and blue, but not for body? If you look
at the HTML, you'll see the following. Body is, apparently, the name of a tag. So
that's why we just selected "body" with that line of code around here. However,
red, green, and blue are not the names of tags. They are the unique identifiers,
values that I just came up with. I could have called it x, y, z. But I chose more
descriptive terms. So whenever you want to reference or select a node who-- that
has an identifier, you use the hash instead. That's all. These are just human
conventions that are non-obvious unless you were told what they all mean. Let's try
one other example with JavaScript. It's not uncommon on news websites to have the
ability to change the font size, which you can, actually, do on your Mac and PC
sometimes using keyboard shortcuts. But sometimes, it's built into the web page
itself. Let me go into, for instance, size.html. And here's some Latin text or
Latin-like text. And notice that it has a little select menu. Normally, when you
have a select menu, you select something. And then you click Submit. And then the
server deals with it. The information goes somewhere. But you don't need to do
that. You can actually make little menus interactive, just like text boxes. Suppose
I want to make this text a little smaller. I can do that. I can choose extra small.
I can do extra-extra small or I can do extra-extra large. And so what's going on
here? Well, just like there are click events in a browser, there are also change
events or selection events. Just anything that can happen on the web page you can
listen for. So let's take a look at this code, for instance. We've not seen this
tag before. But we have seen paragraph. And there's a paragraph of Latin. And then
there's a select tag, which gives you a select menu. A dropdown menu is called a
select menu in HTML. And here's how you have all of the options. Now, there is a
bit of duality here. There's what the human sees, which is between the open tag and
close tag. And then there's this value, which the computer sees-- but more on that
another time, when we get to Python. But this just gives me that whole menu of size
options. And if I scroll down now, notice I have a script tag down here. And in
this script tag, I have document.querySelector "select" because I want to select
the name, the tag whose name is select. And then there's this event, onchange. And
you'd only know this from the documentation. But like onsubmit, onchange is called
any time you change that menu. What function should get called? Well, this one
here, which is an anonymous in the sense that it has no name. And go ahead and do
this. Select from the document the body tag. Get access to its style. And change
its font size to, and this is funky here, this.value. So what did I do here? Let me
do this, no pun intended. This refers to whatever element in the web page induced
this function to be called. So this is-- you can think of as a variable, a special
variable, that always refers to whatever element you are listening to. And so
this.value just saves me some keystrokes because I don't-- you need to use
document.querySelector to get at this select menu. But we'll see this again,
perhaps, down the road. Questions? And let me point out one thing that's stupid.
This here, fontSize, looks different from CSS. In CSS, what did we call this? Do
you remember? We did font size small, medium, large. It was font-size. So this was
left hand not talking to right hand when these things were invented. It turns out
that dash is JavaScript means what, maybe? Minus or subtraction. And so this syntax
just breaks in the context of JavaScript. So what did humans do? They decided that
any time you have a CSS property that's word, dash, something, get rid of the dash.
Capitalize the next word. And that's now the mapping in JavaScript-- so just a
simple heuristic there that you can perhaps keep in mind. Let's take a look,
perhaps, at one final value-- oh, how about two final values? Let's go ahead and do
this with blink.html. So back in the day, when the web was first being invented and
HTML was in its infancy, there was a wonderful tag that was probably on my own
personal home page called blink that literally did that. You could have a tag that
was open bracket, B-L-I-N-K, close bracket, put some words, then close the tag, and
then your web page would just do this to all visitors, which humans eventually
realized, well, this is dumb and really annoying to look at-- bad user experience,
or UX. And so they took it away. It's one of the few tags, I think, from HTML that
was actually removed by committee, as opposed to added. There was also marquee at
the time, too, that-- like a theater sign would just scroll words across your page.
So you've probably seen websites like this that recreate them in some way. But you
can do this with JavaScript. Think about this logically. We know how, in code, we
can change the style of an element. We've not seen how to do this yet. But you can
make an element show or hide, show or hide. Turns out in JavaScript, you can use a
timer. You have access to a clock. And you could actually write code that says, you
know what? Every half-second, call this function. Call this function. Call this
function. Call this function. And what that function does is it changes the style
of the page to hide or show, hide or show. Now, this used to be built into
browsers. But now you can recreate it with something like that. And I'll wave my
hand at what the code is. But that's just one feature there. Let's look at one
final example, though, that's a little creepy. Here's the code first. And this is
called geolocation. This is all the rage now with apps like Uber and Waze and Find
My Friends on iPhone and the like. Here is relatively little code that will figure
out where your user is in the world. Now, it's a bit of a mouthful here. But it's
mostly this file, html with a script tag. But there's this other special global
variable. And we won't use this much. And indeed, you might not ever use it if you
don't care about this feature. But it's called navigator, for historical reasons.
And navigator has a feature called geolocation. And geolocation, which stands for
locate people geographically, has a function called getCurrentPosition. And for
reasons we won't really get into, it takes a function as an argument. This is a
very common JavaScript paradigm, but more on this toward final projects, perhaps.
This line of code is going to write to the document the user's latitude and, if we
scroll to the right, their longitude. So this is where it gets creepy. So if you
were to use this code in your websites and a user were to visit, like I will now,
and they click the link, they will be prompted, do you want the website to know
your location? Sometimes, you might
say yes. Sometimes, you might say no. Frankly, most of us probably just click
Allow instinctively without really thinking about this. But there's where I am,
apparently. Let me go ahead and highlight that. Let me go to maps.google.com
because whatever website you just visited, whether it's Facebook or CNN or-- a lot
of news websites want to know where you are. If you go to like, what, fandango.com
or the like for movie tickets, they might want to know where you are. Well, you're
giving them very precise information. If I go ahead and search for these GPS
coordinates on Google, that's not where I am. What the hell? [LAUGHTER] Why are we
in Oklahoma? [LAUGHTER] I don't understand what's going on. This was not part of
the demonstration. This was going to be the big climax. Let's turn off the wired
internet in here. And apparently, we're going through Oklahoma today. Let's turn on
the Wi-Fi, which will just give me a different IP address, which is a wonderful way
to tie the start of the lecture together. If I wait a second, it should go green.
Come on-- no IP address. Now these words might make a little more sense. Come on.
Give me an IP address. Come on. Harvard-- there we go. There's my IP address. Let's
reload. [LAUGHTER] We'll email the IT people about this later. But all of my
internet-- what this means is my-- no, this is really weird. We have a lot of
footage to cut out of today's video. So what this does is, with low probability,
tell you where your users are in terms of latitude and longitude so that you could
geolocate them, figure out what the local movie theaters are or what the starting
times of stores are, give them directions to places, and the like. And while that
was supposed to be the big climactic finish, apparently, none of this works. Today
was completely wrong. We're in Oklahoma. But let's end here today. I'll stick
around for questions. We'll see you next time.