Lecture0 720p en
Lecture0 720p en
DAVID MALAN: Welcome everyone to web programming with Python and JavaScript.
My name is David Malan.
BRIAN YU: I'm Brian.
DAVID MALAN: And today we're going to give you a quick overview of the course
and then dive right into the course's material.
So this is meant to be a class taken after a course like CS50, which
is the colleges and the extension schools
introduction to computer science.
But even if you haven't taken that class anything approximating
that is certainly fine.
We assume only prior programming experience in some language.
And what we'll then do is assuming you know
some of the basic constructs of most any procedural or imperative language,
we'll fill in the blanks along the way both with Python and with JavaScript.
Neither is actually assumed.
And what we'll do over the course of the next several weeks
is first dive into Git.
So you might know Git if you've used it before as a version control
software, whereby you can maintain multiple versions of your software.
But these days it's actually used for much more than that.
People will use it not only for versioning their code
and for collaborating with others, but also
for deploying their code from their local machines
to some staging server to some testing server and ultimately to production.
So it's actually become quite an integral tool
when it comes to actually deploying your code to the cloud,
so to speak these days.
Thereafter, we'll transition to HTML and CSS, with which you might already
be familiar, but we're focused on some of the more modern perhaps
some of the more advanced features of both of these languages
HTML5, specifically the latest incarnation of that,
as well as CSS and various selectors that you may or may not
have used before.
But also toolchain, something called SAS that allows you to programmatically
generate and maintain more readily, more complicated style sheets
especially as your web apps become themselves more complicated.
We'll then introduce Flask, which is going
to be a very popular framework for making web
based applications using Python.
And it's generally considered a micro framework,
which means there's not all that much complexity to it.
It doesn't try to do too much.
It really just tries to solve some very common problems so that most
of your effort when writing a web app with it
isn't focused on how do I learn Flask and how do I
build with this architecture, but rather how
do you implement your ideas without reinventing the wheel?
And so you'll get that out of a micro framework like this.
We'll then introduce a bit of SQL, or structured query language
with which you can query databases and store your actual data.
And we'll look at perhaps more complex queries
than you've seen or used in the past.
We'll talk about the idea of API, or application programming interfaces.
These can be both your own that you build for your own applications to use,
or as you may have used them already third party APIs.
Data feeds and functional behavior that you can actually access over the web
or from some other server that some other company or person has actually
made available to you to make your applications all the more
interactive or featureful.
And then we'll introduce JavaScript, which you might have used or tinkered
with before.
We'll introduce the very latest something known as ES6
or ECMAScript 6, which adds a number of features many of which,
or most of which are supported by today's browsers.
But we'll also talk about some of the pitfalls
when you try to use some of the latest and greatest features
and what it might mean to ensure as through transpiling or other techniques
that your code will indeed work on any number of mobile devices and desktops
and laptops these days.
And we'll also talk about front ends, the idea of actually building
a front end user interface using JavaScript talking about techniques
like Ajax or SPAs single page applications these days,
particularly modern paradigms with which folks are implementing today's web
applications.
Also looking at things like graphics and animation as it
can be implemented in JavaScript and inside of a browser.
And then we'll look at a heavier weight framework
something known as Django, which is similar in spirit at least at first
to something like Flask.
Just makes it easier to get going building web applications,
but comes with so many more features.
The proverbial kitchen sink.
So when you get a little tired in life of implementing
an administrative interface to your web application, or a log in interface
for your application, or any number of things that a lot of us
probably use in various tools.
You can start to lean on these larger scale frameworks that
just come with many more features.
And as such, you might have to comfort of it more to its conventions,
but you'll end up writing a lot less code than you would otherwise.
So we'll sort of graduate to that level of framework.
And then we'll talk about a world that's generally
known these days as DevOps, development and operations kind of united in one,
in the context of testing like making sure your code actually works
and how you can think about that and how you can actually do that when
writing your code.
And then CICD continuous integration and continuous development,
which is just a fancy way of saying setting yourself up
for success with the right tools and with the right scripts,
the right environments so that when you run a command on your laptop or desktop
the code actually goes somewhere and it goes not only into a code
repository to be saved and versioned and shared with other people,
but you can test it automatically and continuously so to speak.
And you can even deploy it to the cloud simply by having set up
some of those steps in advance.
So if you're already in the habit now of deploying your applications by kind
of dragging and dropping them to an FTP server or using some web interface
or copying things, all of this now can be automated in very robust ways
especially that are conducive to collaboration with others.
And then toward the end of the term we'll
talk about some higher level issues that will
inform how you go about building web applications
after the scope of the class.
Scalability.
So topics like DNS and load balancing and how
you think about anticipating that 101st user that
might not fit on just one server.
And so if you now have to have your app on two
or three or more different servers, how do you
have these servers talking to one another
and how do you share data among them?
What's going to get easy?
What's going to get hard as you scale to more and more users?
And then throughout the semester, we'll talk about topics of security.
What you want to do in terms of best practices
to avoid getting exploited in some way, but we'll also
culminate that discussion in a focus on security at the end
so that when you go out into the real world
or back into the real world after the courses lessons,
you actually are mindful of especially in the languages and tools
that we'll use throughout the semester of what
you should be particularly mindful of.
And then as punctuating the whole semester will be a number of projects.
So four assigned projects where we prescribe the specifications of some
app that we'd like you to build with the whole course's staff and support
structure.
And then one final project that will culminate this semester, whereby you'll
be invited to design and implement your own tool that's
a genuine personal or professional interest
to you that somehow draws upon the course's lessons.
And let me pause there and see before we forge ahead if there are any questions.
Anything else?
Yeah.
AUDIENCE: So HTML, CSS, JavaScript-- suppose
I don't have any experience on those things?
DAVID MALAN: Good question.
And so what then?
So if you don't have any experience in some of the alphabet soup
that we put up already like HTML and CSS,
JavaScript and/or Python, for the most part that's OK.
I would say that they'll be a bit of a more of a learning curve
early on for you.
But we will take care to provide students like you
with any number of resources supplementary
so you know where to fill in any gaps.
And we'll also introduce these topics in the class itself.
So all of the topics that we just gave an overview of we'll
introduce and dive into in the class.
It will certainly be advantageous if you've seen them before,
but each of the projects and by way of the courses sections and lectures
where you have all the material you need to succeed,
even if most of these topics are brand new.
So not to worry.
Other questions?
Yeah.
AUDIENCE: [INAUDIBLE] purchase any of the software [INAUDIBLE]??
DAVID MALAN: No need to purchase any software whatsoever.
All of the tools that we'll use, all of the libraries,
frameworks, APIs are freely available now and after the class as well.
Other questions?
No.
All right.
So first on the agenda today is version control
and Gits in particular, a tool that you'll
use not only to version your code and share your code,
but also ultimately deploy it.
So without further ado allow me to turn things over to Brian.
BRIAN YU: Thank you very much.
All right.
So the first topic that we're going to be talking about today as we approach
the world of web programming and web development
is thinking about when we're designing projects,
how do we keep track of different versions of our code?
How do we collaborate with other people?
How do we make sure that if we make a change and that change
doesn't work that we have an easy way to go back to older versions of our code
and make sure that we have access to those as well?
And so all of that falls under the larger umbrella
of what's called version control.
And out there, there are some number of different version control software
that people are using on a day to day basis, but one of the most popular
is a piece of software called Git, which is a version control
tool that we're going to be using in this class
and that people often use in industry in order to help maintain and manage
different versions of their code in order to keep track of their projects
and make sure that everything is organized
and that they're able to effectively collaborate
with other people along the way.
So we'll take a moment to step back and talk about the different things
that Git does for you at a high level.
And then we'll dive in and look at the actual commands
that you would use in order to run Git, understand how it works
and actually make use of it.
So the first thing that Git's good at doing
is keeping track of different changes to your code
so that if you're making changes, you don't only
have access to the latest version of your code,
but if you start out with a particular file
and then you make changes and add another line to it,
you remove a line to it later you can keep
track of all of those different versions of those files
such that you know the history of your project
and how it's developed from the beginning
all the way up until where you are now.
So that's one thing Git's particularly good at.
One other thing the version control is very useful for
is synchronizing code between different people.
Very often in the modern world you're not
the only person working alone on your projects independently, but rather you
and one or more other people are working together
collaboratively trying to work on a project together and making sure
that you and the people you're working with stay in sync in terms of your code
is often a challenging task.
And what Git, another version control softwares
like it do is help to make that process a little bit easier.
So you can imagine that maybe we're storing a version of your code
up in some remote server somewhere.
And Git what will allow you to do is make sure
that you and someone you're working with both have access to that same code.
And when you both make independent different changes to that code
there's an easy way via which Git can merge those changes back
together so that there's a central version that
has all of the changes to which both of you will then have access to.
So synchronizing code between different people
and making sure that everyone has access to that code base
is something that is also useful with regards to version control.
In addition, Git is also very good at letting you test your code
without losing your original copy.
So if you have a working program or a working web application
and you want to make some modifications to it in order to add a new feature
but you're worried that adding that new feature
might break some prior feature that's already existing within your web
application, Git's very good at letting you test your new changes
and experiment with your code without losing track of that original.
And only once you're happy with the original code
that you have can you then merge your new changes in with the existing
changes so that you never lose a working copy of your web application
And finally, one last thing to Git is very
good at is reverting back to old versions of your code.
So you've been working on your project, you've
made some number of modifications or edits,
and you realize that your most recent version of your program doesn't work,
you want to go back to some previous version of your code.
Git is also very good at allowing you to revert back
to old versions of your code.
And we'll see examples of all of that in just a moment.
So that's sort of the high level overview of what Git is
and how it works.
And in this course we'll also be using another service known as GitHub.
And GitHub is just a website whose purpose in life
is to store Git repositories on the internet.
It's to give you and people all around the world access
to Git repositories on the internet, such
that you can look at repositories that other people have created
and contribute to them or use them, and such
that you can work on your own projects, push them to GitHub so
that your collaborators or other people on the internet can also see and use
and work on those projects as well.
And so one of the first things you'll do in this course is go to GitHub.
And if you don't already have an account already you'll
create a free GitHub account.
And once you do, I'll show you what GitHub's interface looks like.
We'll just go to get github.com.
And so this is what github.com might look like once you log in.
And what we'll do right here is we're going
to first create a GitHub repository.
And repository is just a fancy word for the place
where we are going to keep track of all of your code and all of the changes
to your code.
Think of it as like a central storage place where
we're going to store your project.
So in the upper right of GitHub's screen we have the plus button
and we can go to the new repository.
And this takes us to the page where we can create a brand new repository.
In this case, I'm going to name the repository Lecture Zero.
And I'll go ahead and just click Create Repository.
And that creates a new repository for me that stored on GitHub.
Right now it's not on my computer yet, but we'll see in a moment
how we can take this repository which is right now empty but on the internet
and download a copy of it to our own computer.
And so that's where we start to introduce some of the command line
interface of Git and the commands that you might run in order to use it.
So after you've installed Git, one of the first commands you'll want to learn
is git clone.
And the git clone command has just one purpose.
What it does is it takes a repository stored somewhere
else like on some server like GitHub.
And what happens is that when you run git clone followed
by the URL of that GitHub repository, that remote version of your code
will be downloaded onto your computer so that you
have a copy of the repository on your own computer.
So I'll show you what that looks like now.
We'll head back over to the GitHub repository
that we just created over here.
And what you'll notice is that GitHub provides me with this URL.
This is the URL of this GitHub repository.
So if I go ahead and copy that to my clipboard
and open up a terminal window, for example, what I can do
is type git clone followed by that URL, just pasting it right in there.
When I press Return it already exists because I already created it.
So I'll go ahead and remove the old version of that.
Sorry about that.
And we'll do git clone pasting in that repository.
And it's giving me a warning.
Warning you appear to have cloned an empty repository, which
is to be expected because the repository that I just created was in fact empty.
And I can CD, CD for change directory, if you're
unfamiliar with the command line interface
into that Lecture Zero directory.
And now I'm inside of that Lecture Zero directory.
Which if I take LS for list or list all files
in that directory nothing shows up.
So this directory is currently empty.
So let's go ahead and fix that.
Let's add some code to this repository.
I can use the touch command where touch is just
a command that if you're unfamiliar with it can help to create a brand new file.
And I'll create a new file called hello.html.
And I'll open up that file using a text editor.
In this class you can use whatever text editor you wish.
But common ones include Adam which I'm using here,
but also Sublime and VS Code and many others.
And I'll just go ahead and create here a simple HTML web page.
No worries if you haven't seen HTML before
and this looks unfamiliar to you.
Later on during tonight's lecture we'll dive
in more depth into what all this code means if you haven't seen HTML
before to understand what's actually happening when I create this web page.
But in essence, what I'm going to do is create
a website whose title is my web page and whose contents just say hello, world.
All right.
So there I have it, a simple HTML web page.
Again, not to worry if you haven't seen this type of thing before.
But now I want to take that code and save it.
I want to make a what's called a commit to my repository
to say these are changes that I want to save because one day I might want
to refer back to them, for instance.
And so the next thing we'll need to know is git add.
And the git add command basically means we're
going to take some number of files, one or more files that we've changed
and tell Git that these are files that we want to include the next time we
make a commit, to the next time that we save
a version or a snapshot of the current repository.
So for instance, if I say git add followed
by some file name, what that's going to do is tell Git to track that file.
That this file is a file that I want to track the next time
that I save a copy of the repository.
So what does that actually look like?
If I do ls right now, again, list all the files in the current directory,
you'll see that I have hello.html, that file that I just created.
And what I'll do now is I'll say git add hello.html.
To mean, I want to take hello.html, and I
want to include that the next time I save a version of this repository.
Nothing appears to have happened, but that's
OK I have now added hello.html as a file that I want
to track the next time I make a save.
So what does that process look like?
That comes in the form of a command called git commit.
Commit it just fancy way of saying take a snapshot of the repository
in the current moment and save it.
And so how that would work is I would say git commit followed by a flag dash
m, m for message, and then in quotation marks
some English message describing what it is that I've changed in this commit,
describing what it is that's happened in this change that
makes it different from previous versions of the code.
This is useful because as you begin working
on a project that has dozens or hundreds or even thousands of commits,
later on you can refer back to this list of messages
that you yourself have written describing what happened
in any successive change, so that you know where to look if you're trying
to find a particular commit, or a particular change that you made
to your code at any particular time.
So when you run git commit dash m followed by a short description of what
you've done, what that'll do is have Git save a new version or a new snapshot
of your repository in that moment keeping track
of all of your old versions as well.
So that's git commit.
And we'll take a look at that now.
I'll do git commit dash m for message.
And the message that I want to include in this case is just added hello.html.
That's what I did.
I'll press Return.
And what you'll notice is that Git provides me some helpful information
about what it is that I just did.
It said one file changed at nine insertions because I added a new file
and that file had nine lines in it.
And so now Git has kept track of the fact that in this commit,
in this save I have added this hello.html file that
has the contents that you just saw a moment ago.
So that's me making a save to the contents of that file.
Next command that's often helpful to know and to be familiar with
is git status.
Git status is a simple command that effectively just tells you what's
currently going on in your repository.
If you forget whether you've made new commits since the last time you checked
from GitHub, if you forget whether you've made new changes that you
haven't committed yet, git status is an easy way to just run git status
and see the current status of what's going on inside of your repository.
So let's take a look at the code that we've been working on.
We'll go ahead and run git status on it.
And what we see is on branch master--
don't worry about branches too much.
We'll dive into more depth about that next week.
But importantly, we'll see that we are based on origin master
and right now it says we have nothing to commit.
So git status effectively tells us the current status of the repository,
tells us what's going on with our repository at any given moment.
So next up we've made these changes to our repository.
The next question is, now how do we send those changes back to GitHub?
GitHub's keeping track of our repository on the internet
and we've made changes to the repository adding hello.html on our computer
locally, but that isn't yet reflected on GitHub.
If we were to check the GitHub page for this repository
it would still currently be empty.
So how do we then send those changes to GitHub?
That's called a push, where we push our code from our local computer
to the repository that's stored somewhere on the internet.
And so when we run git push, that causes those changes,
whatever changes that we've made to our code locally
to be pushed to the remote server so that GitHub is now able to keep
track of those changes that we've made.
So that is git push.
And I'll go ahead and try and show you that now.
If I try and run git push it pushes those changes to the GitHub repository.
And now if I go back to here, this GitHub page for student50/lecturezero,
which is the repository page on GitHub, and refresh that page
you'll notice that now there's contents here.
Now I have an hello.html file that's located inside this repository.
And if I click on it then you can see the contents of that hello.html file
that is now stored on GitHub as well.
So I've now taken my changes that were just on my computer before
and I'll push them so that they are on the internet as well for people to see.
So that's git push.
Next up is sort of the inverse of that.
Git pull.
What if someone else has been working on your repository,
has made changes to it, and pushed those to GitHub?
And now you want to download the latest version of that repository.
You want to download the latest changes down onto your computer locally
to take a look at it.
How would you go about doing that?
That's by a different command called git pull.
When you run git pull, if there are other changes that
have happened on the remote server, notice that here locally I've
made one change, but someone else on GitHub for instance
has pushed some second change that's been made to the code.
If I run git pull, that causes any of the latest changes that
have been made on the remote server to be downloaded onto my own computer
so that I now have a working copy of the entire history of what's
been going on with my project so far.
So that's git pull.
And we'll show you a quick example of that now.
If I go back into the GitHub interface there is sort of two ways
to make changes to the code that you see here on GitHub.
Either I can change that code on my own and my code on my computer,
or actually GitHub's web interface actually has a button here
that lets me edit this code.
So let's say I wanted to add another line that
says hello, again, for instance, that I wanted to add to this file,
I can scroll down and go ahead and commit those changes.
Again, commit is just a fancy way of saying save or take a snapshot.
And when I commit those changes what I see
is that the contents of my web page on GitHub show hello, world
and also hello again.
But if I were to check my computer I just have hello, world.
Just the one sentence.
That change has been made on GitHub.
It hasn't yet been reflected in my version of the code that's
stored on my computer.
So what can I do now?
I can run git pull to say pull down any of those latest changes from GitHub.
I press Return.
And notice that it says hello.html.
Two changes, one plus and one minus.
One insertion, one deletion.
Git's not quite smart enough to know that I actually took a line
and changed it.
As far as Git is concerned I removed that old line
that just said hello, world, and added a new line that
said hello, world, and hello again.
So if I check my code now going back here, I see that it's now updated.
My local version on my computer now says hello, world, and hello again
because that was the change that I had just pulled down from GitHub.
And so via pushing and pulling code can you and other people
that you're working with collaborate together on a repository
and make sure that you're keeping track of any changes that you make.
But what can go wrong here?
What might happen and cause things to not seem as simple as they are?
Well, what if I decided to make a change here?
Hello a third time.
So I make that change and I decide to OK, git add hello.html.
I want to track that.
And git commit, add a third line.
So now I've added that third line to the contents of my hello.html file.
But what if someone else on the internet who has access to my GitHub repository
decides to edit it differently and decides to say hello, hello, hello,
and save those changes by committing them?
Now the online version says hello, world, hello again, hello, hello,
hello, but in my local version of the code
it says hello, world, hello again, hello a third time.
And if I try now to pull this code from GitHub
it's not going to be as simple as it was last time of just updating the changes
because Git doesn't quite know which change I actually want.
Here I've added a sentence online that's a different sentence.
So we're going to need some way to reconcile those two things.
And so that's where we introduce the concept of merge conflicts.
Git will try whenever it can to automatically take
any changes that have been made and combine them together automatically
for you without you needing to worry about what's going on.
But in some cases, if you and another person
have both made changes to the same lines of the same files
you may run into a merge conflict, which is what
happens when you try and run git pull.
But what happens is that there's some sort of conflict.
The pull can't happen.
And so what you'll see is a message that says automatic merge failed.
You need to fix the conflicts and then commit the results.
So what does that look like?
Well, what will happen is that if you open up the file with the conflict
you'll see something that looks a little bit like this.
You'll see a file with a bunch of less than signs
and then HEAD, some lines and then equals, equals, equals,
some more lines and then this sort of random long sequence of numbers
and letters.
It might seem a little bit arcane at the moment,
but we'll break down what this actually means.
So when you look at a file like this, which
results whenever there is a merge conflict produced by Git,
there are a couple of things to keep in mind.
One is that anything between HEAD and all the equal signs are your changes.
The things that you did on your computer before you tried to do the pull.
Anything between these equal signs and the greater
than signs here, these are the remote changes.
The changes from GitHub that you were trying to pull down that
were somehow in conflict.
That these two lines couldn't automatically be merged together.
And this long sequence of numbers and letters is the conflicting commit.
Whenever you make a commit in Git, Git represents that using a long hash.
Just a long sequence of numbers and letters
so that you can uniquely identify one commit out
of a series in a history of commits.
And this long sequence of numbers and letters
is just the name of that conflicting commit.
It is that commit hash of the one that caused the conflict.
So what do you do in a situation like this?
All you need to do is remove all of the lines you don't want.
Remove all of those less than, equal than, greater than lines
and also remove whichever part of the code
you didn't want leaving only the version that you want to be merged together,
and then get rid of any that extra white space
and then you can commit the result.
So I'll show you what that looks like if we go back over to the computer here.
Recall again, that locally we had three different sentences.
And online we had three different sentences,
but the third sentence differed.
So now if I try and run a git pull what you'll notice
is that we see exactly this.
We tried to automerge hello.html, but there was a conflict.
There was a merge conflict in hello.html.
The automatic merge failed.
We need to fix the conflicts and then commit the results.
So if I take a look at hello.html, my text editor Adam
is automatically highlighting things in certain colors for me.
But what you'll notice is you see this less than, less than head,
and then this version, which was my version, hello a third time.
And then this version down here, which is the version from online.
Git doesn't know which one I want, so I need to pick.
And I'll just say you know what?
Let's use the version that I had.
So I'll go ahead and get rid of all of these extra lines
so that I'm left with just the version that I
want, the one that says hello, world, hello again, hello a third time.
And if I then commit those changes, now Git
knows because I have told it this is how I
want you to resolve the merge conflict.
Now Git is aware of how to go about merging the two different versions
of that repository together in order to come up
with one version that is going to work for everyone.
So that's the process of resolving merge conflicts.
It can seem a bit complicated at first, but as you start to deal with them
you'll start to get a sense for where the different changes are
and how to go about resolving them.
And it's something you may run into as you go about the process of working
on your project.
A couple other useful commands that are useful to know.
One is git log.
What git log does is effectively just show you a history
of all of the commits that you've made.
If you run git log while you're inside of a Git repository,
you'll see a list of all the different commits that have been made.
Notice again that you'll see each commit is marked by a unique commit hash.
Just a sequence of numbers and letters describing that commit.
You'll see who made the commit, when that commit was made,
and also a description based on that message
that you provide whenever you make a commit of what it is that happened
in that commit so that you can see the history of what's
been going on in your repository.
So that's git log.
And then one other command that's useful to know is git reset.
So we talked about before if you've made some changes,
realize that you messed up and you want to go back
to the way things were before, you can run one of these commands
if you do git reset --hard, followed by a commit hash like the numbers
and letters that we saw before.
That will reset your whole repository back
to that version, whichever version was marked by that commit hash.
And likewise, if you run something like git rest --hard origin/master,
origin/master is a fancy way of saying the version of the repository that
was the origin of this repository where I got it from.
In other words, if I cloned my repository from GitHub then running git
reset origin master is going to reset the contents to my repository
back to the version that was previously on GitHub so that then I am
able to see whatever it was originally.
So in this case, if I run git reset --hard
followed by the commit hash of some previous version of the code,
what that's going to do is reset that code back to that older version,
and now my repository is back to a previous version
such that I can correct my mistakes and then continue working appropriately.
And so we'll show a quick example of that.
So first of all, commit my changes.
So just now I fixed the merge conflict and run a quick git status.
Oh.
I need to add the files before I commit them.
So that's a good lesson to be learned.
The way Git effectively works is that we first
need to add the files to what's called a staging area or an index.
Just telling it these are files that I want to track in the next time
that I make a commit and then you commit after that.
So if I git add hello.html and then git commit, fix the merge conflicts,
that will resolve the issue.
And if you're looking to simplify these two commands into one
simpler command know that you can also do a command like git commit -am,
where the a stands for add to both add files to the staging area
and commit them all together in one command.
So go ahead and press Return there.
And now if I run a command like git log, what you'll see
is a history of all the different commits that I've made now.
Here was me fixing the merge commits, here was when I updated HTML online,
here was when I added a third line to the repository.
So I see the history of all of the different
commits that I've made to this repository.
And let's say I wanted to reset back to an older one of these.
I wanted to reset back to this original one where I first added hello.HTML.
I can take this commit hash, the commit hash
of when I first made that change, or even just
the first couple characters of the commit hash
is usually sufficient to be able to identify it.
And I can run a command like git reset --hard followed
by that commit hash by pasting it in there.
And now I've reset the head, reset where I am in this repository
back to that older version.
And now if I check the contents of hello.html, it just says hello, world.
Back to that very first version of the HTML
file that I created way back when I first created the repository.
Yes, so Git keeps track of all the different snapshots.
In fact, if you run a command like git rest log,
just a log of all of the different references
that Git has kept track of you can see all the different changes
that are still there.
So they're accessible, but they're just not present
in the current version of the repository as you see it just there.
Yeah.
A question over there.
AUDIENCE: Once you run the [INAUDIBLE] what version of the file [INAUDIBLE]??
BRIAN YU: GitHub was untouched.
So the question was, what happens to the remote repository,
the repository on GitHub when I reset something locally?
And the answer is that any changes I make to my computer,
to my version of the repository on my computer
never affect what's going on online unless I try to push
those changes to GitHub for instance.
So if I really screw things up, mess things up on my computer completely
GitHub's version is still going to be the way it was before.
And if I really wanted to I could just download a new copy
by cloning the old version from GitHub.
If I check now, even though I reset my version on my computer
it still has hello, world, hello, again, hello, hello, hello,
because I have never pushed any new changes to GitHub after that
to tell it to make any additional changes after this point
that it knows about.
So GitHub doesn't know about any of those additional changes just yet.
Question back there.
AUDIENCE: Yeah.
So does Windows or a Mac OS [INAUDIBLE] built into it so [INAUDIBLE]??
BRIAN YU: Great question.
The question is, is Git built into Windows and Mac OS,
or is there something special you have to do?
In many cases, you will need to install Git.
When we release project zero you'll find that in the project zero instructions,
there are instructions for how to get set up with a GitHub account
and how to install Git onto your computer
and configure it correctly so that it can talk to GitHub.
But yes, typically you'll need to install it.
It's free software that you can install on your machine
and it will prove helpful as you go about starting
to work on version control.
Yeah.
AUDIENCE: Do merge conflicts only happen if you
were trying to pull from the repository and it's different,
or is there any situation where I'd be pushing changes and not
running to a merge conflict?
I don't know if that makes sense.
BRIAN YU: Great question.
So the question is, is pulling the only time that you
might run into merge conflicts?
And the answer is no.
It's the only one we've seen so far.
But any time you are trying to take two different versions of the code
and combine them, there is a possibility that you'll run into a merge conflict.
And so later on in this course, we'll take a look
at additional features of Git like branching,
where you can keep track of multiple different versions of your repository
at once so that you have your current version of your repository,
but you also have a different branch on which you're
working on some new feature and maybe a different branch
where you're working on some other feature.
And any time you want to merge two branches together to say,
OK, this feature is done.
I want to bring it back into the master branch or the official version
of the code, so to speak.
Then there's possibilities for merge conflicts there.
So pulling is one instance in which conflicts can happen,
but certainly not the only instance in which those conflicts can happen.
Yeah.
One more question.
AUDIENCE: Let's say I entered in multiple files [INAUDIBLE]
should I run Git [INAUDIBLE]?
All right.
Welcome back.
So now that we've taken a look at version control
and how we might go about versioning our project
and keeping track of different versions of our project as we go along,
we'll dive right now into the actual web programming
aspect of the course starting by just taking a look at HTML, or HyperText
Markup Language.
This is a language via which we're going to be laying out the structure of a web
page such that when a user opens up in their web browser,
their web browser, whether it's Safari or Chrome or Firefox or some other
knows how to understand and interpret that HTML and display it as a web page
to the user.
So we'll take a look at a simple example.
In fact, we'll just take a look at hello.html.
Very similar to what we've just been working on with that Git repository.
And we'll now break this down and sort of get
a feel for what's going on in terms of what we see here
and how this is going to translate when a web browser reads code like this
and tries to interpret it as a web page.
So up here on line one, we see this sort of funky angled bracket !DOCTYPE HTML.
This first line just goes mean something along the lines of HTML
has come in a number of different versions.
It's had a bunch of different standards where people specify,
here's what's included in this version of HTML and this new version of HTML.
And the latest version of HTML is called HTML5.
And the way that a web browser knows when
it gets a web page, which version of HTML it's using
is by taking a look at that first line.
So that first line saying doctype HTML is
our way of telling the web browser that this web page is written using HTML5.
So now let's take a look at the rest of this web page.
And what you'll notice throughout this web page
are a whole bunch of what are called HTML tags.
Those are these keywords that begin with an angled bracket
and end with an angled bracket.
Right here we see the HTML tag.
And all that tag means is that angled bracket HTML ending angle bracket
means this is the start of the HTML content of the website.
And this will go all the way until here on line nine where we see a tag that is
angled bracket /HTML, where that slash just means this is the end of the tag.
So what line two and line nine sort of tell
us here is that this is the start of the HTML content of our web page and line
nine here is the end of the HTML content of our website.
And everything in between is the actual contents of that website.
And if you take a look we've divided that content to the website
into two parts.
Up here on line three we've started the head of the website.
Angled bracket head angled bracket.
That's the start of the head tag.
The head of the website is usually used for a metadata, information
about the page that doesn't really appear
in the main contents of the page, but is used
to give the browser important information about how
to go about displaying that page or other important information about it.
In this case, you see we have a title tag here
where the title in between the start of the title tag
and the end of the title tag we've included text, my web page.
And so as you might guess what this line four is saying,
is we're going to have a web page whose title is just my web page!
And that's going to be the title of the web page.
And that's information that's all included
in the header of our HTML page.
In addition to that, on line six here we see the beginning of the body tag
and the end body tag is on line eight.
And in the body of the website very simply we just say, hello, world.
And that's it.
So what we've described here in nine lines
is an HTML5 website that's got two parts.
It's got a header whose title is my web page.
That's going to be the title of the page.
And we have a body that just says hello, world.
And so now if we actually were to open up a web page like this by saying,
open hello.html, or just opening it in a web browser like Chrome,
you'll see that what we get is a web page that just says hello, world.
And if you notice up there at the top it says that the title of the page
is my web page.
So as you might guess, Chrome is reading that HTML code that we just wrote.
And it's interpreting it trying to figure out what means what.
And it knows where to put different tags,
it knows that the title tag is going to go up here in the title part of my web
page, and it knows that whatever is in the body is
going to go in the main area, the main body of my web page in general.
So if I changed the title to something else
or change the body to something else, it would have reflected here.
Of course, this is a very simple website, but it shows you the basics.
How we use HTML tags to define the structure of our page,
and then using those tags we can create pages
that are rendered nicely when a web browser sees that HTML
and tries to do something with it.
Questions about that so far?
Yeah.
AUDIENCE: Is the indentation style or functional?
BRIAN YU: Great question.
So the question is, is the indentation that we saw in that code earlier style,
or is it functional?
The answer is that it's just style.
Ultimately Chrome and other web browsers don't really
care about whether your head tags are indented
and your title tags are indented further than that.
But it can often be easy when another human is reading your code,
or even when you're reading your own code to be able to say,
OK, here's the head tag and just look straight down here
is the end of that head tag.
And so very frequently you'll see a paradigm
like that will indent anything inside of the header,
but the header itself will be aligned nicely.
And oftentimes, you'll see things that when a tag only contains one line
within it, we'll just put the whole thing on the same line where we have
title, my web page, and then /title.
But we could have just as easily if we had one or two indented the my web page
and put the /title on its own line as well.
And that would render identically.
If we go back into Chrome, refresh that page, no changes.
Chrome doesn't care about that difference in indentation.
Great question.
Other questions about this first HTML web page that we've created?
All right.
So that was sort of the introduction to just a basic HTML page,
but there's a lot more that we can do with HTML
by taking advantage of other tags.
So far we've seen the HTML team tag and the head tag and the body tag.
And right now all that's able to do for us is render some text.
And we can type more text and it would appear there as well.
But let's take a look at how we might render headings for text
because if we have text, maybe we want a heading to go at the top of our page
and maybe subheadings to go beneath it.
And so we'll open up headings.html And what headings.html is going to do
is show you a couple of other tags.
So HTML has many, many built in tags, more
than we're going to talk about today, but we'll just
introduce some of the common ones so you can get a sense for how these tags work
and the general feel of them.
And these are ones that will come up quite frequently as you go
about writing web programs using HTML.
And what you see here is in H1 tag located inside the body, where H just
stands for heading, like a big headline at the top of the page,
and one is a number that stands for its size.
So HTML has six built in heading tags inside that understand.
h1 is the largest, h6 is the smallest, and two, three, four, and five,
as you might guess fall somewhere in between.
So this is the largest headline.
Starts at h1, ends with the /h1.
Notice this continual pattern of angled bracket name of the tag, like h1,
and then the /h1 to mean this is the end of the tag.
This is the end of that head end.
So if we open up this page now by going to not hello.html, but headings.html,
what we'll see is this is what gets rendered.
We have this is the largest headline.
Again, this was our h1, this was our h2, all the way down
to h6 at the bottom which is a relatively small headline.
And one feature of Chrome and most web browsers
nowadays is that if I actually want to take a look at any web page
and see what HTML actually made it up, I can Control click on the page
and go to View Page Source for instance.
And when I go to View Page Source, what I get
is Chrome showing me the actual contents of the page that it had just rendered.
And this can often be helpful once you start
working on larger web applications trying to understand
what's actually getting rendered.
In this case, what we see here is exactly
the same thing as what we loaded before because Chrome is just
showing us the HTML contents of the page that it then
renders to look something like this.
So it's the browser that takes the HTML, understands the tags and what they do,
and renders it to look a little bit nicer like that.
So what are some other common HTML tags that we might want?
So now we have the ability to include text in our web pages,
we have the ability to include headings.
One other thing that we might naturally want to do
is maybe create a list of different items
where frequently we'll want to have a bulleted list on our web page
or a numbered list on our web page or some other type of list.
And so we'll take a look at possible ways we can do that.
And we'll see here in lists.html that I have two different examples of lists
for you or take a look at.
So the start of our web page is the same.
We have doctype.html.
This is the start of the HTML content of our page,
this is the start of the HTML header.
Here's our title.
Then in our body is where things get interesting.
So here where I said an unordered list, I
have this tag ul, where ul as you might guess stands for unordered list.
And the ul element goes from here all the way down to line 12 over here.
And inside of it I have three li's, where li stands for list item.
This is an item inside of this unordered list.
Here's one item, another item, and yet another item.
And so these are three list items that are inside of the unordered list.
And as you'll start to notice the HTML tags very frequently
nest within each other.
We have an li which is inside of a ul which is inside of the body.
And this natural way of nesting HTML tags within each other
is a nice way of being able to add and make
your website more complex by nesting more and more of these different HTML
tags together in order to create the end product that you ultimately want.
And so that is a ul, an unordered list.
Lower down on the page we also see an ordered list, which as you might guess
is labeled ol, ol for ordered list.
And that one is going to be numbered.
We have the first item, second item, and the third item.
And now if I were to open that up by opening up list.html, what we see
is we have an unordered list that just shows up as a sequence of bullet points
and an ordered list that shows up as a sequence of numbers.
Note that nowhere in my HTML that I actually say, OK, this is one
dot first item, or two dots second item, three dot third item.
The web browser knows to render it as an ordered list
and it puts the numbers there for me, such
that if I try and insert another item here I
don't need to go back and renumber the bullet points.
The web browser will take care of noticing
that this is the third list item.
This is now going to actually be the fourth list item.
And when I render that page it's going to show
me here's the first item and the second item, another item, the third item,
and the fourth item in the list there as well.
So the web browser is pretty smart about these things.
It knows the names of these tags and it knows what they mean and what they do.
And it can use that information in order to make a web page that
looks the way that we want it to look.
Questions about any of that so far, or about the tags that we've seen?
All right.
We'll keep going.
So that was images.
We'll show you a couple of other things that HTML can do.
One thing that it's very useful for is rendering tables.
So we will have tables of data with rows and columns
and we want to display that data to the user.
Let's take a look at table.html, which will be an example of that.
So what we have here is a table that represents US presidents.
Just the first two.
But what we'll notice here is that we have a table tag that begins the table.
And then we have a whole bunch of tags nested within it.
We have a tr tag, which stands for table row.
And then within that we have th tags, which stands for table headers.
So if you think about this just going one layer at a time,
we start our table.
And the first thing in our table is going to be a row in that table
where that row is going to consist of three headers or three columns that are
being headed by these individual cells.
We have first name, last name, and years in office.
And now we end that row with /tr.
That's the end of that row and now we start another row.
Here's a table row that says, all right, here is
going to be the start of a new row of this table.
We have George and then Washington and then
the years of George Washington's time in office.
And if we scroll down a little more we see
we have another row underneath that.
Notice that inside of the row all of the individual cells
are stored in td elements, where td stands for table data.
This is just the data that is contained within that particular row.
And so now if I were to open up table.html, what I see
is something that looks something like this.
I see my title.
Notice presidents was here labeled as a h1,
so it's going to render as a large heading.
And within that I have individual rows.
Here's my header row.
The th ones make it render as sort of bold.
And I have the names and in the second row inside of that table as well.
Now, this might not look like a very fancy table.
It doesn't have borders or a coloring or it
doesn't look like it could be aesthetically pleasing.
We'll see later on in tonight's lecture how
we might go about styling a web page like this in order
to make it look a little bit nicer and look a little more aesthetically
pleasing.
But that's an individual table.
And if I wanted to, I could add an additional row to this.
Right here is two rows and I can just continue to add more elements inside
of this HTML page.
So I can say one new table row and I'll end that table row.
And inside of that is going to be table data Thomas Jefferson and 1801 to 1809.
And so if I refresh that page, we see that the third row in that table
now appears because I've added to the HTML code.
And you can continually do this by adding more and more HTML elements
to the contents of my HTML page.
One other HTML tag that we'll take a look at just to see how they work
is form.html.
So what we're looking at here is an HTML4.
Oftentimes, when we're working with applications
we don't just want to display information to the user,
but we want to collect information from the user in order
for them to either sign up for our website or log into our web site
or submit data to us in some other way.
And so what we see here is a simple example of an HTML form, where
we have this form tag in the end of the form to say here
is going to be a place where users can input data.
On line seven we have an input tag.
Notice that like the image tag there is no end tag here.
This is just going to be a place where users can input text
and we need to tell the web browser what type of information
the user is going to be inputting.
In this case, we're saying the type of that information is just
going to be text.
And we're specifying a couple of other optional attributes
that give additional information to this form so that it knows how to behave.
Placeholder is just full name.
Placeholder, if you'll recall, and we'll take a look at it in a moment,
is sort of that same text that appears in a text field
before you start typing in it just to give
the user a little bit of an indication as to what's expected of them
as to what goes there.
And this name field at the very end just gives a name
to this input field that says that this input field is
going to store the name of the person.
This won't become relevant just yet, but as we'll see later on in this course
as we start to actually do things with the form, take this information
and log it to a database or process it in some way,
being able to reference a particular input field by its name
can ultimately be very, very helpful.
And then finally down here after they type in their name,
let's give them a button to click on.
That's created just by using a button tag.
And the name of this button is going to be Submit, and then /button to say, OK,
that's the end of that button.
So if we render that form and take a look
at what that looks like when we open it as HTML
we see it's going to look something like this.
So we have a spot for the user to type in their full name.
Notice that full name is automatically placed there as the placeholder text
that we put in or HTML, and they can type their name in there.
And then the Submit button is a button that
would theoretically submit that form.
Now, this form doesn't yet do anything because we haven't hooked it up.
We haven't told the form what to do after someone clicks on the Submit
button, but we'll see later in this course
how we can begin to using other programming languages like Python
and JavaScript begin to take the results of form information
and do something useful with it.
But for now all we're doing is designing the front end.
What the user sees when they visit a particular web page.
So that was the form.
Questions about the forms or tables or images
or any of the other HTML elements or tags that we've seen thus far?
All right.
One helpful way to think about HTML as we
think about designing our HTML websites is thinking about them
like a tree structure.
If you're unfamiliar with tree structures,
effectively think of them as a combination of nodes
where nodes are just points within this tree that are connected to other nodes.
So in this case, if we look at a simple website like the Hello, World page
that we created before, if we wanted to represent this as a tree in HTML
we typically call that tree the document object model.
It might look something like this.
We have HTML at the very top.
Everything in our web page is contained within this HTML tag.
And within that HTML tag we have the header,
that head section of the HTML page, and we have the body of the HTML page
because inside of HTML we have the head here and the body there.
Inside of the head we have a title because the whole title
tag is nested within the HTML header.
And inside of that title is our text, hello.
And likewise, inside of our body is just this text, hello, world.
And you can imagine for some of our more complicated pages
that we saw earlier where we had tables, for instance,
that we might have a table element inside of our tree
and which is connected to a whole bunch of tr's for table
rows each of which itself is connected to a whole bunch of th's for table
headers, or td's for table data.
And you can represent this entire HTML page as this big tree.
And it might not seem very intuitive as to why
you might want to do that right off the bat,
but as we'll soon see, especially as we start diving into JavaScript later
on in the course that by having an understanding of this tree can
we start to manipulate it, can we start to add things to the tree
in order to add more to our web page, remove things
if we want to take things away from the web page
while the user is interacting with it.
And as we'll see in just a moment we can use this tree in understanding
what's contained within what to begin to style our web pages.
And styling our web pages is going to be the process of taking what so far has
just been websites that have a white background and black text on it
and maybe images and other things as well,
and starting to add some of our own custom styles
to it in order to make it look a little bit nicer to the user.
Because a big part of web development these days
is not just making sure that the web site works
and that it does what it's expected to do,
but also that it's visually appealing to the user.
That it's something that they would want to interact with,
that it looks nice, that it looks professional.
And so that is not something we can do with just HTML alone,
but it's something that's going to come in with an additional tool called CSS,
or cascading style sheets which is a different language altogether
and we can use to interact with HTML in order
to style the HTML in order to change the way the HTML looks according to rules
that we set in order to add color to our web pages, for example,
or add spacing in places where we want spacing or add borders to things
or add a background to things, for instance.
And so what we'll take a look at now is how
we might be able to leverage some of the tools of CSS
in order to design a web page that looks just a little bit nicer than the web
pages that we've already been working with.
So let's take a look at stylezero.html.
And what we'll notice is that this web page is
very similar to ones we've seen before.
It's got a body, it's got an h1 as the headline,
it's also got these p elements where p just stands for paragraph,
like a paragraph of text.
But the key difference here is that we've added a new attribute.
We've added this style attribute here that's associated
with h1, that headline.
And that style attribute is equal to something a little bit complicated,
but let's break it down into parts.
We have in quotation marks, "color:blue;text-align:center";
And so what we see here in this style attribute of our heading,
R2 is CSS properties, where a CSS property is just some specific style
property that the browser is going to understand and render in a particular
way.
And as you might guess what's happening here
is we're saying that we want to assign the color property of this heading
to blue and we want to assign the text align
property of this heading to center.
And so what that's going to do is instead of just rendering an h1 as we
normally would as just a black big headline on the left side
of the screen, we'll render it as a blue headline that's centered on the screen.
And so if we now open up stylezero.html, and we see a web page
that looks something like this.
That big heading is still there at the top of the page,
but it's a little bit different now.
We styled it to be blue, we styled it to be centered.
Whereas before, if we were to just get rid of this style tag
altogether and say that this is what that looks like without any
of that additional styling.
And so leveraging tools like that we can start
to build up styles for our web page.
We can start to make things look the way we want it to.
We can apply a color scheme to our website
in order to put whatever themed colors we want to put on our site.
And this can be used in order to add the sort of styling.
And HTML and CSS have a very rich vocabulary
for the types of things that can understand.
Obviously, we can be simple colors.
We can do the blue color or we can say red to make the headline render as red
instead, but there is something like 140 different colors
that HTML and CSS know how to understand and interpret.
So I could do something like color:dark magenta, for instance.
And if I refresh that page then the heading is rendered as dark magenta.
And if that's not enough color sophistication for you,
the 140 different named colors out there,
you also have the ability to select exactly which color you might
want by using that colors hex value.
And so in HTML and CSS and when we're dealing with color more generally,
we'll often represent color using a format called RGB, or red, green, blue
where we specify how much red is in the color, how much green is in the color,
and how much blue is in the color.
And using different combinations of red and green and blue,
where zero means very little red and 255 means a whole lot of red.
And likewise for green and blue can we represent basically any color
that we want to.
And so if we type in HTML color picker, for instance,
and we can see over here that this color, this shade of blue
is 66 amount of red.
So a moderate amount of red and a little more green, 134 green and 244 blue.
So a whole lot of blue.
And that is this particular color.
And so if we wanted to make our headings some different color, for instance,
maybe we want it green and we want it to be a darker green like this color,
for instance, that's this color.
That's 12 red, 142 green, and five blue.
And that color is represented by this up here.
This is called a hex code.
If you're familiar with hexadecimal or base 16,
it's effectively these three numbers 12, 142, and five represented in base 16.
No need to actually understand where that number comes from,
but effectively know that the first two of these numbers and letters
represent the amount of red, the second to represent the amount of green,
and the last represent the amount of blue.
And if I take that now 0c8e05, and in my HTML code rather than dark magenta,
I say #0c8e05, for instance, that same color hex
code that I saw before and then refresh my page,
now it's going to render using that exact same green.
So by using hex codes and understanding RGB values,
we can have a lot more control over the colors
that our web page uses by specifying exactly which
color that we want to display when that page ultimately gets rendered.
So that's the basic introduction to how we
might use the style attribute to begin to add some styling to our web pages
and make them look just a little bit nicer.
Questions about that so far, CSS or colors or anything we've looked at?
OK.
But we can in fact get even better at how
we go about trying to separate out the CSS
because natural questions that might come up now are number one,
we still have this styling code inside of the HTML file,
when it sort of feels like something separate.
The way that we style our website is sort of
fundamentally different from the actual content
of the text that goes on our website and the structure of our web page
in general.
But another issue that might come up is, what
if I start to build larger web applications that don't just
have one HTML file, that have two, three, four, or more HTML files
that all want to have red headlines that are all centered.
Of course, I could take the style tag and I
could copy paste it across all of my different HTML files,
but again, that brings up the same problems that we saw before.
The problem of whenever you find yourself copy and pasting
code and repeating code we run the risk of making it more difficult to maintain
and ultimately making it less elegant.
If we wanted to change the color down the line
it becomes a whole lot harder because we have
to change it in many different places.
So what can we do about that?
Well, we can take that CSS code and just separate it into a different file
altogether.
So what I'll show you now is styletwo.html.
Styletwo.html does the exact same thing as styleone.html.
And all the source code will be made available to you afterwards as well.
Styletwo.html shows you a big blue centered headline,
but how is it doing that?
Well, the body is still the same and we no longer have a style tag in the head,
but what we do have is this line here, line five.
Link rail equals style sheet href=styles.css.
So what's going on here?
This link tag is effectively telling us we
want to link in some other file that's going to provide us information to help
us know how to render this HTML page.
And what kind of information are we trying to render?
Well, it's going to be a style sheet.
Information about how to style our web page.
And which file are we going to include?
Which is the file that we want to link?
Well, it's styles.css.
And so now if we take a look at styles.css,
what's going on in there to allow it to render the CSS the way
that we want it to?
Let's open up styles.css.
It's exactly the same thing as the contents
that we saw in the style tag of our HTML header before.
It's just h1, color is blue, text align is center.
And that's what allows us to get this.
If we add additional properties, maybe I want my paragraphs
to all be red, for instance, and I save that, now if I refresh of the page
the paragraphs are red.
The HTML file didn't change at all.
Styletwo.html stayed the same.
Yet, when I refreshed it the styles changed because this linked file,
this linked CSS file that is defining the style for my styletwo.html file
has been updated to say, now I want all of the paragraphs
to show up with red coloring instead of the original black.
And so we saw three different ways via which we can link CSS
into the contents of our HTML code.
One, just by including that style attribute directly in the HTML.
The second way, factoring it out into the header of the HTML
page so that it applies to the entire page.
And then finally, what might be one of the most common paradigms
you'll use, especially if you start building larger web applications is
this method of saying, take the CSS, separate out into a different file such
that even if I have many different HTML files
they can all reference the same CSS file so that they all
get styled the way that I want the page to be styled.
So those are the basics of how we might go about using CSS.
Now let's take a look at a couple of the common CSS properties
that we might use.
So far we've seen color to give a particular element of color in HTML,
and we've seen text align to say I want to center this text instead of left
justifying it.
And we can also use CSS to change the size of different elements as well.
So let's take a look at size.html.
And for good measure I've just included the CSS in the header
like we saw in the second example before.
Though in practice in a larger application
you might want to move this information into a different file.
But what you see here is inside the body I have a div.
And a div just basically means a division of my code.
Some section of my code that doesn't really have any real formal meaning.
It's just a section of my code that I want to do something with,
maybe style in a particular way.
And here's a style I've applied to it.
Background color is going to be teal, width is going to be 100 pixels,
height is going to be 400 pixels.
So if I now go to size.html, this is how it gets rendered.
We have a vertical just block of HTML content that says hello, world.
But in particular its background color is teal, it's got a particular width
and it's got a particular height as defined
by what I included inside of my style tag just a moment to go.
And so using these width and height tags we
can start to really define exactly what our website looks like.
If we change the width to 500 pixels instead of 100
and refresh the page there, we see that now it's a fair bit wider.
And so we can control exactly how the web page shows up
just by making these small modifications to it.
But now what if we wanted to add a little more to this website
in terms of its design, in terms of the spacing of this page,
in terms of thinking about what it's going to look like?
You notice that right now this hello, world block
is very close to the upper left hand corner of the screen.
Maybe we would want to move it around a little bit more.
So that's where we can start to introduce the notion of a margin
around the edge of a particular HTML element.
So for instance, if I go in here and set the margin of the div
to be 30 pixels, for instance, and now refresh that page,
now we see that hello, world has a margin around it.
It's got this sort of 30 pixel invisible border that's surrounding it.
And it helps to space that out from different elements.
And so controlling margin can often be helpful
when you're trying to lay out a web page with a bunch of different elements
and you want to control how far apart different elements are from each other.
The margin is very helpful there.
Another thing you might notice is that hello, world right now
is very much just directly at the edge of this teal box, which
looks a little bit suboptimal.
Maybe I would want to change that a little more.
And for that I can add in another CSS property called padding.
So I can say, all right, let's add a padding of maybe 20 pixels.
And after I refresh that, now you'll notice
that hello, world is internally padded by sort
of an invisible border of 20 pixels.
And so margin and padding are both used in order to control spacing.
But the key difference is that the margin of an element
is the space around this outside of the border of the element.
So this is my div, this teal box.
The margin is what's outside of it.
I've got 30 pixels of space along that side
and the padding is between the content of the element and that elements
border.
So this right here is 20 pixels worth of padding for the hello, world
that's located inside of this div.
And so using margin and padding, especially on larger web applications
you can start to really control the look and feel of the website
in order to make it display exactly the way that you would want it to.
All right.
Thus far we've also only been interacting with our HTML page
in the sense of having text that is all of the same font.
It's sort have been the same default font
that HTML tends to use whenever a web browser is displaying HTML content.
And maybe we'd like to have a little more control over that.
So let's open up font.html, and take a look at what's going on there.
So again, we have a body inside of which is a div that says hello, world.
And inside of the style tag up here we've
added some special styling to that particular div.
In particular, we've added three things.
We've added a font family that effectively just says
this is the font that I want this div to render in.
And notice that I haven't just said give it one font.
I said Arial, but I said Arial, sans serif.
Reason for this is when we start to think
about making sure that our website looks right in matter what browser it's
loaded on.
So maybe you were wanting to even include some font on your web page
that the user's computer doesn't have, or that the user's web browser just
doesn't understand.
And so if you include multiple thongs as the font family
in the styling of our HTML, then what's ultimately going to happen there
is-- sorry.
There's an extra tag there.
What's ultimately going to happen is that the web browser will first
try and match the first font that I provide.
It will try and use the font Arial if at all possible.
But if it doesn't have the font Arial, if the web browser doesn't
know what Arial is or can't find that font,
it's just going to default to any sans serif font.
And so oftentimes if you want to use fancier fonts on a web page
it can be a good idea to include the font that you want,
but after that some additional more common fonts
that might be more common in other browsers
on older browsers in particular that way you
can guarantee, or at least know with high probability
that when a user looks at your page they're
seeing what it is that you actually want them to be looking at.
In addition to the font family, we've additionally
specified the font size for how big we want the font to show up as.
In this case, 28 pixels tall.
And finally, a font weight.
You want the fun to be bold, for instance.
So now if we open up font.html, we see that what we get
is slightly different text rendering that what we saw before.
We see hello, world, but it's no longer in that same font
that it was previously.
It's now 28 point font in size, it's now in a particular font,
it's now bold because we were able to control
the font that was present there.
Couple other CSS things that we'll just take a look out before we move on.
We'll take a look at border.html So again, we have inside of the body
a div that says hello, world.
Just [INAUDIBLE] saying hello, world in some rectangular box.
But in the past that rectangular box has sort of been invisible.
We've seen the words hello, world, but there hasn't been
like in a physical box drawn around it.
But now there can be.
Up in the style tag we're going to specify that we want inside of the div
for there to be a border and that border to be a three pixel, solid blue line.
And so by specifying border three, pixel, solid blue
we can open up border.html and now we see
hello, world inside of this rectangular box that is a three pixel blue line.
And we can change this, can customize it however you like.
It can be a five pixel, dotted red line, for instance.
And now it's going to look something like that.
So we have full control over what the border looks like.
And again, there are many, many CSS properties.
Far more than we're going to be able to look at in just tonight's lecture,
but I'm giving you a taste of them, just a teaser
of what CSS properties are out there so that as you start
designing your own web applications you can
think about what do you want the web page to look
like, you can get a feel for what CSS is capable of.
And as a result, you can start to design pages that look
the way that you want them to look.
So that's borders.
And now let's try and use some of the CSS that we've learned in order
to improve the style of one of the HTML pages that we've already looked at.
So let's take a look at table.html.
And recall that table.html was just a simple web page that
listed presidents of the United States.
We have Washington, Adams, Jefferson.
And right now this table doesn't look particularly fancy or particularly
great, but we can use CSS now to begin to add styling to it,
to begin to control the way this looks to make it look the way we want it to.
Maybe, for instance, we want a border around this table.
So up in the head I can add a style tag and say, all right,
around the table lets add a border and let's make it two pixels solid black.