Exercises - Week 1

NOW THAT YOU'VE GOTTEN THROUGH THIS WEEK'S MATERIAL, YOU CAN SHOW WHAT YOU'VE LEARNED BY COMPLETING THESE EXERCISES.

To get credit for the course, Week 1 exercises are due on 30 May 2016

But we advise you to do the exercises after studying this week's material, while everything is fresh on your mind ;)

Recipe project - Week 1

Throughout the course, we'll be building a simple project, adding to it with what we've learned each week.

This project will be a simple Web App that will allow you to browse different recipes.

This week we'll start off with a simple first draft using just what we've learned about HTML5 using tags we've covered.  We want to have the following components:

• A large title for the app, something like "My Favorite Recipes", or whatever you'd like to call it.
• A description of a recipe, just some plain text explaining what the recipe is and any other pertinent information.
• A set of steps to follow, numbered in order.

When you're done you should have something like this:

If you have any questions or problems, discuss them below.

SHARING YOUR CODE

Of course, having a Web page isn't as much fun if you don't have a way to share it.  There are a number of different possibilities.  If you type "Web hosting static webpages" or something similar into your favorite search engine, you can find a number of different options.

One free option is to use 'github', which provides a place to store and track your project as well as a way to host static web pages using 'github pages'.  If that's something you're interested in, you can find out more about it here.  Other project hosting sites offer similar possibilities.

Another easy way to share your app is to take advantage of the build feature of Intel® XDK.  This allows you to build your page as a mobile app that can be installed on phones and tablets.  You can find out more about that here.

Video: recipe project - Week 1

Hopefully you've tried this little bit on your own.
This shows you what I did, which could be similar to what you did.
First a title for our recipe project.
I'll just leave it generic for now, (I don't have any bright ideas).
Then under "My Favorite Recipes », we'll give an example of a recipe.
Again, this will just be generic, so I'll have some instructions for the recipe.
And then often you have a list of steps for a given recipe.
So we'll add that as a list.
Each item of the list will be another step in the process.
For now I'll just put Step 1, Step 2, Step 3, and so on.
To make it a little quicker I'll just copy those and change "First" to "Second" and "Third".
Since these are in order, it might make more sense to have an ordered list instead of unordered list.
We change the open and close tags to 'ol’, and you'll see we've got numbers instead of bullets over there.
One more thing we could try is a list of ingredients.
Let's put the list of ingredients up ahead of the instructions.
Again, we just put in some generic ingredients.
It's not necessarily as important for these to be ordered so I'll just use an unordered list for now.
And then we want something telling us that this is the list of ingredients, so I'll put in a paragraph.
A paragraph works fine, but this is really more of a header so let's change that to h3.
So it'll be a header, but smaller than the main header above.
The recipe instructions below are often more prose-like, so we'll just leave those as paragraphs.
It looks good! So far, so good!

Live coding video: more HTML5

Live coding video: more HTML5

A few new tags to learn

There are a lot more tags, but we will just cover a few more for now, mostly because they are straightforward to use and you can see the effect in your web page when you use them:

Tags we have already used

Now you can create a simple, empty, HTML page, and you know what tags are, though we have not said a lot about specific tags, what they mean, how many there are, etc.  We will start with the ones we have already seen:

• <!doctype> - This tag is special.  In fact, many folks don't even consider it a tag, as it is officially the DTD - Document Type Declaration.  Unlike most tags, it has no closing tag, not even a "/" at the end.  It is there to declare exactly what type of HTML the computer will find in this file.
• <html> - The html open and close tags wrap around nearly everything in your html file (except the doctype tag).  This essentially contains all of the HTML code in the file, which is generally everything (one big html element). Next week we will learn about attributes, and you will learn that you should always add a lang attribute to the html opening tag, to identify the default language of your page.
• <head> - The head element is where you put information that does notreally appear in the body of the work.  For example, the <title> of the page, which typically appears on the window containing the page, is defined in the head section.
• <body> - The body section contains all of the content of your page, essentially what the user sees.  This could be text, pictures, links, videos, tables and so on.  In addition to the content, the body usually contains lots of other elements, each indicated by their own tags.

• <h1> - There are a whole collection of 'h' tags, <h1>, <h2>, <h3> . . . all the way up to <h6>.  Why there are 6 rather than 5 or 7 may be a bit of a mystery, but there it is.  They're generally used the same way you would use chapter or section headings in a book (don't confuse the h here with the<head> section, that is completely different).  An <h1> tag might be used as the title of the document (as it appears on the page, not the same as the aforementioned <title> element), or to indicate the outermost level in a group of nested sections.

