[MUSIC PLAYING]
DAVID J. MALAN: Recall
that when you visit
a URL, like
http://www.example.com, you're
actually requesting of some
web server a file, most likely,
called, for instance, index.html.
Now, to be fair, that file
can be called something else
and it doesn't actually
have to be a file.
It can be a program that
generates a response for the user.
But in the common case, it's
indeed a file called index.html,
even if you or some user
has not explicitly typed it.
And what that means is
that you're effectively
downloading from the server just a
file that happens to be a text file,
such as one written in
Notepad.exe or Text Edit on a Mac.
But this file is written in such a
way that the browser understands it.
It's written in a language that
calls itself HTML or HyperText Markup
Language.
And now, and this is indeed
not a programming language
but a markup language,
a set of instructions
that tells the computer what to do
and how to do it, but not in the way
that we saw with programming
languages proper.
We don't have an HTML functions or
loops or conditions or variables.
Rather, we have what
we're going to call tags,
special instructions to the browser
that tell it what to start doing
and eventually, what to stop doing.
So for instance, if you might want
to display text or center that text
or format it or
structure it in some way,
HTML is going to allow us to
present contents of a web page.
And eventually, we'll
see another language
via which we can style
the same, but we're not
going to do it in the same
way as logically as we
did with the programming language.
So what might the
simplest possible web page
be that we could implement
in this language called HTML?
Well, consider this web page here.
In the main part of the page, do I
see, hello, body, a sort of greeting
to the actual user.
And up here in the title do
I see quite simply, hello,
title, referring to the title bar
or the tab atop this web page.
Now it's incredibly simple.
It's only whitespace everywhere else.
So this web page would seem to
have just a couple of phrases.
So how, using this language, HTML, would
you go about implementing this page?
Well, let's take a look.
Here I have just a simple text
editor, again similar in spirit
to Notepad or Text Edit.
I'm going to call this file index.html,
simply to be consistent with that URL
we saw.
Now, what might the
contents of this file be?
Well, to write the
simplest possible web page,
I'm simply going to begin as follows,
open bracket, or less than sign,
followed by an exclamation
point, and then DOCTYPE html.
A fairly arcane line
of text that is simply
a clue to the browser
to say hey, browser,
here comes a web page written
in a version of HTML version 5.
Indeed, this first line of code
has changed over the years.
This is perhaps the simplest yet,
and it implies only implicitly
that indeed we want to use HTML5.
Now thereafter, actually come the
structure of the web page itself.
And so I will literally type this.
Open bracket, html, close bracket.
And then a couple of lines later, let me
go ahead and say, open bracket, /html.
These are what are called tags and
they say to the browser, hey browser,
here comes a page written in HTML.
And hey browser, that's
it for this web page.
So whereas, we might call
this first tag here the start
tag and this last tag the
end tag, we might also
call them the open and
close tag, respectively,
thereby implying that there's
a structure and a symmetry
really to a web page, whereby, you both
start and stop, ultimately, a thought.
Now inside of this
web page, you're going
to be at least two parts, just
as we saw in the rendering
thereof in the browser.
We have what we're going to
call the head of the web page,
the very topmost portion thereof.
And I'm going to go ahead
and preemptively say,
open bracket, head, closed bracket.
And then again, close that
tag by using a forward slash
in front of that very same name.
Now for now, the only thing that
can go in the head of a web page,
for our purposes, it turns out is
something like the page's title.
And I'll go ahead and say title,
and just as before, hello, title.
Now that's the end of
my thought, and so I'm
going to tell the browser
that is it for the title,
and I'm going to close or
end that tag, so to speak.
So that covers it for
the top part of the page.
What about the rest of
it-- the body of the page?
Well there too, I have another
tag quite simply called
body that says, hey
browser, here comes the body
of my page, the remainder of the
contents that really fill out the rest.
Thereafter, I'm going to
preemptively say, all right,
that's going to be it for the body.
But inside of that body, are going to
be the contents thereof, perhaps just
a phrase like I had before, or perhaps
a picture or video or much more.
This is where you would put the contents
of a company's web page or anything
that you want to present to the user.
I'm quite simply for now going to
say hello, body, and that's it.
Hereafter, I'll save this file
and it will exist on my hard drive
as just that, a file, called index.html.
And if I now go into my
browser and choose File Open
or simply drag that file index.html
onto the browser, what I will see
is just this.
Our browser pictured here
is Chrome and in the title
bar is indeed hello, title, and in
the body is just that, hello, body.
The browser knows what to do.
Because indeed, at the end of the
day, all a browser does is that.
It reads this language called HTML in a
file called, typically something .html,
top to bottom, left to right, and every
time it encounters one of these tags,
it does what that tag means.
So Google and Microsoft
and Mozilla and others
who create these so-called browsers
simply design them in such a way
that they know how to, if
you will, interpret HTML.
Again, it's not a programming language
or interpreted in quite the same way
that Python is, but it is in fact
an interpreted, line by line,
top to bottom, left to
right and the browser simply
does what these tags tell it
to do-- present the title up
here and the body down here.
Now fortunately, there are many
more tags than just these, whereby
we can create lists and tables
and paragraphs and more.
And so, let's flesh out the
vocabulary, so to speak,
that is HTML by looking at
some more complicated examples.
Here for instance, is a
file called paragraphs.html,
and I've begun it just as I
have before with a DOCTYPE html
at the top an html tag
thereafter and a close html tag
down below, a head, a close head,
an open body, a close body, a title
tag, and a close title tag thereafter.
But between that, I've
gone ahead and whipped up
a couple of paragraphs
of Latin, or well, Latin,
thereby filling out
the screen much more.
But let's go ahead and now
open this file on a browser
and we'll see that it doesn't quite
present in the way that you'd think.
Indeed, when I open
this file in my browser
all I see is just one big block
of text, no two paragraphs,
even though when I typed it
out did I very deliberately
hit my Enter key a
couple of times in order
to create that break between paragraphs.
And so, what's going on then?
Why is the browser ignoring me?
Well indeed, just as with
the tags, the browser
only does what it tells you to do.
And in fact, by default, it ignores
whitespace-- presses of your space bar
or tab key that are typically
used only in writing code
to make the code more
readable for the user,
whether Python or HTML or anything else.
And indeed, notice how I very nicely
indented here everything on the screen,
including those paragraphs.
But I don't want to see all
of this space in the page
and I don't want to see all of
this space in the title or body,
and so the browser just ignores
seemingly superfluous whitespace,
simply presuming that the code
itself was pretty printed.
But that's of course, a problem
when what I want to display
is text, English text, that actually
has paragraphs and structure.
And so, I need to format this
a little bit differently.
I need to tell the browser, hey,
browser, break lines here so as
to move the text down below.
So let's go ahead and do that.
And let me go in here between these two
paragraphs and type out a open bracket,
br, closed bracket,
indicating line break.
Indeed here, br is obviously
not a complete word.
It's just an abbreviation,
because HTML ultimately
tends to optimize characters.
And for any type of tag, so to
speak, that you might use frequently,
it tends to have a shorter
name or nickname like this.
Now curiously, about br, that's it.
I'm done typing.
Because with a line break, it's
either there or it's not there.
You can't really start breaking a
line and then stop breaking a line.
You either do it or you don't.
And so the br tag, unlike
HTML head title and body,
does not in fact have a
corresponding end tag.
You could theoretically go ahead and
say open bracket, /br, close bracket,
but it has no meaning.
And you shouldn't put
anything in between anyway.
And so, it's not strictly
necessary and HTML5
allows you to omit that altogether.
Or if you really do
like to feel symmetric,
can you put the forward slash inside
the tag right there at the end.
So here, too, the language itself HTML
allows for all of these possibilities.
But why type more characters
when you can type fewer, and so
we'll leave it, for
instance, as just this.
Let me go ahead and save now
the file and reload the browser.
And you'll see that it doesn't seem
to have quite solved the problem.
Now it did make sure that, that first
paragraph ends and the next one begins
here, but I don't see
the space that I'd like
to see as in a magazine
or paper or book,
whereby those two paragraphs
are truly distinct.
So how can I do better?
Well, if one br tag got me one
break, why not use two get two?
And so, let's do that
in my code instead,
this time doing open bracket, br, close
bracket again, telling the browser,
give me two line breaks here.
And if I now reload
that page in my browser,
I do in fact see a gap
between paragraphs.
But this feels a little
bit hackish, and frankly,
old-school, akin to a typewriter,
where the only expressiveness you have
is what you can do mechanically.
But these days in software, we
should certainly be able to do more.
And so indeed, HTML accommodates this.
Rather than just break lines, why
not tell the browser, hey, browser,
here is a paragraph.
And say that a couple of times
for a couple of paragraphs.
So let me go back into my code here,
and instead of this line break,
instead first go to the start of my
text and say hey, browser, here comes
a paragraph, abbreviated just p.
And just for consistency, I'll go ahead
and indent the rest of that paragraph.
And notice my text editor is smart
and it's moving everything over,
just so that I can see that this is
all part of one thought, if you will.
It's not actually adding all of
these spaces to the actual output.
But when that paragraph is done, I
should tell the browser as much and do
open bracket, /p, close bracket,
thereby saying hey, browser,
that's it for this paragraph.
But I again want to say this a second
time and so here on my second line
will I go ahead and say open
bracket, p, close bracket.
And then below that paragraph
of text, go back down
and finish that thought as well.
And so, it's a bit more
verbose now because I
have to say, both start and
stop, or open and close.
But now, I've told the browser
all the more explicitly what
instructions to follow.
And if I go back into my
browser and reload now,
we'll see that I indeed still
have that gap between lines,
but I no longer have to
fairly hackishly, if you will,
hit line break, line break just twice.
So that's how I get paragraphs.
How about a list, whether
a to do list for the day
or a whole list of thoughts.
Well here, I've readied
a page called list.html.
And as before, I've structured it
in the usual way, DOCTYPE up top
and then HTML at the top, close HTML
at the bottom with a head and a body
in between and only a title.
So let's now focus on making
a list inside of that body
and suppose that I have three
thoughts on my mind, foobar
and baz, the go-to words
for any computer scientist,
not unlike xy or z for a mathematician.
So if I have three things
to say, I might go ahead
and say, foo bar and baz, one per
line, just as you might on a tablet
or on an actual piece of paper.
And let me go ahead and Save this
now and open it in my browser.
And unfortunately, just as you might
expect, per our foray into paragraphs,
each of those thoughts
ends up on that same line.
Well, why is that?
Well, I haven't told the browser
to give me separate paragraphs,
let alone lines.
And indeed, these really
aren't paragraphs.
Now, I want for myself a proper list.
Well, it turns out that
HTML does offer that
in the form of multiple types of lists.
And in fact, if I go back to my
code and am a bit more explicit
this time, I can say,
hey, browser, give me
a list, specifically a UL or unordered
list, one that will not have numbers.
And then beneath that, I'm going to go
ahead and indent my previous thoughts.
But this time, I'm going to
surround them with open bracket,
li for list item, and then open
bracket, close li, for the same.
Then, each of the elements below will
get that same wrapper, if you will,
open bracket, li, and then
open bracket, close li.
And then lastly, so does get baz.
Of course, I need to
finish that whole thought
and say hey, browser, that's
it for my unordered list.
If I now save this and go back to
my browser and reload, what I'll get
is that unordered list, complete with
bullets given to me by the browser.
And here now, do I have the ability
to start formatting a page in a fairly
standard way without having to
worry about how do I get the bullets
and where do I put them.
The browser can do that for me.
Now to be fair, it's up
to the particular browser
how to render that unordered list.
And different browsers,
Chrome or Firefox or Edge
might interpret that ul tag differently.
But for the most part, we
humans have agreed universally
what these bullets should look like.
But what if I want this list to
actually be ordered and not unordered.
Well instead, I can actually
use ol instead of ul,
thereby giving me an ordered list.
Here, I need only change that
u to an o and this u to an o
as well, hitting Save, not
even adding any numbers myself.
And if now I go back to my page
and reload, I automatically,
for free so to speak,
get my 1, 2, and 3.
And you can imagine then, the
utility of this, not so much
for foos bars and baz's, but
rather when these lists get long.
You, as the developer of
the web page, no longer need
to worry about keeping track
of these numbers, let alone
if some additional element needs to
be inserted at the beginning or middle
or end of that list.
You don't have to worry
about renumbering that page.
After all, computers can save us
time and solve problems for us.
And this is just one with which
we're scratching the surface.
Well that then is a list.
Suppose I want to start writing whole
chapter or sections or subsections
thereof.
Well, it turns out HTML
can help me with that too.
Because up until now, we've seen
no mention of font size or font
weight, bold or italics or the like.
And it turns out, we can nonetheless get
some of those features via HTML itself.
Within the body of this
page, for instance,
suppose I have the first
chapter of my book.
Well, I can go ahead and
say open bracket, h1,
for heading one, the
first topmost level.
And then I'll simply say
for now something like 1.
I'll go ahead and close that tag with
open bracket, /h1, close bracket.
And then, let's move on to the next.
Suppose that within chapter
1, there is a section,
and so it is diminutive
with respect to the first.
And so here, I'm going to say not
h1 but h2, thereafter saying a word,
like 2 itself, open
bracket, /h2, close bracket.
And if we continue this logic doing h3
followed by 3, and close bracket, h3,
and h4, followed by 4, and close, h4,
and then open bracket, h5, F-I-V-E,
followed by, close 5, and
then lastly h6, followed by 6,
and then we can complete
that thought as well.
And that's as many levels as you get.
Beyond that, you'd better
start reorganizing your book.
I'm going to go head now and save
this file and open it in my browser.
And what do I get?
Well, I get a whole hierarchy.
At the very top, is one in the
biggest boldest text that we see.
Beneath that, is still some text
that's bold, but smaller still.
And repeatedly, does
the font progressively
get smaller, but still boldface,
thereby, drawing attention to it,
just as you might in a book.
So HTML does all of that for free
and we can commingle these tags
so that I have paragraphs of
text, but above and below them
these section headings, h1 through h6.
Now web pages are so
much more than just text,
so much more than headings and lists.
They're ultimately,
frankly, about links,
hyperlinks from one page to another.
So how with HTML can we go about
linking one page to another.
Well again, with these tags.
Here is a file called link.html and
it too has our boilerplate code.
I have a HTML tag, a head,
and a title, as well as
a body where our code need now go.
So within that body, let's
go ahead and encourage people
to visit Harvard, Harvard's website.
And I'll proceed to say visit,
https://www.harvard.edu.
Now my text editor here
is being quite friendly.
It's actually underlining it for
me as though it's just a link.
But browsers are not so friendly as
these text editors that developers use.
And indeed, if I save this
file now, go into my browser,
and open this file, what I
see is literally what I typed,
visit https://www.harvard.edu.
And yet, it's not underlined here.
And indeed, I can try clicking this
all day long, highlighting it too--
nothing actually happens.
And that's because the browser
has taken me literally.
All it saw in my file was
visit https://www.harvard.edu.
I never actually told
it to link to that page.
So if I go back to my code, I
need to be more explicit it seems.
And indeed, there's a tag for just this.
Historically, it's called the
anchor tag, or short, just a.
So open bracket, a.
And now I need to tell the browser
where to take the user, and albeit
redundantly, let me first type href,
for hyper reference, = "that URL".
And now I have the opportunity
to tell the browser what
to display to the user.
So rather than say the URL, I'm going
to say the more user-friendly, Harvard,
followed by open bracket,
/a, close bracket.
And at this point, notice
the slight asymmetry.
Whereas, I've opened the tag with an
href, I've closed the tag with just a.
Indeed, whenever you
have a tag whose behavior
needs to be customized in this
way, the behavior of the tag
influenced by an additional
input otherwise known
as an attribute of
which href is just one.
What you do in closing the tag is only
mentioned with that one forward slash,
the name of the tag not the attributes.
Otherwise, you'd be repeating
yourself all day long.
And indeed, this is
indeed more generally
an attribute, a key word defined
in the HTML language that
somehow modifies the behave of the
tag inside which you've typed it.
And its structured typically as
some keyword, like href, followed
by equals and then a pair of quotes, may
be single or double, and inside of that
is some value.
So here, too, we see a theme we've
seen in other contexts and languages,
key value pairs, some word
associated with some value.
And this one, as we'll
soon see, will modify
the behavior of the anchor
or a tag to actually create
a link, like the one we see here.
And so, if I go ahead and
save this file and go back
to the same page in my browser and
click reload, what I now see is that,
visit Harvard, this time underlined
and in that familiar blue.
And indeed, if I hover over
this link, albeit small,
you'll see a little clue in
the bottom left of your screen,
at least if using Chrome, that tells you
preemptively where, if you click that,
you'll actually end up.
Of course, there's a
bit of a threat here,
I dare say, whereas I might say one
thing, I might actually mean another.
And in fact, I could, for instance,
were I a rival, go into this code
and instead say, oh, please visit
Yale, saving the file thereafter
and reloading.
And here I see now a
message to visit Yale.
But of course, if I
hover over that, it's
really just an invitation
to visit www.Harvard.edu.
Well, this is just playful.
We could actually be
more malicious than this.
And indeed, if you flip through
some day your spam folder,
odds are you'll find some
message you've not ever
seen that actually does have
hyperlinks, because these days, emails
can be written by computers or humans
in HTML and displayed as web pages
within your browser.
But within your spam folder
might very well be what's called
a phishing attack, an
attack by someone who
is trying to socially
engineer you into clicking
one link that you think goes someplace,
but actually go someplace else.
For instance, I might
here say, you know what?
Go ahead and visit PayPal.com, thereby
inviting you to visit this page.
And if I now reload and look at what's
here, I'm invited to visit PayPal.com.
And yet, if I click that, I'm clearly
going to end up at www.Harvard.edu.
Well, that isn't necessarily
all that malicious, but were
that URL not to be www.Harvard.edu,
but some domain name some bad actor
has bought, trying to trick you
into giving him or her your username
or password or credit card information
or something even more personal,
it truly is not all that hard
with these basic primitives.
This is how HTML works
and phishing attacks
are derivative of exactly this design.
So what do you do?
Well, you could certainly adopt
a habit of hovering over links
and realizing, mm-mm, I'm not
actually going to PayPal.com.
Most of us probably won't be so
paranoid as to do that regularly.
But with antivirus software
and tools that are cloud-based,
can we detect some of
this automatically.
And indeed, browsers like
Chrome will occasionally,
if they know through experience
some website to be bad,
might even warn you within that window.
And corporate networks
as well can certainly
do this, albeit at the
cost computationally
and in terms of your
privacy, of monitoring
all of the emails and traffic
going in and out of a network,
thereby being capable of alerting
users if they see something dangerous.
But it all boils down to
these basic, simple tags.
And indeed, this was
just the first example
of using an attribute to modify
the behavior of some tag.
It turns out there are others that you
can used more for good and not evil.
And indeed, on the HTML tag itself it's
not uncommon to specify a language,
for instance, this one here.
Your browser might be
in the habit, if you
visit some foreign website,
of asking you, would
you like to translate this page from
its native language into English.
And one of the clues you can provide
to a browser is exactly that.
Hey, browser, here comes a web
page written in HTML, specifically
with English text or any other, thereby
helping those automatic translation
tools to know what it
is they're looking at so
as to translate with higher probability
of success it to some other language.
Now, web pages are so
much more than just text.
They have images and
sounds and videos and more.
So how can we go about
embedding media in a web page?
Well, it's again thanks to
these tags and attributes.
Here, for instance, is a
file called image.html.
I've begun as I always have with DOCTYPE
in HTML, head and body, and therein,
a title.
And this time, I've proactively said the
language of this web page and any other
is going to be written
in my own English.
And now suppose that I have on my hard
drive here an image called cat.jpeg
and I want to embed that
image in my web page.
How do I do it?
Well, I'm going to go ahead and this
time start with an open bracket, img,
which is short for image, and then
specify that the source of the image I
want is going to be src,
for source, ="cat.jpeg".
Thereafter, I'm going to go ahead
and close my tag and save this file,
and go ahead now and open it up.
And we'll see here, exactly that,
a cat, a grumpy cat, in fact.
And the browser has done
exactly what I've told.
I've said hey, browser, here comes
an image, the source of which
should be this file called
cat.jpeg, and it does exactly
that, embedding it as the
very first thing it sees.
Now, this is not nearly as accessible
as it might be in multiple ways.
One, if I'm on a slow
internet connection,
the human might not see this image all
too soon as his or her phone or browser
downloads it slowly, and it'd be
nice to have some place holder text.
Moreover for
accessibility's sake, if I'd
like to ensure that users who are
blind and require screen readers
can actually have this image
recited or described to them,
have an actual hint in the code
with which to describe it verbally.
So how might I do this?
Well, in HTML you can have multiple
attributes, not just zero or one,
but a second one too.
For instance, alt, the
alternative text for this image
shall be, for instance, one grumpy cat.
And if now I were to reload
this page on a slow connection,
would I see that text, or if using a
screen reader, have it recited to me.
Now, how about data with even
more structure-- something
tabular with rows and columns
and numbers and names?
Well, here too, HTML
provides us a mechanism.
And in fact, this one,
I'll cook in advance.
In this file, do we have table.html,
some of our familiar structure,
but also some new tags.
Indeed, in the body of this page,
do we have a new one called table.
Open bracket, table, close
bracket, which just says,
hey, browser, here
come some tabular info.
And below that, do we have a less
obviously named tr tag, that says,
hey browser, here comes a table row.
Within that table row tag,
which is only later closed,
do we have three td tags,
it would seem, 1, 2, and 3.
Well, td stands for
table data and denotes
here comes a column or cell, the
actual data in this position.
And the close tag, of course,
means that's it for that data.
1, 2, and 3 followed by 4, 5,
and 6, 7, 8, 9, each of them
in their own table rows.
What sort of effect might
that have in the end?
1, 2, 3 in one row, 4, 5,
6, in another, 7, 8, 9.
And if we scroll further, it turns
out, an asterisk, a zero, and hash.
What have I laid out in tabular form?
Well, you might not see it so often
if you're using your contacts,
but on a typical phone, this is exactly
how those numbers and symbols are
laid out, really in rows and columns.
And if I go now and open
up this file in my browser,
will I see that, albeit, fairly small,
laid out top to bottom, left to right.
Indeed, here in table.html,
once viewed with a browser,
do I see my 1, 2, 3, 4, 5, 6, 7,
8, 9, and asterisk, zero, and hash.
So you can certainly imagine longer
words or phrases, dollar amounts,
or any data being laid out
in this way, even taking up
the entire width of the screen,
otherwise known as the viewport.
Now, to add one last
piece of jargon here,
even though these tags
open and close are each
called just that, collectively,
what we have on the screen here
are any number of HTML elements.
An HTML elements is a
higher-level concept,
such as you might see
in a data structure
in memory that represents
everything between this start tag
and end tag and everything within.
In fact, what we keep
looking at here in HTML
form is really a tree of some sort.
In fact, it's no accident
that I've been deliberately
indenting every level of my code
here so that the browser knows
what's inside of something else.
Now, to be fair, I
could delete almost all
of the whitespace, all of the
tabs and spacebar characters
that I've typed thus far, because
again, the browser doesn't care.
This is mostly for
your benefit and mine,
so as to read our own code
top to bottom, left to right,
and see it quite quickly.
But it turns out that the computer
when reading this code top to bottom,
left to right, actually loads
it into its own memory or RAM
in a tree-like form.
After all, at the very
top of this file is
this one very important tag-- hey,
browser, here comes a web page in HTML.
And then nested inside of that, slightly
indented, is both head and the body,
much like in a tree structure, might
a node have one or two children.
Meanwhile, within body, do you have
another child table, inside of which
is one, two, three, four table rows--
four total children.
And within just one of those children,
say this table row, are three children,
as well.
So akin to a real-world
family tree, do we
have a number of root elements,
so to speak, each of which
have children of some number, at below
which might be grandchildren and more.
So how might we see this?
Well, this is generally known
as a DOM, document object model.
And HTML would have us
think of it as just this.
This then is the simplest of web
pages with which we began, whereby,
we had hello, title, hello, body,
and plus this time, lang=english.
But on the right, here, do we
have an artist's rendition of what
a computer would do when that browser
reads this HTML file top to bottom,
left to right.
Well, at the very top
of this tree, we'll
just call it the generic document, some
sort of reference to everything inside.
But the one in one only
children that we've
seen thus far beneath that
is that HTML element, which
itself has two children-- head on
the left and body on the right.
Meanwhile, that had element,
indented inside of that, was title.
And so, we see title as its sole child.
And inside of that was not another
tag or element, but rather just text,
a text node in this
tree, and that's why I've
drawn it in this very
different shape, to make clear
that it's not an element that has
some notion of starting and ending,
but rather it's just the value,
effectively, of that particular node.
And down here in the body did we only
have a short phrase, hello, body.
And it too was a leaf, so
to speak, of this tree.
And here, then we see the
intersection of the human and computer
in our discussion itself
of data structures.
Here is the computer using a
fundamental core concept of CS,
while allowing the human,
or really the computer,
to think at a higher
level of abstraction.
It does not matter how this
is represented in memory,
but that it is represented and can be.
And so here, via this indentation, do
we see a hint at what the computer is
ultimately doing.
Now finally, what about user input?
Suppose that you want your web
page to interact with the user
and actually ask them for some
textual input, like a web form might.
Well consider this file here,
search.html, which I've, again, begun
as always, and I'm now ready
for the body of this page.
Well, it turns out that HTML
also indeed supports forms,
such as any of those text boxes
or check boxes or dropdown menus
that you might see on
a typical web page.
And this tag for this is quite simply
open bracket, form, close bracket.
And I'll go ahead now and
preemptively finish that thought.
And it turns out that
within form tags can
you have so-called inputs, each of
which can be of some disparate type.
For instance, here I'll go ahead
and say, inputs, the type of which
shall be text.
And then hereafter, I'll go ahead and
have another input, input type=submit,
thereby giving me, per HTML's
own documentation, inputs,
that is UI mechanisms, via which the
user can provide textual input and then
submit it to some server.
Let's go ahead and save this
file and open it in my browser.
And what I see now is quite
simply this, a text box
that just seems to be waiting for
input, followed by a Submit button that
will submit it to some server.
Now, we can clean this up a
little bit, because I don't really
know what I'm looking at.
And so, let me go back to my code and
put a place holder in this text box,
literally adding another
attribute that says,
for instance, query, whatever it
is the user wants to search for.
Meanwhile, let me change
the value of that button
to actually say not the default submit,
but for instance, more clearly, search.
And now if I reload this page, it's a
bit more self-explanatory to the user.
It's not just an empty box,
but one that says query.
And that button explicitly says search.
And if I begin now to
type in this box, query
will go away if I want
to search for, say, cats.
Of course, if I click search now,
what's going to become of this input?
Well, nothing, because I have no
back-end server, let alone database.
But you know what?
I know who does--
Google.
And Google is very good
at searching the web.
So let's see if I can't glean
via http how Google itself works
and see if I could
make my own front-end,
that is, web page for Google,
but defer all of the logic
to Googlers own back-end.
Well, let's see exactly what happens
when I search Google for cats.
Here we go, Enter.
And voila, I'm whisked away to any
number of cats-- more than 4 billion,
indeed.
But let's focus not so much on the
actual results on how we got them.
Indeed, if I focus on
the URL, up here, you'll
see that this URL itself begins with the
familiar https://www.google.com/search,
a program of sorts on
Google's servers that
does literally that, search the web.
Then, there's this
question mark followed
by a number of other words and key
phrases and a number of equal signs.
And if I keep looking, ampersands.
It turns out, that http specifies
not only how web browsers
and servers communicate within
that so-called virtual envelope,
but also how the browser should format
the user's input when submitting it
to some server.
And in fact, there's
so much up here that I
don't understand at first glance.
I'm going to just start
deleting things from that URL
that just seem unfamiliar.
But familiar, of course, after I
delete just a few characters is q
equals cats, which would seem to
relate to whatever I typed in.
In fact, let me go ahead and erase.
Everything after that is irrelevant.
Hit Enter again and
search much more simply.
And I still get those cats.
Well, what does that mean?
Well, it seems that http
prescribes that in order
to provide input from browser to
server, you literally visit some URL.
You append to that URL a question
mark, thereby saying, hey, server,
here comes some inputs.
And those inputs have
names, for instance, q,
followed by an equal sign and
then whatever the human typed in.
And if the human had typed into multiple
boxes or maybe checked some checkboxes
or selected for menus, well those
additional inputs or http parameters
would all appear in that URL
separated by ampersands, each of them
a key value pair, separated with equals.
Well that's all I've searched
for here and you know what?
I bet I could mimic this behavior.
I know the URL to which I
want to send the user's input,
and I can defer to the
browser to format that input.
It remains, then, only to somehow
wire this logic into my web page.
So let's go back to that web page
and finish our form's thought.
The action I would like this
form to take, so to speak,
is to submit specifically to
https://www.google.com/search,
the URL of that program
running on Google servers that
does quite simply search.
I don't need to type a question
mark q or an equal sign,
and I certainly don't want to type cats.
That should come from the user.
But I do need to give the
users' input a name, which I'll
do here with now a third attribute.
The name equaling q.
Why q?
Well, that's clearly
what Google decided,
and it turns out some 20 years
ago, so did Larry and Sergey
at Google, in its infancy, decide
that the name of their query parameter
would simply be q.
My other input doesn't
need a name, per se,
because it's just a button that
needs to trigger that submission.
And so now, if I save this file and
go back to my own browser and reload,
I still see the same form
here, a query with a button.
But if I now go ahead and,
for instance, search for cats
and hit Search, indeed the URL to which
I whisk my users away is just that,
q equals cats.
Now, to be clear, cats are
not hard-coded in this page.
If I go back to my own and this
time search for, say, dogs,
I can go ahead and search for those too.
My browser will presume to append
dogs after that equal sign,
thereby allowing me to search
dynamically for anything I want.
Now there's a few other
features here that relate really
to you ux, user experience.
In this form, now that I've
searched for a couple of things,
you'll notice that the browser wants
to complete that thought for me, using
what's generally known as auto-complete,
a browser's specific feature,
sometimes, that remembers the
words you've typed into some box
and then reminds you of such
just to save you keystrokes.
Now, you might not want this to happen.
You, the web page, might want to
implement this sort of feature
yourself.
And so we can actually turn off
that notion of auto-complete.
Moreover, if I visit this web page,
the very first thing I have to do,
it would seem, is actually
click in that box.
I can't actually type until
I have focused on that input.
And this, too, is not all
that good for user experience.
Why make me, if I already come
to your website to search,
the first thing I need to do
is actually click in that box?
Why not click on it for
me yourself with code?
And we can do this with HTML.
Indeed, if I go back to this input
here, and I say, you know what?
Go ahead and turn
auto-complete, "off" as well as
auto-focus on that particular box.
Now here we see already an anomaly.
In HTML5, attributes don't
have to have values, per se.
They need not be followed by an equal
sign or double or single quotes,
you can specify the attribute's name.
And if its present, it means give
focus automatically to this text input.
And if it's not present,
just don't do that feature.
Now indeed, if I go back to
my browser and reload, what
you see now is even with my
cursor away from that box,
does it already have focus.
And on Mac OS, here, does it
tend to highlight in blue.
But other operating systems and
browsers might do it a bit differently.
But the key is I can search for
immediately without clicking anything
I want, without now, this time, even
being prompted for my last input cats
or, say, dogs.
Now, thus far, our web pages
have been fairly simplistic,
but there's so many
more tags we can use.
But those tags all
follow a similar format.
A tag's name followed by
zero or more attributes.
But some of those tags have
more meaning than others.
And can we begin now to
stylize our page further
through fonts and
through colors and more.
Consider, for instance, this
home page here for John Harvard.
Welcome to my home page,
copyright John Harvard.
How might we go about
structuring this page with HTML?
Well consider this file here,
which I've written already.
Here in this file to I have really three
paragraphs, one on top of the other.
And within those
paragraphs, do I have text.
Now, one anomaly that we've
not yet seen is that copyright.
I'm not sure where on my keyboard
to type a c within that circle,
but it's indeed a symbol that
computers and printers can express.
And within HTML, indeed, can you
express those same characters,
even if they're not readily
accessible on your own keyboard.
This thing here, ampersand#169;
is what's known as an HTML entity.
That ampersand says, hey, browser,
here comes an entity, number 169.
And that semicolon means
that's it for that.
Now, within the computer's
memory is a list, essentially,
of all of these codes that correspond
to the symbol, the punctuation,
that you want to display.
And so here, do we get in the actual
browser the graphical version thereof.
But these aren't, strictly
speaking, paragraphs, per se.
Indeed, these are really just
different divisions of the page.
And so, there are other
tags in HTML, like exactly
that, div, whereby you can
fairly generically say,
here comes a division of my page,
really an invisible rectangle, a swath,
from left to right across the screen
that represents this information,
then this, then this.
Of course, that doesn't really have
much meaning unto itself either.
And so in HTML5, the latest
version, are there more
semantically meaningful tags.
For instance, this feels like,
perhaps, the header of my page.
And perhaps this is the
main aspect thereof.
Meanwhile, this copyright
might be relegated
to the simple idea of a footer.
And so HTML also has
tags like those there.
I can actually call this not the head,
but the proper header of my page,
and I'll close that tag there.
Here might be the main part of my
page, and so I'll call it just that.
And then down here, will be the footer
of my page, which I'll specify as such.
And now I further refine the semantics
of my web page, which does not
change at all the layout, but it
does help the browser perhaps,
both now and in the future, better
understand what it is it's looking at.
And indeed, for SEO,
search engine optimization,
the more hints you can provide to
the Google's and Bings of the world,
the more they can know what it is
they're searching and how to index it.
Moreover, they know perhaps what
to display in search results
if the main part of the page is
this and everything else is just
header and footer.
So the more hints you can provide
to the browser, and in turn web,
is probably a good thing
for your own website.
But of course, if I
reload this same HTML now
it's going to look exactly the same.
But with these tags, as
well as with div and with p,
I can actually begin now
to stylize my website more.
But I can't rely on HTML
alone, at least not with HTML5.
I need a second new language.
And indeed HTML works
wonderfully well in conjunction
with a second language called
CSS, cascading style sheets, which
allows you to take a
website that last mile
and get the aesthetics, the colors,
the fonts, and the positioning,
just right, leaving less to
the browser to just infer.
And with CSS though, we need to somehow
remain within the confines of our HTML,
at least for now.
And so how might I provide
yet another language?
Well, these attributes of
HTML provide one solution.
For instance, suppose I want to
specify that the style of my header
shall have a very large font size.
I can indeed say font-size:large.
And here in the main
part of my page, well,
I'm fine with the style thereof
of being font-size:medium.
Meanwhile, the footer is
sort of my last thought,
and so I'll style it ever so
smaller with a font-size:small.
Now what is this then
that I've just typed?
Well, this is CSS within the
confines of my HTML attributes values
surrounded by quotes have I
specified CSS syntax, which
follows this pattern--
some keyword, like font
size, followed by colon,
followed by that so-called
property's value.
And indeed here, the property I'm using
throughout this page now is font size,
but with three different values-- large,
medium, and small, pre-determined words
that every browser
should just know, even
though they're more relative
than they are fixed.
And so let's go now and save
this file and reload the page
and now we'll have the same content,
but stylized differently still.
Indeed, when I reload
the page now, I still
have three lines of text, three
paragraphs, or divs, or now sections,
if you will.
But John Harvard's text is indeed
a bit larger and my welcome to home
page is just medium.
Meanwhile, copyright John
Harvard is ever so smaller,
because I've now applied styles
to each of these sections.
But it'd be nice if this, after
all, is John Harvard's home
page, let's greet everyone
right in the middle,
and align that text in the center.
Well, how might we do that?
Well, it turns out that with CSS, you
can specify one or more properties
within each of these pairs of
quotes, simply separating them
with a semicolon, thereby finishing the
first thought, and starting another.
And so I might now say something
like text-align:center.
And then down here, do the
same-- text-align:center.
And then lastly, here the same--
text-align:center.
If I now save this file,
reload the page, what I see now
is exactly that same text,
but now nicely centered.
And so now do I have, through
this combination of HTML and CSS,
a wonderful marriage of
structure and style, each of them
focused on really particular tasks.
But there's some redundancy.
And indeed, any time you find yourself
doing the same thing again and again,
like text-align:center,
text-align:center, text-align:center,
you're probably doing something wrong.
Surely, there's an opportunity here
to factor that out and somehow say
that thought just once
and apply it throughout.
And indeed, here's one hint of what
we mean by cascading style sheets.
That first c implies that
you can have one property
sort of affect multiple things
in your tree, that so-called DOM.
After all, with header
and main and footer,
notice that they all share a
common parent, so to speak,
in the family-tree sense.
That parent here his body.
And if I want everything
centered but disparate font sizes
for each of those
sections, you know what?
I'm going to go ahead and just remove
each of those text-aligned centers
and move all three of those to just one
on the parent, saying, hey, browser,
the style of its body should
instead be text-align:center.
If I now save this page
and reload, voila--
it actually still looks the same
because the effect is the same,
but now, I've been more succinct.
I've typed fewer keystrokes,
thereby saving time,
and I've also ensured now
that design-wise of my code,
if I need ever change that
value, say to left or to right,
I can only change it now in one
place and affect everything.
But there's still an opportunity
to design this code better.
Up until now, I've been commingling
one language with another,
mixing in my CSS properties inside
those quotes, inside of HTML proper.
Now, it turns out in industry,
this isn't always best practice
to have one language
right there in another,
if only because if I'm working with some
colleague who's focused on the site's
aesthetics, the UI designer, whereas
I'm the web developer focusing
on its structure, it would be nice if
the two of us could work independently,
but collaboratively.
But it's hard to imagine how that
work well if his or her code needs
to be commingled with mine.
So it tends to be better practice
to actually factor out one language,
say CSS, and remove it
from those attributes
and put it, for instance,
in a tag of its own.
Now, that's not a hard and fast rule.
In fact, increasingly,
in web development
there is this notion of components,
whereby one human doesn't
work on just one page, but some
portion thereof, a component,
like just the search box,
or some other feature.
And in those cases, are we actually
seeing an industry of tendency
in the opposite direction, whereby
he or she combines their HTML
and CSS into one.
But for this process, whereby I'm
creating not components, but web pages,
probably shouldn't be
commingling them there.
So indeed, I'm going to
go into this same code,
remove those style attributes,
and instead, go back
to the head of my page,
where historically, I've
had nothing else but my title,
and now go in and add a style tag,
not attribute, opening and closing
it within the confines of that head.
And inside of this style tag can I now
go ahead and type CSS, all indented
as always just for beauty's sake.
But here, I can go ahead and
specify well, what tags in my HTML
should have what properties.
And I can do this by name.
For instance, the body of my web page
shall have, as per these curly braces,
the following property
well, text-align:center.
Meanwhile, the header of my page,
not to be confused with the head,
shall instead have font-size:large.
Meanwhile, the main part of my
page, as before, this time though,
up here shall have font-size:medium.
And then last but not least, is
the page's footer, which as before,
will have a font-size:small.
And here too, do we still
have that same cascading
feature, whereby, body is still a
parent of those three other tags.
And that body shall be
text-aligned:center.
But header and main and footer shall
each have their own respective font
size.
Now, why these properties in particular?
Well, you would only
know which properties
exist by consulting some
documentation or class.
But indeed, text align and font size
and font family and color and more
are all defined by CSS as
being available properties,
just as with HTML whereby you might
hereafter look up in some reference
the available tags, so in CSS can you do
the same, to see what properties exist
and for what HTML tags.
So if I go now and reload this page,
the effect should be visually the same,
but I now have at least moved all
of my CSS to the top, at least
within the head of my page, and all of
the HTML, or most of it, down below.
Indeed here, it looks exactly as
expected, no different from before,
but design-wise, underneath the hood,
have I now structured it better.
But it turns out, you don't have
to apply CSS properties only
to HTML tags in this way.
You can actually create reusable
collections of properties
that you can apply to this tag or
this one or multiple tags altogether.
In fact, let's go now to some
HTML that's almost the same,
but create some new collections of
properties quite like those here.
And so, let me go ahead
and say, I would like
a class, or a collection of
properties, called centered,
as indicated here by that dot.
Indeed, in CSS, if you have
not just a word, but a dot,
it says this is a class, a custom
name, that you yourself provide.
And inside of the curly braces now
and am I going to do just as before,
text-align:center.
But suppose I now want
some reusable classes
as well that express the notion
of small, medium, and large.
Well, I could have one called
large, inside of which, for now,
is just one simple property,
like font-size=large.
Meanwhile, might I have medium
defined almost the same.
And lastly, might I
again have, say, small,
that just as these
others do exactly that.
So my code is a little
different, but now I've
associated properties
not with hard-coded tags,
but rather with words,
class names, so to speak,
that I can apply anywhere I want.
So as to achieve the
same effect as before,
but now using these reusable commodity
classes can I go down to my page
and say, well, my body shall
have a class of "centered".
Meanwhile, my header shall
have a class of "large".
And the main part of my page,
meanwhile, will be medium, as before.
And that footer, lastly, shall be small.
So the effect, for me the
programmer, is a little different.
I'm not actually changing
all that many keystrokes,
but I now have these collections that I
can reuse here or in other tags still,
particularly, if this
page were even bigger.
If I go ahead and reload the page
now after saving that file, voila,
it still looks the same, because
again, we're focusing now
not on correctness, but also design.
And so with CSS are there best
practices or at least good practices
for this particular
context via which we can
implement our same ideas but better.
But there's still one last opportunity
here, I daresay, to do better.
Suppose that colleague of mine with
whom I'd like to collaborate actually
would prefer to work on their own file.
After all, I'm still
commingling my CSS with HTML.
It just happens to be
not in those attributes,
but in one bigger tag up top there.
And so, why not just factor all of that
CSS out and put it in a separate file
and then just tell my
HTML file how to find it.
And indeed, let's do this,
with one final flourish.
Here under new file, css3.css
are those same CSS classes
inside of which are those properties.
But now, all of this
code is in its own file.
Meanwhile, I'll have another
file css3.html, which
before had all of my HTML and CSS.
But this time, here, has
just one new tag link.
This tag link says to the
browser, hey, browser,
link this file to this
other one called css3.css.
And the relationship between
one file and the other
is quite simply that of style sheet.
And so effectively,
what the browser does
here is copy-paste the
contents of that CSS file
as though it were at
the top of this page.
But the effect ultimately,
for development purposes,
is that now I have my so-called
separation of concerns.
And I, and any number of
colleagues, can work now truly
independently on these two files,
aggregating later the net effect
together.
Moreover, because this CSS
file is now factored out,
I can reuse that same CSS
file not just on this page,
but dozens or hundreds of others.
And so, if indeed, you put in one
or more files all of your CSS,
you can reuse those entire files.
And browsers themselves are smart and
try to be as efficient as possible.
And so, if a browser realizes that while
you visit some website that this page
and that both use the
same CSS file, the browser
can be smart and download
that file just once,
thereby saving you the user,
time, because you don't
have to wait for that file to download.
And it saves the website
bandwidth because it doesn't
have to download that same file twice.
So simply by focusing not only on the
correctness of the content that you'd
like to display and
the aesthetics thereof,
but on the underlying design, can
we build systems that scale better
and can be built by so many more people.
So with HTML can we structure our
web pages and the data therein?
And with CSS, can we take
things that final mile
and stylize it just
the way that we want?
But everything we've coded
thus far has been static.
I write it.
I save it.
And then everyone else reads it.
But of course, so many of
today's websites are dynamic.
They take users' input and they produce,
per every user, disparate output.
So how can you do that?
Well, you need for that to work,
a proper programming language.
And some of that logic that changes
the data and changes the pages
that users see, can be done on the
server-side with languages like Python.
But a lot of it, and increasingly so,
can it be done client-side, on the Mac
or PC itself within the user's browser.
And the language via which
this is done these days
is via JavaScript, not to be confused
with Java, another language still.
But via JavaScript, do
you have the ability
through writing functions
and conditions and loops
and Boolean expressions and
more to actually change a web
page once a user has downloaded it for
the first time in that virtual HTTP
envelope.
In other words, imagine most
any website you visit daily
that's constantly changing.
For instance, something like Gmail.
Anytime you receive a message in
Gmail or any web-based client,
you get, for instance, a new
row in a table, each of which
represents an email you've gotten.
Or on some social media
site might you get
messages that just pop up
at the bottom of the page
and you don't have to wait until you
click something or reload in order
to see them.
And so, with JavaScript what
you can do is send to the user
some initial HTML, the
simplest of web pages
that doesn't have all that much content.
But because the browser then loads
that HTML into memory, into RAM,
via the DOM, or document object model,
that tree, or more generally, data
structure, can evolve over time.
Just as you can add and remove things
from an array or a list, so can
a tree have more or
fewer nodes and branches.
And so, with JavaScript, a
proper programming language,
can you add data to a web
page by just asking via
HTTP some server for that data any
time a new email comes in and then
present it to the user,
really, but just adding
another tr, or table row to a table, or
another div, or another element still.
And so, with JavaScript, too, we have
the ability then to change web pages
and, most importantly,
listen for users' input.
For instance, here is a list,
but not even an exhaustive list,
of all of the events that might
happen while a human is interacting
with your website.
They might click or drag or change
something on the page, each of which
is an operation, or more generally,
event that the author of that web page
can listen for by writing
code in JavaScript.
For instance, if you've ever used
Google Maps or some other mapping tool
where you can click and drag in order
to see north, south, west, or east,
every time you click and drag you're
seeing more images, more tiles,
so to speak.
And if your connection
happens to be somewhat slow,
you might actually
see gray place holders
until all of a sudden new
squares suddenly appear.
That's because, behind the
scenes, is the browser requesting
more and more images from some
server and then embedding them
in the website dynamically, adding
more divs or some other HTML elements.
Moreover, if you have
Gmail, that again, is just
getting more and more
data from the server
and appending it or pre-pending
it to some HTML table
or some stack of big divs.
So there's any number of
events that we can listen for.
And those events at what underlie
every possible interaction you
have with a modern website.
It's just a menu of things
a programmer can listen for,
and can you listen for those
things with JavaScript.
For instance, suppose I want to
make my very first interactive web
page that has an HTML form.
But this interactive form
doesn't go to a server
like Google's, but instead, stays
right here and interacts with the user.
Well, I might have a form tag inside
of which are a couple of input.
So let's go ahead and
construct this UI and then
somehow write some
code in JavaScript that
listens for clicks of the
button, submissions of this form,
intercepts that submission, and then
does something with the user's input.
Here then, I have a
file hello.html, inside
of which I'll go about
implementing my form.
In here, have I opened
and closed my form tag,
and now I need the first of my inputs.
I'm going to go ahead and save
the type of this input is text.
But you know what?
As before, I'd like to turn
autocomplete=off, and auto focus,
for UI's sake.
And moreover, I'm going to go
ahead and have a input type=submit,
the value of which quite
simply will be submits.
Finally, for UI's sake, let's go
ahead and add a place holder of "name"
so that the user knows exactly
what it is we want of them.
Now, I'm not going to include, say, the
action attribute on my form elements
here this time, because I don't want
the action to go to some server.
Rather, I do want to
keep the user right here.
So you know what?
Instead of that default action, via
which the browser handles submission,
I'm going to go ahead and
say the following-- on
submit, literally telling the
browser when this form is submitted,
do this and not your default behavior.
Inside of quotes, I'm going to
go ahead and type now, not HTML
and not CSS, but code in JavaScript.
I want to go ahead and
say, greet the user.
And I'm going to go ahead
and quite simply say, greet.
Thereafter, I'm going to go
ahead and implement this function
as those parentheses would imply.
Indeed, JavaScript quite like
Python, looks very much the same
and has similar conventions.
Functions have names and you call them
with parentheses and zero more inputs.
With JavaScript, we achieve the same,
but through slightly different syntax.
Up here in the head
of my page, I'm going
to go ahead and now add
yet another new tag,
this one called script,
implying to the browser
that, hey, browser, here comes a
script or a small program written,
as this presumed, in JavaScript.
Now, in order to declare my
own function in JavaScript,
I don't say def, as in Python.
I instead say function quite literally.
And if I want this function
to be called greet,
I simply say it by name,
open paren, closed paren,
since it shall take no inputs here.
And then inside of curly braces, not
just indentation with some colon,
I'm going to go ahead and say
window.alert ("hello,world");
Here too, am I passing a string
or phrase into alert as an input.
And notice that alert itself
is associated with the window.
Well, it turns out in JavaScript,
you have some global variables,
if you will, one of which is
called window and refers to data
or functionality that's somehow
associated with the whole browser's
window.
Indeed, what I want to do ultimately
is have the user type in some input
and then display an alert that
says, hello, world, as in this case.
So that's it.
I have defined a function called greet.
I've hard-coded that I
want it to alert the user.
And I've told the browser
on Submit, to call greet.
Unfortunately, there's a
couple of shortcomings here.
Indeed, I seem to be asking
via HTML for the user's name
and yet never doing anything
for it, but that's OK.
Let's still break this problem down step
by step getting each milestone right
until we build on this success
hopefully with at least one other.
Let's go ahead and save this file here.
Go back to the browser and type my name,
David, followed by a click on Submit.
And there it is.
This page says, hello, world, an alert
of sorts that my browser, here, Chrome,
has displayed for the user.
So window.alert is a function built
into the browser window itself
that does exactly this-- opens
a prompt, says a message,
and then allows the user to click OK.
There's a small bug here though.
Indeed, when I click OK, you'll
notice that suddenly the page refresh
is entirely disappearing my name.
Well, that's not exactly
the behavior I intend,
especially if I want the
user's input to remain.
Moreover, I want to ultimately
do something with that input.
So this is a subtle change
to make, but it turns out
if in JavaScript you want to override
the browser's default behavior,
inside of this submit, I need
to say not one thought but two.
I need to tell the browser via a
Boolean expression return-false.
This is simply a convention that says
whatever your default behavior is
when submitting a form, do not do that.
Return-false.
Turn that off.
Instead, only called greet, which
is going to be this function.
This ensures that we don't accidentally,
not only take the user's input
and do something with
it, but also send it
off somewhere that's not here defined.
So now, let's actually capture
the user's name or input
and actually print hello, so
and so, instead of just world.
Well, to do this, we can solve
the problem in several ways.
I'm going to go up here in my greet
function and declare a variable.
The keyword in JavaScript I might use
for this is called let, so to speak,
let the following variable
take on some value.
And I'm going to Let's go
ahead and call that variable,
perhaps reasonably, name.
And then I need to go about getting
that value from the web page.
And here, that same picture we drew of
the so-called document object model,
or DOM, that tree, allows
you to think about where
this value's going to come from.
Somewhere in my computer's memory
is a tree structure and one
of the nodes or rectangles in
that tree is this text box.
In that text box, once the human
interacts with it, has some value.
So I somehow programmatically
in this new language
JavaScript want to express,
hey, browser, go get me
from the document that particular
node, and go in and get its value
and return it to me
so that I can store it
from right to left into this variable.
And the means by which
we can do that is this.
Hey, browser, go into
the document, thereby
accessing another global variable,
so to speak, alongside window,
and go ahead and select via a function
called query selector, so to speak,
whereby I can now specify the name of a
tag or some other expression via which
I can go get that particular input.
Unfortunately, that input
doesn't yet have a name.
Or better yet, it
doesn't yet have an ID.
It turns out in HTML
and in turn JavaScript,
if you want to proactively give
certain elements identifiers,
unique across the entire
document so that later in code
you can refer to that input and
not mistake it for any other,
you can give inputs not
only names, but ID's, simply
by saying, for instance, within
this tag here, the ID of this tag
should actually be "name" or
x or y or z or anything else,
but here, too, I'll name it quite aptly.
And now within my query selector,
I need just a pair of quotes,
single or double, and I need to now
express that unique identifier's name.
Well I'm going to go
ahead and say #name,
because it turns out in
JavaScript as well as in CSS,
you can specify or select a
specific tag by way of its ID.
And the browser only knows that
you mean an ID by way of this hash.
You don't write it down here.
You only write it here.
But the browser realizes,
oh, I see a hash,
you must mean the element
with this ID name.
So now, have I selected
from the web page's document
that node, that rectangle, from my DOM.
But I specifically want its value and
the syntax for that, quite simply,
is to say .value, go into that box, and
grab the text of whatever the user has
typed in.
So what now remains?
Here I have a line let name equal the
following value, for instance DAV ID.
And then I still have the window
alert hello, world, but I now
want to say hello to
that name-- hello, David.
Well, I clearly want to replace
the world with that name.
So how might I go about doing that?
Well, in JavaScript, we
have multiple options,
but perhaps the simplest is our old
friend concatenation, using a plus,
not between numbers, but between strings
or text values, and quite simply,
concatenate onto the end of
that thought hello, hello+name.
Now if I save this file,
go back to my web page,
and begin to interact
with it after loading,
I can go about typing my name and
hopefully, with fingers crossed,
do I now submit it and see not just
hello, world, but D-A-V-I-D Submit.
Hello, David.
And there then, with JavaScript,
have we rather come full circle.
Not only do we have the ability to
present data and the stylization
thereof, we also now have the ability
to change our minds later and manipulate
that page, perhaps even prompting
the user interactively with values he
or she actually typed in.
And so you can perhaps
imagine now that we've
only just begun to scratch the surface
of what you can do in JavaScript.
But almost any of
today's popular websites
with which you yourself interact
are being influenced and talked
to by this particular
language, JavaScript.
Well, what more now can
we do with JavaScript?
Well, we needn't just wait
for the user to type something
in and then submit
some form to our code.
We can instead actually change
the aesthetics of the website
too just by waiting, say,
for mouse clicks on buttons.
For instance, in this file
here, background.html,
let's go about giving ourselves one
or more buttons that if clicked,
change the colors of that page.
So I'm going to go ahead here and
use another tag still called button,
but proactively, I'm going
to go ahead and give it
a unique identifier of "red"
because my goal ultimately here
is going to be to create a
button that when clicked,
changes the whole background
from white to red.
So here, I'm going to go ahead and
call this button quite simply, r.
And I'm going to go ahead and
close that button tag next.
And now down below here am I going to
print my script tag, this time, not
in the head, but below, because
indeed, logically now, I
need this button to exist before
this code actually executes.
Before, when I created
that greet function,
it was only eventually called,
not right when the page loads.
So here now, I want this
script, though, to run
after the buttons have been rendered.
So what do I want to do within this
script or mini program written here
in JavaScript?
Well, I think I'd like
to express the following.
First, let's go ahead
and say to the document,
go ahead and select via that
same function query selector,
this particular button whose ID is red.
I can express the notion of
an ID, again with that hash,
and then the word of that ID--
red.
And when I select that button,
I want to go ahead and listen
for an on-click event,
not on Submit, per se,
but on-click, because this
time, I want to distinguish one
among multiple buttons.
And here, what do I want to do
when that button is clicked?
Well, I'd like to
execute a block of code.
Well, what is a block of code?
Well, that's really
just what a function is.
And in fact, functions don't
always have to have names.
Sometimes, you just want a function
to encapsulate one or more lines.
And in JavaScript, this is actually
quite straightforward, if cryptic
certainly, the first time around.
I can just say, hey,
JavaScript, give me a function
with no name, just parentheses,
implying that it also takes no input.
And then by convention, this time,
I'll put a curly brace on the same line
just because I want the
other curly brace down below.
And I'll finish my thought in
advance with that semicolon.
This is to say now that between
those two curly braces is a function,
if an anonymous function
with no name, that is just
to have one or more lines of code that
I'd like the browser to execute, if
and only if that red button is clicked.
Now what do I want to do
when that button is clicked?
I'd like to change the whole
background of the page, that
is the body from white, its
default, to, in this case, red.
So let's go ahead and ask the
browser again, hey, browser,
go into the document and select via
that function again, query selector, not
red, or any ID, but rather an actual
tag "body" with no hash, because body
is the name of that tag.
And I'd like to change the style of that
particular tag and everything therein,
and so it turns out that I can
get not its value, as before,
but instead its style, its actual CSS.
And within that style
property, so to speak,
is there something called background
color, capitalized this time exactly
like this in so-called camel case,
whereby it's a lower-case background
and then a capital c and
the rest of the word color.
This is distinct, and
unfortunately inconsistent
with what this would be called in CSS.
Were I writing CSS and not JavaScript,
I would actually say background-color,
all in lowercase, just as font size
and text align are all lowercase,
with that same dash.
But so be it.
These languages were
designed by different people
and so sometimes you simply
have these inconsistencies.
Now style.background color is indeed the
current color, which is to say, white.
So if I want to change
that color, I just
need to assign it a new
value from right to left.
And frankly, I'll just change it to
that "red"; followed by a semicolon,
thereby ending my thought.
And while each individual
keyword on the screen
here might in itself
look fairly cryptic.
Again, consider it top-down.
Hey, browser, give me a
button, the label of which
is just r and the unique ID underneath
the hood of which is just red.
Hey, browser, here comes a script,
a program written in JavaScript.
Hey, browser, from the documents
select the element who's unique
ID is red, and on clicking that button--
that is to say, to listen
for the following event
and then call this
function, that has no name,
but that's fine, in between
these two curly braces.
Document.querySelect
or("body").style.backgroundColor=red.
So if I now save this
file and open that page,
I should see a button
quite simply labeled r.
And if now I click this r, I should
see that my white background becomes,
indeed, red.
Now red is not all that
interesting, and this page
is far from all that
interactive, because now it's red
and it's permanently so.
I've not implemented any
notion of a toggle, which
I could perhaps with an, if else.
Now, it's just red.
But what if I wanted to allow at
least three colors r, g, and b,
for red, green, and blue.
Well with a bit of duplication or
better design, could I do this.
And let me actually pull
something out of the oven
that's already written here, which
is to say this version-- voila.
Now I have that same structure
red, green, and blue,
as well as a few blocks of code.
But because this is
getting fairly verbose,
I've actually factored out some
of my code to another variable,
document.querySelector("body") is what
I would need to use three times now,
one for each button.
But I've instead called
that just once, stored
the answer in body, the equivalent
of really going into that tree
and plucking out one of those nodes,
one of those rectangles from the DOM
and just calling it body so that
I have now immediate access.
And thereafter, I simply check for
red on click and green on click
and blue on click and on each line,
setting that background color.
And I could actually take this
further, because indeed, there's
clearly a structure here.
So while correct, this is not
necessarily well-designed.
Indeed, almost all of
my code is now the same.
All of that red, that green,
and that blue, and so there
is certainly an opportunity here to
factor more out and maybe use a loop.
Listen for red and then
for green and then for blue
and so do something again and
again, specifically three times.
But for now, we'll leave this
is as demonstrative really
of what you can do in the intersection
now with not just HTML and JavaScript,
but HTML and CSS and JavaScript,
because indeed, that's what's going on.
By way of this style property
inside of the body tag can
I change something
just as I can read it.
In the past, did I read the
value of what the human typed in.
But here I can check the style
of the body and even change it.
Allow me now to pull one
more cake out of the oven.
This one called size.html.
Here again, I have a paragraph
of Latin or Latin text, which
is fairly small by
default. But I've used
that familiar UI mechanism,
a dropdown or select menu
inside of which is multiple values.
By default, its value
is "initial" but here
we see that we can go large or
small, or even xx large or xx small.
In fact, we can interact
now with this web page using
HTML that's being listened to by
JavaScript, so that if I go ahead now
and select, say, xx large, a
well-defined type size in CSS,
I can go ahead and magically change
the entire text, suddenly be extra,
extra large.
Meanwhile, if I go to
that same drop-down menu
and choose instead xx small, it
instead goes in the other direction.
So how now might this be implemented?
Well, it's probably quite not
obvious exactly what code to write,
but the primitives are exactly the same.
There is some drop-down menu
implemented with some HTML
that we've not actually yet
seen, but there's so clearly
an action or event associated on
occasion with that HTML element.
It happens to be an
event called on change.
Whenever that dropdown menus value
changes, you, the programmer,
can do something.
And what can you do?
Well, technically, anything.
But in this case, I want
to change the font size.
And just as I can change the color
of a background of an HTML tag,
thereby affecting with
JavaScript its underlying CSS,
so will I bet can I
do the same here using
JavaScript to change the font size
property of one or more HTML elements.
And while again, the wiring of this
end code might not be so clear,
all of this interactions reduces to
these first principles-- what can
you do?
Well, HTML tags layout your data.
CSS styles the page.
And with JavaScript can you listen
for interactions from a user
and respond to those actions
or events with some change.
So indeed here, lets look underneath
the hood, so to speak, at this file
here, size.html.
I have my paragraph of text
up top here in my p tag
and below that a new
tag, so-called select.
This select tag is what gives you a
drop-down menu on most any website.
And you can see within that
are any number of options.
Those options happen to
have specific values.
And in between the open and close
tags, you have whatever the human sees.
So you can have just with, as with
links, dichotomy between the values
that are ultimately used and
what the human actually sees.
But in this case, surely,
I'd like to be consistent.
And so I've made them quite the same.
By default though, I
had initial selected
and that's because I indeed had this
attribute with no value "selected"
on only one and just
one of those elements.
Now if I go down below,
I'll see another script tag.
Again here, I've put it down below so
that everything has been read already
by the browser, top to bottom.
And here I have now our
old friend, query selector.
Hey, browser, go into the document
and select, via query selector,
the tag called, conveniently, select.
And on change, when its value
changes by way of some interaction,
go ahead and call the
following function.
As before, that function has no name.
It's just a block of code,
one line in this case.
And hey, browser, go into the document
and select the body, just as before.
Go into its style and change whatever
its font size is to this .value.
Now this place holder
called this is actually
a variable to which we
have implicit access.
Because this code is associated
with that select menu,
conveniently, in JavaScript
this means whatever
element is an actual play here.
Now notice that same
inconsistency again.
Font size has this
camel case, capital s.
There again, turns out that JavaScript
standardized on and only supports
this approach, because in JavaScript
it turns out if you had a hyphen,
it would be confused for subtraction,
which is not what we want.
So font size in JavaScript maps to
font-size, all lowercase in CSS.
And so the net effect here
is to say, hey, browser,
change the font size of
the body to this value,
which is whatever the user selected.
And now, one final flourish.
An example that uses
JavaScript to actually find
my or, perhaps, your location.
Indeed, it turns out now browsers today
and in turn computers and laptops,
can figure out where you
are with high probability.
This is all thanks to GPS in our
phones and all of these wireless
access points throughout our world.
But indeed this can be
useful if not a bit invasive.
But let's see through JavaScript
how with just a few lines of code,
you can achieve this yourself.
Here then, is a web
page geo location .html,
finding someone's location
geographically via code.
Here in my body, I have a script
tag that fairly arcanely says, hey,
browser, go into your
navigator, an historical term,
and geo location is a feature therein,
and get the user's current position.
That might actually take some
number of milliseconds or seconds.
And so, this says, hey, browser, please
call this function when you are done.
And what is that function?
Well, it's one that takes an
argument, the user's actual position.
And then as per these curly
braces, do the following thing.
Document.right, that is print to
the screen the position.coordinates
.latitude,position.c
oordinates.longitude.
In other words, if the browser is
successful in finding me in this world,
I will see quite simply on the
screen latitude, longitude.
Well, let's go ahead and
open this page in my browser
and thankfully, my browser
first asks, is this OK?
This page wants to know your location.
At which point, I can either block
that invasive request or allow it.
Now for pedagogical
purposes, we'll proceed
to allow and some
number of seconds later
after some deep thought
and triangulation,
there is where I apparently
am in this world--
42,comma-71 with quite a few
decimal points of precision.
Where in fact is that?
Well, let me go ahead and just copy
this now into the familiar Google Maps.
It turns out with Google Maps you can
search not only by address or city
or state, but also by GPS coordinates.
And indeed, if I paste
those in and hit Enter,
we'll zoom in on what appears
to be, yes, Harvard Law School.
And in fact, if we turn on now satellite
mode, we can see with some probability
exactly where we are.
And indeed, it would seem that I'm
standing on the steps of Lang Del hall,
the library here on Harvard
Law School's campus, which
isn't quite right but
those are the steps that I
happen to go in to get here.
And so your location is only precise
within some radius of some sort.
Why?
Well, at some point,
I entered a building
where, thankfully,
Google doesn't have eyes.
And so only with some
probability can Google
or any service identify
your precise location.
But surely, in time, will
this only get better.
And so, imagine now if you just
pull up Google Maps regularly,
you might have said allow quite
some time ago or perhaps block,
but this is how Google Maps knows
when you pull it out of your pocket
or open your laptop, where, with
some probability, you actually are.
In the end of the day, anyone
can ask that same question
where is this user in the world?
And our only defense
right now is that block.
And if you're in the habit
all too often, as frankly,
am I, of just saying
allow or allow, well
you're giving up quite
a bit of information.
Because what the program or
website does with that information
now is entirely up to it.
It might you be used for
good and to show me on a map
or it could be logged server side.
Once you have the ability to program,
can you do anything with this data.
That then, is web development, or really
only scratching the surface thereof.
With HTML have we the ability
now to structure web pages
and all of the contents therein.
With CSS do we have the ability
to refine the presentation thereof
and the size and the color and more.
And with JavaScript, do we
have the ability, ultimately,
to interact with the user and then
do something with that user's input--
pass it off to a server
or keep it locally,
and even change the DOM or
the underlying code that
composes that web page on the fly, as
we get more and more input and more
and more data.
Of course, all of this now is happening,
so to speak, client-side within the Mac
or PC, in the specific browser.
If we now go back to the
server instead, do we
have even more expressive
capabilities, because on servers
can we use a Python or
Ruby or PHP or Java,
and can we store any volume of
data in so-called databases.
And so whereas, web development
here has been client-side,
the whole ecosystem of web development
and more generally web programming,
has yet more pieces that we can assemble
as part of this whole technology stack.
