Request Headers

    Request Method: GET, POST, PUT, HEAD

  accept: Tells the server what type of content the client want's (html, xml, json, etc..)

  accept-encoding: Tells the server what content encoding's the client understands (gzip,deflate, etc..)

  cookie: client cookies are passed to the server with the request (more on this later)

Response Headers

  Status Code: Tells the client how the request was completed. (200 OK, 404 NOT FOUND etc)

 Status Code ranges:

               1xx Informational

               2xx Success

               3xx Redirection

               4xx Client Error (  418 I'm a teapot )

               5xx Server Error

Response Headers con't

  content-type: What type of content the server returned (may not match accept header from client)

  content-encoding: How the content is encoded (gzip)

  cache-control: Tells the client how long this content can be cached for. 

  set-cookie: Tells the client to store the following cookies for future requests back to the server.

The presentation language of the web. 

<open> and </close> tag semantics

Declarative language used to describe WHAT should appear on the screen. Not HOW it should appear.

Different tags denote different content container types

<span> <div> <ul> <img> <video> <audio>

   HTML 5 is the newest version of the W3C consortium specification for HTML language. 

  

A large part of the spec focuses on the "Semantic web" 

  The semantic web's purpose is to provide more descriptive container elements that are able to more aptly describe the content that is place within said tag.     

 Prior to HTML 5, when you built a navigation bar on your page you would probably do something like this

  

     

The point was to try and imply the content container type ("nav") while having to use a generic container element "div"

     In HTML 5 a new tag called <nav> was introduced. 

<nav></nav>

Now the tag itself implies the content contained within. 

This makes the HTML language more semantic (less overloading of the vocabulary)

DO: Keep your HTML simple (K.I.S.S)

DO: Put CSS in a seperate file

DO: Leverage semantic tags to increase readability

DO: Reduce nesting of elements

DON'T: Inline CSS in HTML elements

DON'T: Inline CSS in HTML Document head

DON'T: Use HTML elements to imply style (e.g. <table> for layout structure)

CSS is a markup language that allows to you apply visual styling to HTML elements

HTML elements define layout container and content semantics

CSS applies the visual styling to these elements

DO: Favor unobtrusive CSS

DO: Use sensibly named CSS classes

DO: Keep styles simple

DO: Favor style composition on HTML elements

DON'T: Inline CSS

DON'T: Make classes hard to refactor

Used to match CSS classes to HTML elements in the DOM

Gives you a pattern matching system to apply styles to groups of like elements

Element id ,Element type, Element class etc..

Can apply selector filters to build more complex selector logic

use a period ( . ) to denote a class name selector

.className {} 

use a hash ( # ) to denote an id selector

#id {} 

use an HTML element type for a type selector

div {} 

use square brackets [ ] to denote an attribute filter

a [href="http://www.carestream.com"] {} 

http://net.tutsplus.com/tutorials/html-css-techniques/the-30-css-selectors-you-must-memorize/

      if (doneCorrectly){

          return "awesome";

      }else{

          return "frustrating"

      }

};

var question = whatIsJavascript;

var answer = question();

Interpreted

Dynamic 

Loosely Typed

Prototypical

Functional 

C style syntax

DO: Favor unobtrusive JavaScript (separate files, no inlining)

DO: Follow normal coding principles DRY, KISS etc..

DO: Try to avoid deeply nested callback structures

DO: Follow the "revealing module" pattern (more later) 

DON'T: Introduce global variables (THIS IS A BIG ONE)

DON'T: rely on this semantics if possible

DON'T: Rely on object state. Remember.."functional"

"Run" javascript?

JS is an interpreted language, meaning the runtime environment (usually the browser) contains an "interpreter" that executes JS code on the fly (no compilation). 

To "run" JS you need to load your JS file into the interpreter. 

In HTML this involves referencing your JS file in the context of a page.

Debug JS?

Many runtime environments also supply debuggers.

In Chrome, the developer tools (Ctrl + Shift + I) has an excellent debugger.

Visual Studio can also attach to the browsers JS interpreter and provide a great debug experience.  Simply F5 your MVC project and place breakpoints in your JS as you would normally.

Step 1: Browser makes a request to the web server

Step 2: Web server processes request and sends a response

Step 4: HTML document is parsed.

Step 5: CSS files are loaded and applied to HTML elements

Step 6: Javascript files are loaded into the JS interpreter and executed