CS50 for Lawyers 2019 - Web Development - VoiceTube: Learn English through videos!

Subtitles section Play video

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