Though you theoretically should not think about what it looks like, it will typically appear as large, possibly bold text in your document, to mark a separation or beginning of some new section.  <h2> is usually a bit smaller, and <h3> smaller yet and so on down to <h6>.  This allows logical nesting of sections, though they should not be nested too deeply. Try not to skip levels of headers when nesting them. Headings are really useful for some assistive technology users and missing levels can be confusing.

• <p> - P is for 'paragraph', which is how much of your text information might be arranged.  Depending on the style you are using, text wrapped in a <p> tag may be indented or have extra vertical white space before starting.  When rendered on the web page, a p element will typically be a new line.

You might notice that when discussing how these different elements are rendered (i.e. what they look like to the end user) you will find words like "typically", "possibly", and "generally".  It is a little picky; as you will learn in Week 3, it is possible to change the styling of one element to look like just about any other element.  You could style a <p> element so that it looks like an <h1>, though best practice would be not to do that.

White space and other niceties

Before we go any further, it's good to understand a few technical details.  

TAGS ARE CASE INSENSITIVE

You might notice that code is not always consistent in how a given tag is written.  We might say <h1> in one spot and <H1> in another.  In this case, they are exactly the same kind of tag.  Tag names are "case insensitive" meaning that it does not matter whether you use capital or lower case letters in writing them.  In fact, you could write your body tag as 'bOdY', but that's not generally considered a good practice (it makes it harder to read).  On the other hand, there are places where you want the computer to be "case sensitive", meaning it the computer will distinguish between upper and lower case characters.

Obviously, you usually don't want your text (that the user reads) to be case insensitive.  You want your sentences and proper names to start with Capital letters, but most other characters to be lower case (unless you want to yell, IN WHICH CASE USE 'ALL CAPS').  You generally don't want the browser to mess with that. You would probably be unhappy if the browser turned all your letters into lower case.  And people might think you're quite tightly wound if the browser converted everything to Upper Case.

DON'T WORRY ABOUT TOO MANY WHITE SPACES

