├── .gitignore ├── .jshintrc ├── CONTRIBUTING.md ├── LICENSE ├── Procfile ├── README.md ├── app ├── data │ ├── REST.md │ ├── apis.md │ ├── browser-compatibility.md │ ├── client-server.md │ ├── css.md │ ├── html.md │ ├── http-requests.md │ ├── http-status-codes.md │ ├── http.md │ ├── javascript.md │ ├── jquery.md │ ├── mvc.md │ ├── technology-stacks.md │ ├── the-DOM.md │ ├── web-applications.md │ └── web-standards.md ├── index.js ├── styles │ └── custom.css ├── vendor │ └── Skeleton-2.0.2 │ │ ├── css │ │ ├── normalize.css │ │ └── skeleton.css │ │ └── images │ │ └── favicon.png └── views │ ├── about.jade │ ├── index.jade │ ├── layout.jade │ ├── map.html │ ├── partials │ ├── about.jade │ ├── github.jade │ ├── google-analytics.jade │ └── header.jade │ └── topic.jade ├── gruntfile.js ├── index.js ├── package.json └── public ├── css ├── styles.css └── styles.min.css ├── img ├── DOM.jpg ├── client-server.gif ├── cluster_key.jpg ├── cluster_programweb_nav.jpg ├── cluster_web_stack_color.jpg ├── cluster_web_works_color.jpg ├── cluster_webapps_nav.jpg ├── cluster_webstack.jpg ├── cluster_webworks.jpg ├── cluster_webworks_nav.jpg ├── css_where.jpg ├── html.gif ├── logo.jpg ├── mvc.gif ├── parent_child.jpg ├── request.jpg ├── response.jpg ├── status_100.gif ├── status_100_old.gif ├── status_200.gif ├── status_200_old.gif ├── status_300.gif ├── status_400.gif ├── status_500.gif └── web_nav.jpg └── js └── image-map-resizer ├── .gitignore ├── README.md ├── bower.json ├── gruntfile.js ├── imageMapResizer.jquery.json ├── js ├── ie8.polyfil.js ├── ie8.polyfil.map ├── ie8.polyfil.min.js ├── imageMapResizer.js ├── imageMapResizer.map └── imageMapResizer.min.js └── package.json /.gitignore: -------------------------------------------------------------------------------- 1 | npm-debug.log 2 | node_modules 3 | 4 | -------------------------------------------------------------------------------- /.jshintrc: -------------------------------------------------------------------------------- 1 | { 2 | "camelcase" : false, 3 | "curly" : true, 4 | "eqeqeq" : true, 5 | "forin" : true, 6 | "immed" : true, 7 | "indent" : 2, 8 | "latedef" : true, 9 | "newcap" : true, 10 | "noarg" : true, 11 | "noempty" : true, 12 | "nonbsp" : true, 13 | "nonew" : true, 14 | "plusplus" : false, 15 | "undef" : true, 16 | "unused" : "vars", 17 | "strict" : false, 18 | "trailing" : true, 19 | "maxparams" : 4, 20 | "maxdepth" : 2, 21 | "maxstatements" : 15, 22 | "maxcomplexity" : 6, 23 | "maxlen" : 120, 24 | 25 | "asi" : false, 26 | "boss" : false, 27 | "debug" : false, 28 | "eqnull" : false, 29 | "esnext" : true, 30 | "evil" : false, 31 | "expr" : false, 32 | "funcscope" : false, 33 | "globalstrict" : false, 34 | "iterator" : false, 35 | "lastsemic" : false, 36 | "laxbreak" : false, 37 | "laxcomma" : false, 38 | "loopfunc" : false, 39 | "maxerr" : 50, 40 | "multistr" : false, 41 | "notypeof" : false, 42 | "proto" : false, 43 | "scripturl" : false, 44 | "smarttabs" : false, 45 | "shadow" : false, 46 | "sub" : false, 47 | "supernew" : false, 48 | "validthis" : false, 49 | "noyield" : false, 50 | 51 | "browser" : false, 52 | "couch" : false, 53 | "devel" : false, 54 | "dojo" : false, 55 | "jquery" : false, 56 | "mootools" : false, 57 | "node" : true, 58 | "nonstandard" : false, 59 | "prototypejs" : false, 60 | "rhino" : false, 61 | "worker" : false, 62 | "wsh" : false, 63 | "yui" : false 64 | } 65 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing to the Animated White Board of the Web 2 | 3 | So you want to contribute? Awesome. We've written up some guidelines here to make that easier for you. 4 | 5 | ## Text Content 6 | 7 | The biggest and most helpful contribution that the community can make on this project now is to write, audit, edit, and fact-check the text content. Please file a single issue/PR per content topic page when making edits or reporting bugs. 8 | 9 | The key to creating good text content for the Animated White board is to put yourself in the place of a complete, or almost complete beginner. Only reference abstract ideas or higher level concepts with links to their explanation in the Animated White Board. If there is no page to explain a concept you need, either explain it right in the article you are editing; or create a new article. We recommend that you first explain it in a pre-existing article and then, in a separate PR, separate it out into it's own article. 10 | 11 | The tone of the Animated White Board is conversational and it's coverage of topics is brief, high-level, and focused on practical skills and workflows. When you "find an omission" in the project, take a moment to consider whether it was left out for the purposes of keeping the text abstract and introductory in nature. If you aren't sure, open an issue for discussion first, and then, after feedback, decide to either move forward with a PR or not. 12 | 13 | ## Images and Animation 14 | 15 | Currently, we are not looking for contributions of images or animations right now. In the long run, we'd like the Animated White Board to be a collection of a lot of people's images and ideas, but right now we don't have that funcationality. In the meantime, if you have an idea ofor an image or animation, create an issue with a shot of a sketch or a description and we'll do the magic image and animation making on our side (if we decide to move forward with your idea). 16 | 17 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2014 Bocoup 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | 23 | -------------------------------------------------------------------------------- /Procfile: -------------------------------------------------------------------------------- 1 | web: node index.js 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Open Web Fundamentals! 2 | ===================== 3 | 4 | Open Web Fundamentals is project aimed to serve as an introductory resource for anyone interested in familiarizing themselves with foundational concepts regarding the open web in preparation for developing, designing, or consuming content or applications. 5 | 6 | Key concepts: 7 | - History of and Process of Web Standards 8 | - Client/Server Relationship 9 | - HTTP 10 | - Basic Roles of HTML, CSS, Javascript 11 | - HTML5, CSS3, and the 'Living Standard' 12 | - The Document Object Model (DOM) 13 | - Browsers 14 | - Open Source Models, Practices, and Philosophy 15 | 16 | ## Up and Running 17 | 18 | 1. Fork and clone this project. 19 | 2. `npm install` 20 | 3. `node index.js` 21 | 4. Visit `http://localhost:8080/` 22 | 23 | While in development, run `grunt` to watch and lint all javascript files, as well as concat custom and vendor css. 24 | -------------------------------------------------------------------------------- /app/data/REST.md: -------------------------------------------------------------------------------- 1 | # REST (REpresentational State Transfer) 2 | 3 | REST is a convention for building web services, like an API. Conventions are rules and practices that groups of people agree to in order to streamline the production of a shared or similar product or service. Web services built following the REST convention, or any convention, are more predictable and maintainable than web services not built following a convention. This makes them easier and faster for other developers to use, build, and contribute to, because developers do not need to spend time learning the bespoke rules of an individual web service. 4 | 5 | Based on the original specification made by Roy Fielding in his dissertation, RESTful web services conform to six constraints: 6 | 7 | - Uniform Interface 8 | - Stateless 9 | - Cacheable 10 | - Client/Server 11 | - Layer System 12 | - Code on Demand 13 | 14 | The key thing for a beginner to know is that RESTful web services are self-contained services served over a uniform interface that allow development of a server and client to happen independently, assuming that uniform interface is maintained. 15 | 16 | ## What it might look like 17 | 18 | The uniform interface is a mapping of HTTP methods to resource-based URIs representing either a collection of resources or an individual resource; these URIs are called collection and elements URIs. 19 | 20 | ### Collection and Element URIs 21 | 22 | A collection URI should return a data structure containing all of that type of resource. While not always followed, it is convention to pluralize the resource name. 23 | 24 | e.g. `http://www.myapp.com/api/cats` 25 | 26 | An element URI should return a data structure containing an individual element of a type of resource. Generally this is indicated by an id number following the pluralized resource name. 27 | 28 | e.g. `http://www.myapp.com/api/cats/1` 29 | 30 | ### Putting it all together 31 | 32 | With this understanding, a RESTful API for the resource `cat` in `myapp` should look like this: 33 | 34 | - `GET http://www.myapp.com/api/cats` should return all cats 35 | - `GET http://www.myapp.com/api/cats/1` should return the first cat 36 | - `POST http://www.myapp.com/api/cats` should create a new cat 37 | - `PUT http://www.myapp.com/api/cats/3` should update or create the third cat 38 | - `DELETE http://www.myapp.com/api/cats/2` should delete the second cat 39 | -------------------------------------------------------------------------------- /app/data/apis.md: -------------------------------------------------------------------------------- 1 | # APIs 2 | 3 | An API or an Application Programmer Interface is the collection of public, or *exposed*, methods/functions available for a programmer to use when interacting with an application, framework, or library. That is, an API always *belongs* to something; depending on what it belongs to, we can generally anticipate that it has a specific type of structure. 4 | 5 | ## CRUD Application APIs 6 | 7 | The primary way the term API is used is to describe a set of endpoints that an application exposes for the purpose of allowing a client to perform certain tasks regarding the resources associated with that application. Those tasks are often known as CRUD tasks: 8 | 9 | - Create: make a new resource 10 | - Read: get a resource(s) data 11 | - Update: edit a resource's data 12 | - Delete: remove a resource 13 | 14 | ## Library and Framework APIs 15 | 16 | The word API is also used when talking about the public methods that a library or framework exposes to the programmer. For example, you might hear someone say, "The new version of the jQuery API exposes some new methods." It is less common, though still quite frequently used. 17 | 18 | ## Standards and Conventions 19 | 20 | APIs are the backbone of modern web development, so it's no wonder that standards and conventions have been designed for them. These standards and conventions primarily address the first type of API, describing the endpoints of an application. 21 | 22 | A very common convention is REST. Read more about that [here](REST). 23 | -------------------------------------------------------------------------------- /app/data/browser-compatibility.md: -------------------------------------------------------------------------------- 1 | # Browser Compatibility 2 | 3 | The internet has an interesting geneaology, and due to this bottom-up development, it poses unique challenges to the developer. Unlike native or server-side web development, where the developer has nearly complete control over the environment where her code will run, the client-side web developer writes code that will run in one of several, sometimes *very different*, browser environments. 4 | 5 | ## How do I know what will work where and how? 6 | 7 | One of the most difficult things in web development is knowing which features of HTML, CSS, and JS will work in which browsers at which version using which technique. Ideally, a browser will support a feature in a standard way, but often before this can occur, the feature is supported using either a vendor prefix or a polyfill. 8 | 9 | A good place to look is [caniuse.com](http://www.caniuse.com). Also, every MDN page on CSS properties will explain where each property is implemented and how to use it (prefix or not, etc). 10 | 11 | ### Vendor Prefixes 12 | 13 | A vendor prefix is a string added to the beginning of a CSS property to point to a specific browser's implementation of the property. 14 | 15 | - `-webkit`: for webkit browsers, e.g. Safari 16 | - `-moz`: Mozilla Firefox 17 | - `-ms`: (Microsoft) Internet Explorer 9+ 18 | 19 | The intention of vendor prefixes was to allow each browser to create its own interpretation of a proposed CSS property; when the property enters "final" status with the W3C, it is a simple change for browser vendors to drop their prefix in favour of the final version. 20 | 21 | As a rule, vendor prefixed properties are written first in any style declaration, with the final version of the property at the end. For example: 22 | 23 | `div {` 24 | `-webkit-border-radius: 5px;` 25 | `-moz-border-radius: 5px;` 26 | `border-radius: 5px;` 27 | `}` 28 | 29 | There are plenty of other vendor prefixes but they aren't used often. 30 | 31 | ### Polyfills, Shims, and Shivs 32 | 33 | A polyfill is a piece of code, usually JavaScript, that provides features that a developer would expect the browser to provide natively. One uses a polyfill when they would like to write their code using new technologies, but need to support browsers, usually older versions, that don't support those features. 34 | 35 | Sometimes these are also called shims or shivs. There are minor differences among these designations, but they are relatively insignificant, practically speaking. 36 | 37 | For example: 38 | 39 | The new HTML5 "living specification" allows one to use new elements such as `
` and `
`; Old browsers like IE6 don't support these elements. One can use a polyfill, e.g. html5shiv, to provide support for these elements via JavaScript. 40 | 41 | It looks something like this: 42 | `` 45 | 46 | ## Internet Explorer: what's the deal? 47 | 48 | Internet Explorer is a particularly difficult browser to deal with for web developers, particularly anything below version 8. This can be a tricky situation given that at least up until very recently, most users ran Windows, the operating system that comes with IE by default. 49 | 50 | This happened because Microsoft chose to develop IE in way that was very very different than Mozilla, Google, and Apple did. Recently, Microsoft has changed that practice and now development for more modern versions of IE has become increasingly easier. 51 | -------------------------------------------------------------------------------- /app/data/client-server.md: -------------------------------------------------------------------------------- 1 | # The Client-Server Relationship 2 | 3 | ![client-server](/img/client-server.gif) 4 | 5 | One of the most important concepts to understand in web development is the relationship between two computers, the client and the server, during a web transaction. 6 | 7 | In this relationship, the client is a computer, much like the one you are on right now, that is accessing content on the web throughthe browser or the terminal. 8 | 9 | # Requests 10 | 11 | ![client-request](/img/request.jpg) 12 | 13 | Say we are trying to access a website from the browser on our computer. To do this, we'll type a URL into a browser and hit enter, or click a link; either way, when we do so we'll be sending a *request* to another computer, the *server*. 14 | 15 | # Responses 16 | 17 | ![server-response](/img/response.jpg) 18 | 19 | When we send a request to a server, assuming it gets to the server, we will get a message back from that server called a *response*. This response will be accompanied by a status code, letting us know if we were successful, and if so what happened, or alternatively, if something went wrong, and if so, where it went wrong. 20 | 21 | 22 | All the work on the web is accomplished by the *request-response cycle*. 23 | -------------------------------------------------------------------------------- /app/data/css.md: -------------------------------------------------------------------------------- 1 | # Cascading Style Sheets (CSS) 2 | 3 | The web is styled based on rules written in the language, CSS. CSS is not like most programming lanugages you may have used before because it is declarative. Declarative languages have you write what you'd like to be the outcome of your program and then let the computer figure out how to accomplish that, as opposed to imperative languages where the programmer tells the computer what to do. 4 | 5 | ## Selectors 6 | 7 | Selectors are the way you choose what elements in your CSS get styled by the styles you declare. There are a lot of types of selectors, but the three primary ones are IDs, classes, and elements. 8 | 9 | For example: 10 | 11 | - IDs: ID selectors are preceded with a `#`. IDs are the most specific type of selector because there can only be one element on a page with a given ID. IDs are not a very good way to do styles because they don't encourage reusing styles. 12 | 13 | `
` 14 | 15 | `#about {` 16 | ` background-color: purple;` 17 | `}` 18 | 19 | - Classes: Class selectors are preceded with a `.`. Classes are a good way to reuse styles and are the most common selector used. 20 | 21 | 22 | `
` 23 | 24 | `.article {` 25 | ` text-align: right;` 26 | `}` 27 | 28 | - Element: Element selectors are the least specific selector and are often used in resets to remove native browser-styling or boilerplates to set basic styles. 29 | 30 | `
` 31 | 32 | `div {` 33 | ` margin: 20px;` 34 | `}` 35 | 36 | 37 | ## Where does it go? 38 | 39 | ![css_where-does-it-go](/img/css_where.jpg) 40 | 41 | CSS can be added to your HTML in three different ways: inline, internally, and externally. 42 | 43 | ### Inline 44 | 45 | Inline CSS is written as a string in the `style` attribute of an HTML tag. For example: 46 | 47 | 48 | `
` 49 | 50 | This type of CSS can target only *one* element, the element it is an attribute of, and as a result is the most specific type of CSS you can write. This means that the styles you write inline on an element will beat all other types of styles you might write that could target that element. 51 | 52 | ### Internal 53 | 54 | Internal styles are written between `` tags in the `` of your HTML. For example: 55 | 56 | `` 57 | ` ` 63 | `` 64 | 65 | ### External 66 | 67 | External styles are separate `.css` files that are included in your HTML by using `` elements in the `` of your HTML. For example, given a `styles/custom.css` file: 68 | 69 | `` 70 | ` ` 71 | `` 72 | 73 | 74 | Internal and external style specificity is based on the order they are placed in the `` of your HTML. The last styles declared or loaded are the most specific. Because of this, it makes sense to load or declare more general styles first, such as boilerplates like Twitter Bootstrap or a reset, and then later load/declare more custom styling. 75 | 76 | 77 | -------------------------------------------------------------------------------- /app/data/html.md: -------------------------------------------------------------------------------- 1 | # HTML (Hypertext Markup Language) 2 | 3 | HTML, or Hypertext Markup Language, is the language we use to specify the structure of our document. It is composed of a series of tags that form elements. 4 | 5 | ![html to layout](/img/html.gif) 6 | 7 | ## Elements 8 | 9 | You can "change" the default behavior of a type of element by changing its `display` property with CSS. 10 | 11 | ### Block Elements 12 | 13 | A block element assumes that it has a break before and after it, meaning that, by default, it takes up a single line all to itself. 14 | 15 | Examples of block elements: `
`,`

`,`

  • ` 16 | 17 | ### Inline Elements 18 | 19 | Unlike, block elements, inline elements do *not* assume a break before and after, and therefore can share a line with text and other inline elements. 20 | 21 | Examples of inline elements: ``, `