On the other hand, we usually do not want to worry about the amount of white space (spaces, tabs and returns) in between words and lines and paragraphs (well sometimes we do, but there's a tag for that).  In HTML, most extra white space will be ignored.   By 'extra', I mean more than one space (or tab) consecutively.  There are many places where you need to be sure to separate one thing from another with a space, but it generally doesn't matter if you put more spaces in there, your result will look the same.  Thus all three of the following elements should look exactly the same when you read it in the browser:

1.  <H1> This is the Beginning </H1>
2.  
3.  <H1>
4.  
5.     This is the Beginning
6.  
7.  </H1>
8.  
9.  <h1>This is the Beginning</h1>

It might seem confusing at first, but this rule about white space is actually very convenient.  The third option might be a bit too cramped for your taste, while the second might seem to take up too much room in your source code.  Because it doesn't matter to the browser how much white space there is, you can use white space to make your code more visibly organized and easier to read (note the use of indentation in the second <H1> element above).

Given that tag names are case insensitive (you can write them either way), you might think that everything in between < and > is case insensitive, but it is not that easy.  We have not learned much about attributes yet, but when we do we will discover that they are "case sensitive", thus these two elements will have different 'id's:

1.  <p id=ThisOne>
2.  
3.  <p id=thisone>

 Even though they're spelled the same, the differing cases indicate different names.  Note that distinguishing different ids solely by case (i.e. spelled the same but with different capitalization) is a really bad practice (opposite of best practice).  Instead you can use capitalization in other ways, likeCamelCase.

ANY KIND OF QUOTES FOR STRINGS

Finally, it will eventually be important to know about "strings".  Strings are just a series of characters.  They could be any characters like "Dingbats" or "ABC123^&*@aeiou".  They can even contain spaces as in "This is a string.".  Because they are so wildly variable (they can essentially be anything you can type), the computer needs us to indicate where a string begins and ends, which is typically done with quotation marks, either single (') or double (").  HTML tries to be helpful here.  You will find that in places where HTML is expecting certain types of strings (say a string without spaces), even if you do not use the quotation marks it will essentially insert them for you, thus:

1.  <p id=MyName>
2.  
3.  <p id="MyName">
4.  
5.  <p id='MyName'>

.... are all equivalent.  It is also important to know that, in HTML, double and single quotes are almost interchangeable, but they have to match.  If you start a string with a double quote, the computer will not end it until it sees another double quote.  Any single quotes will be happily considered part of the string, which is handy if you need quotation marks in your string.  Because of this, if you create a string as ' "quote" ' (single quotes containing a double quoted string),  your string will have the letters <space>-"-q-u-o-t-e-"-<space> (with double quotes in the string and spaces outside those) as opposed to "quote" which will just have the letters q-u-o-t-e (no quotation marks or spaces in the string).  Nevertheless, best practice is to be consistent in your quotes, so it's best to quote them all the same way, even if the browser would understand it anyway.

IN SUMMARY:

The idea is to take advantage of these flexibilities to create clean organized code that is easy for a human to comprehend.  I guess you could sum it all up with these simple dictums:

• Case matters, except when it doesn't - case matters for some things, like strings and attributes, but not others, like tag names.
• White space is ignored, except when it's not - White space is used to separate things, but adding more than one space will be the same as just one.  White space in strings is always just as you type it.
• Quotation marks are not part of a string, except when they are - Quotation marks enclose a string, but thanks to the flexibility of choice between single or double quotes, it is easy to include one or the other in your string.
• The important thing is to look good - You can take advantage of flexibility in capitalization and white space to make your code more readable and organized.

Do's and don'ts

The history of Web pages is such that browsers tend to be very forgiving of certain types of mistakes. If you miss a closing tag, it will often work the way you expect. It probably won't crash, or ignore the document, or give up completely, but it might not appear quite the way you meant it to. Or maybe it does look like you want, but you do not want to depend on that. In general Best Practice would be to do it properly, and not depend on the browser to patch it for you..

Because an HTML file essentially represents a tree structure, the open and close tags should always match, and there should not be any overlap with other elements. That is, you can have an element that is enclosed in another element, or you can have two elements side-by-side, but you can never have an a situation in which part of an element is in another, but the other part is not.

1. <p>This is a <em>paragraph</em><p>
2.  
3. <h1>Paragraph ahead</h1>
4. <p>And here it is.</p>

The two examples above are fine because in each case either an element is wholly contained in another (<em> in <p>) or they are completely separate (<h1> and <p>).  This, on the other hand, is not valid:

1. <h1>Part of this header is<p>in the</h2> paragraph below</p>

What happens in this case is what we call "undefined". That just means that there is no telling how the browser will decide to handle it. It might decide to automatically close the <p> when it sees another close tag, or it could complain about an unexpected close tag at the header. Then it might complain again when there is a now unexpected close </p> tag.

If you played around with the minimal HTML file from the previous section, you might have noticed that you can get more minimal than that. For example, if you take out the "head" section completely, the browser will still render the page without complaint (at least Chrome will; Firefox does complain in the debugging console, but we will save that for week 4). In fact, you can even take out the "body" open and close tags (not the content, of course) and it will still work as expected. Not only that, if you take out the <!doctype> statement, it still works (and Chrome still doesn't complain!).

What's actually happening is that the browser knows roughly what to expect in an HTML page, so if it sees a file ending in '.html' it will automatically stick some stuff in if it is not there already. It will typically make basic assumptions like: It is an HTML5 file, everything in there is content, so it goes in a <body> section, the <head> section is empty.  If you right-click on an element and choose "Inspect", you will see that the browser has included an <html> section containing a <head> and <body> section, even though it wasn't there in your file.

Note that we said "typically". The current behavior of most browsers will handle this, but it is "undefined" so there is no guarantee that next weeks update won't break it.  To be correct and complete you need the <doctype> and an <html> section with a <head> and a <body>. In any case, it is a good idea (best practice).

Proper indentation is one way to make your code clearer and easier to understand:

1. <body>
2. <h1>Here is a heading</h1>
3. <p>
4. <ol>
5. <li>List Item 1</li>
6. </ol>
7. </p>
8. </body>

The code above doesn't give any sense of the structure of the document. By using indentation effectively, you can make it more clear, showing the nesting of elements:

1. <body>
2.   <h1>Here is a heading</h1>
3.   <p>
4.     <ol>
5.       <li>List Item 1</li>
6.     </ol>
7.   </p>
8. </body>

Consistent quoting of strings is also helpful, in part to avoid potential problems that can arise when you think something does not need quotes but it actually does.

Often projects will have coding styles that everyone is expected to use so that everything looks consistent and developers can more easily read others code. If you are creating the project, you can decide what the rules are (how many spaces to indent, single or double quotes etc.) but unless there is a good reason to change away from typical practices, it is usually best to adopt them.