Composr Tutorial: Guide to web technologies (including HTML, CSS, and JavaScript)

This tutorial is an introduction to the main standard web technologies that Composr is built upon. It does not explain any technologies specific to Composr. If you need to learn about the Composr's own Tempcode technology, please read the Tempcode programming tutorial.

Overview

Composr is built on top of standard web/Internet protocols, languages and APIs. The main ones are as follows…

Protocol	Description	Relevance to you
Miscellaneous protocols
FTP and SFTP	This is the standard for uploading files to a server.	It is good to set up an SFTP client (FTP is not secure, so best avoided) and use that for uploading/downloading files. It is more convenient and reliable than using a webhosting control panel's file manager.
IMAP and POP3	These are the common protocols for accessing e-mail.	Unless you use webmail, you'll be using these already. You don't need any special understanding of them.
TCP/IP	This is the protocol for transmitting Internet data.	You won't need much awareness except knowing what IP addresses are and are used for (explained in the Using IP addresses to trace users tutorial).
DNS	This is the protocol for looking up the IP address for a domain name.	When you buy and configure a domain name, you are using DNS.
Punycode	This is a standard for International Domain Names (IDN).	When you input URLs into most non-Composr systems you'll need to make sure you use the Puny-coded version (only a tiny minority of users have an IDN though).
SMTP	This is the protocol for sending e-mail.	Unless you use webmail, you'll be using these already. You don't need any special understanding of it.
MIME	This is the standard for the composition of e-mails.	You don't need to know anything about MIME specifically, but a basic awareness that e-mails can have dual text and HTML versions, and contain both attachments and inline images, is useful.
DKIM	This is the standard for signing e-mails.	You don't need to know about this, unless you are configuring it to run on Composr generated e-mails.
SPF	This is the protocol for limiting what servers can send e-mail for a particular domain.	It is advised to set this up to reduce spam and fraud.
Web
HTTP with some common extensions	This is the protocol for transmitting web data.	You won't need much awareness that web URLs come from the HTTP standard, as do cookies, as does HTTP authentication (not used on many sites, but sometimes useful).
Web server	This is the software application that serves data over HTTP, and ties into PHP; Apache and IIS are examples of the web server applications Composr can use.	An awareness of web server configuration may be important. For example, how to configure Apache via .htaccess files.
XHTML5, HTML5 (and microformats)	This is the standard for web pages. XHTML is (for all intents and purposes) a more formal version of HTML, and we ensure Composr is written to this to make things clear and consistent. You will usually hear people talk about HTML rather than XHTML, and practically you can consider them the same.	Knowing (X)HTML is crucial to defining layouts and general template editing.
CSS	This is the standard for styling web pages; it ties into the (X)HTML.	Knowing CSS is crucial for adjusting theme styles.
PHP	This is the programming language Composr is written in.	Knowledge of PHP is only required if changing core Composr code.
JavaScript (aka ECMAScript) (optional), DOM, and XMLHttpRequest	This is the standard to make web pages interactive; it ties into the (X)HTML.	You will only need to know JavaScript if doing particularly advanced themeing.
SVG	Vector graphics standard, used for drawing statistics graphs.	You are unlikely to need any awareness of this.
robots.txt	Robots exclusion standard. Google's version of the specification is the most accurate to what search engines now support.	Knowing this may be important for SEO.
Robots meta tag and X-Robots-Tag HTTP header	Specifying what URLs may be indexed. Google's version of the specification is the most accurate to what search engines now support.	Knowing this may be important for SEO.
Accessibility and Internationalisation
WCAG 1.0 and 2.0 and WAI-ARIA	Accessibility standards, particularly for blind users.	We support the highest levels of compliance (AAA).
UK Gov. recommendation for access keys and Besluit Kwaliteit Rijksoverheidswebsites and Section 508	Detailed accessibility standards from particular countries.	We support these standards.
ATAG	Accessibility standards for site authors.	We are fully compliant.
ISO character sets and Unicode (UTF-8)	These are the alternative standards for Internationalisation support; Composr supports both.	By default Composr uses UTF-8 which means you don't really need much awareness of character sets. It is useful to know how UTF-8 works (particular how some character use more than one byte)
Data & Feeds
XML (including RSS, Atom, OPML, XSLT, XML Sitemaps and Google News Sitemaps, and use in AJAX)	XML is a standard for structuring data, used for many web formats that Composr supports, as well as a few configurable parts of Composr. RSS, Atom and OPML are feed technology, to export Composr news. XSLT is a technology we use to make RSS, Atom and OPML display in a web browser.	You won't need much awareness of XML unless doing particular advanced configuration.
File formats like iCalendar 2.0, CSV files, JPEG, PNG, Zip, Tar, Gzip	These are used in specific areas of Composr, for reading and writing special file types. PNG is an image file format. PNG is used in favour to GIF, as it supports images more than 256 colours, 'alpha transparency' (blended transparency that is not tied to background colour) and is not encumbered by software patents.	The ability to use image editors, and choose appropriate image file types, is definitely useful. Being able to import and export appropriately-structured CSV files (spreadsheets) is also useful.
LDAP 3	This is the standard for having shared logins on a computer network, which Composr can use.	This is only relevant if you are setting up a corporate Intranet.
WebDav	A network file system.	This can be used with The Repository for accessing the Commandr-fs filesystem.
JSON	This is a popular alternative to XML and is commonly used for web APIs between servers or between servers and web browsers.	You won't need to know JSON.
SQL	This is the standard for accessing/manipulating data inside databases; Composr uses it to talk to the database (e.g. SELECT * FROM table WHERE something='somevalue'), which is usually the MySQL database application.	A basic understanding of SQL is useful. Sometimes going down to the database level, bypassing Composr, is useful. For example, to make a bulk text change across the system you could write some queries to do so.
OpenSearch	This allows site searching (with auto-completion) integrated direct into web browsers.	You are unlikely to need any awareness of this.
Metadata
Open Graph	Facebook-originated metadata standard, with data being embedded into normal web pages.	This is automatically included in Composr's templates. Further documentation is in the Facebook Support tutorial.
schema.org	Search Engine originating standard for providing extra data about objects within web pages.	This is automatically included in Composr's templates.
Dublin Core and Composr Core	This is the standard for adding metadata to web pages; it ties into the XHTML.	This is automatically included in Composr's templates.
hCalendar	Standard for embedding calendar data within web pages.	This is automatically included in Composr's templates (calendar).
hCard	Standard for embedding contacts data within web pages.	This is automatically included in Composr's templates (member profiles).
hReview	Standard for embedding user review data within web pages.	This is automatically included in Composr's templates (content comments/reviews).
rel-nofollow, rel-enclosure, rel-license, rel-tag	Standards for describing linking behaviour.	This is automatically included in Composr's templates.
XFN	Standard for showing how website users are friends of each other.	This is automatically included in Composr's templates (limited support).
oEmbed	Provide extra information (e.g. thumbnails) for a link to a page on a site.	Composr can automatically locate oEmbed data for included links.

Composr itself provides the following protocols and languages…

Protocol	Description
Tempcode	This is Composr's template technology (Composr combines data with XHTML templates in order to construct XHTML web pages).
Comcode	This is Composr's easy-to-use content language (lumps of text are written in this, and there are optional ways of encoding sophisticated behaviours; it compiles to more complex XHTML/CSS/JavaScript, via templates).
Dublin Core extensions	Composr extends Dublin Core (described above).
Page-links	A simple technology for generating link between pages, that compiles to HTTP URLs; page-links are local to a website (i.e. they can only work to generate links within a site), and are consistent regardless of the URL Scheme employed (Composr supports URL rewriting, which can make the appearance of final URLs vary considerably).
Filtercode	For filtering results via property querying, simpler than SQL.
Selectcode	For selecting particular results via ID, ID range, category, or tree-position.
Language packs	Translation of a site into different/multiple languages

This tutorial focuses mainly on XHTML, CSS and JavaScript, which are the three technologies one needs to understand to do advanced themeing. Links to full resources for learning these technologies are also provided.

URLs

Like all websites, a Composr site uses URLs (aka web addresses) to link pages. Within Composr, they are usually written as Composr page-links (defined above in "Overview") and then compiled to URLs at the same time the XHTML is generated.

URLs (when written in full) are constructed as follows:

They are constructed as follows:

• Protocol: For a web page, the protocol is always 'http' or 'https' (because the page is transferred via the HTTP(S) protocol).
• Port: The port is almost always '80' which is the default port. If the port is 80 then it is not written down (i.e. ":80" is actually not in the URL).
• Hostname: The server is either specified by a domain name or an IP address.
• Path: The path often relates to a file on the server, but does not have to: it is up to the web server how to treat it. For a Composr site the path usually points to a PHP file on the server (which the web server will recognise as being something it has to run, and relay the output), except if a URL Scheme is on then it might go through a level of indirection (e.g. it looks to the visitor like it refers to an .htm file but actually is invisibly redirected to go through a complex path involving the index.php).
• Parameter(s): There can be any number of parameters (including none). The first one has a "?" before it and subsequent ones have a "&" before it.

Here is a real example:

This deconstructs as follows:

• Protocol: This is an HTTP URL.
• Port: As the port is not specified this is on the standard port 80.
• Hostname: This is on the machine where the domain name example.com points to.
• Path: The path is somepath/deeper/something.
• Parameter(s): We have two parameters one as 1, two as 2.

XHTML

XHTML5 (eXtensible HyperText Markup Language) is the language in which the Composr layout is written, and is what Composr is designed to output. A markup language is a text-based formatting system that allows an author to designate the structure and importance of pieces of a web page. You can't have a web page without markup; all web pages consist of markup. XHTML5 is the same as HTML5 except written to a higher standard of tidiness. It is designed with XML (eXtensible Markup Language) compatibility in mind.

As previously mentioned, all Composr pages are output as XHTML. To customise the appearance of your site, it is just about impossible to do anything major without editing the XHTML. In Composr, the XHTML is split up into various templates for ease-of-use and reusability. Composr also has an inbuilt XHTML webstandards checker, to help you in customising your site.

Syntax

The basic concepts behind XHTML are very simple: your document starts with a document-type definition, then the markup follows. The markup consists of various tag s, each with optional and mandatory attributes.
As you can see, the markup is quite simple. The tag consists of an opening part, and a closing part, with content in-between, and attributes listed in the opening part. However, some tags can be even simpler, and not contain any content, or even a closing part.
This form of tag is called self-closing, but is only found occasionally. For both forms of tag, however, there are some rules and guidelines that should be followed:

• Don't place extraneous spaces in the tag (i.e. between the less-than and the first character of the tag name)
• Always close the tag with a closing part, or a self-closing part
• Don't put more than one space between anything

Tags can contain as many attributes as you like, but they must be valid, and you can't repeat the same attribute twice. Let's look a little closer at the syntax for an attribute.
The syntax for an attribute is quite simple, too. However, there are some rules and guidelines you must stick to:

• Encase the attribute value in double-quotes
• Don't surround the equals with spaces (it must be next to the last character of the attribute name, and the opening double-quote for the attribute value)
• Keep the attribute name lower-case

Putting tags together is only slightly more complex than using single tags. You must bear in mind that XHTML is designed to produce a tree-structure of tags: one tag will contain several others (descendants), which in turn will contain another few (more descendants), or some text, etc.

A key part of this is the fact that there is some required markup in all XHTML documents: the three root tags. These tags (<html>, <head> and <body>) must be present in a particular place in every XHTML document along with a valid document-type definition and some required attributes, or browsers won't be able to make head-or-tail of the page.
That is just about the smallest valid page possible. However, you needn't worry about all this, as Composr already has the basic XHTML structure in-place and working perfectly.

One of the nice things about XHTML is the fact that you can place extraneous whitespace (spaces and tabs) between tags, to make the markup easier to read.
Doing this when writing markup is highly advisable as it saves hours of searching through markup to find closing parts, etc.

Up until now, we've only been working with theoretical and fictional XHTML tags and attributes. Next it's time to introduce you to some of the most commonly-used tags. However, first it must be noted that XHTML is not a layout language! It should not be used with the intention of creating a page with a particular appearance! XHTML coding should be approached with a purely structure-based mindset. That is, XHTML should be used to mark-up the structure of the document (e.g. headings, paragraphs, sections, links, lists, and other such structural paradigms). Anybody who uses XHTML with the intention of creating a page that looks a particular way is using it incorrectly. To learn about how to style a page, see the CSS section below.

Elements and attributes

Now, some HTML elements…

Element	Description
<a>	A hyperlink. Recommended attributes: href (URL to link to), title (text to display when hovered-over).
<body>	The parent tag for the main document body. Required.
<div>	Defines a document section. (See CSS section below.)
<em>	Adds emphasis to the text it surrounds.
<fieldset>	Groups form elements together logically. (See <form> tag below.)
<form>	Defines a form with which to submit data. Required attributes: action (URL to send data to). Recommended attributes: method (how to send the data; either get, or post)
<h1> to <h6>	Document headings; <h1> is the most important (you should have one of these at the beginning of your page, quoting your page title), <h6> is the least important.
<head>	The metadata section of the document. Contains information about the document which isn't displayed, but used by the browser in other ways. Required.
<html>	The main tag in an XHTML document. Required.
<img />	An in-page image. Note that this tag shouldn't be used to place layout images; only page-specific images. (See CSS section below.) Required attributes: src (the URL of the image), alt (alternate text to be displayed if the image cannot be displayed). Recommended attributes: title (text to display when hovered-over).
<input />	A form input, for entering data. Recommended attributes: value (the value to display – varies from type to type), type (the type of input to display: button, checkbox, file, hidden, image, password, radio, reset, submit, text), name (the name with which to refer to the input on the server), id (the unique identifier with which to refer to this element (see CSS and JavaScript sections below)).
<label>	A label associated with a form element. Recommended attributes: for (the ID of the form element associated with this <label>).
<legend>	A caption for a <fieldset>.
<li>	An element in a list (see <ul> and <ol>).
<ol>	An ordered (sequential and numbered) list.
<optgroup>	Groups <option>s in a <select> list. Required attributes: label (the label for the option group).
<option>	An option in a <select> list. Recommended attributes: value (the value to be sent to the server when the form is submitted).
<p>	A paragraph. This element is very commonly used.
<select>	A drop-down list. Recommended attributes: name (the name with which to refer to the input on the server), id (the unique identifier with which to refer to this element (see CSS and JavaScript sections below)).
<span>	Groups inline elements. (See CSS section below.)
<strong>	Designates text as strong (usually displayed as bold).
<sub>	Designates text as subscript.
<sup>	Designates text as superscript.
<table>	A table. Note that this should not be used to lay-out pages! (See CSS section below.) Recommended attributes: summary (a medium-length summary of the content of the table for non-visual browsers).
<td>	A table cell.
<textarea>	A multi-line text input area. Required attributes: cols (how many character columns to display), rows (how many character rows to display). Recommended attributes: name (the name with which to refer to the input on the server), id (the unique identifier with which to refer to this element (see CSS and JavaScript sections below)).
<th>	A table header cell.
<title>	The title of the page (to be displayed in the browser's title bar, for example). Required.
<tr>	A table row.
<ul>	An unordered (non-numbered – blank bulleted) list.

Although the above table doesn't list all of the XHTML elements (it lists approximately half of them), the others are used so rarely it's easier to look them up when required, than learn them first. This table also does not list all the attributes of all the elements. However, it lists the important ones, and the following table lists all the attributes that can be used with any XHTML element; the standard attributes.

Attribute	Description
class	The CSS class of the element; used to style and jazz-up appearances. (See CSS section below.)
id	The unique identifier for the element (see CSS and JavaScript sections below).
style	Inline styling rules – used to apply styling without using a separate CSS definition. Note that it's advisable to separate structure and styling, so use of this attribute is deprecated for all intents and purposes. (See CSS section below.)
title	Text to display in a tooltip when the element is hovered-over.

There are other standard attributes, but only four, and they're used exceedingly infrequently. Note that there are also event attributes (see JavaScript section below).

Element types

Now that you've learnt all the XHTML elements, how to use them, and their attributes, you might think it's all over. This is not true; XHTML has a final surprise for you.

As you might have guessed, you can't put any element inside another. There are rules. The basic rule is that of block-level and inline elements. Every XHTML element is either a block-level element, or an inline element (with a few exceptions, which are beyond the scope of this tutorial, but they don't behave particularly differently anyway.) Block-level elements may contain either other block-level elements or inline elements. However, inline elements may only contain other inline elements.

Examples of block elements: div, p, body, ul, li

Examples of inline elements: span, h1, a, strong, em

Examples of other elements (not so easily classifiable): html, head, style, script, table, tr, td

Example

What follows is an example XHTML document, utilising all of the above principles:

CSS

CSS (Cascading StyleSheets) is the language used to style and position elements in a webpage. The advantage of separating content and structure from style and layout is that if, for example, you have a separate CSS file (i.e. the CSS is not embedded into the XHTML), you can easily apply a standard style across a whole website, without duplicating the CSS over and over again (which would inevitably lead to omissions, errors, and maintenance problems).

CSS is a simple language, consisting of rules, which contain various properties; the individual parameters for styling an element.
The basic format of a rule is as follows.
The selector defines which XHTML elements/classes/IDs the properties in the rule are applied to, the property is the predefined name of the property, and the property-value is the value assigned to the property (the allowed values vary from property to property). Note the spaces, colons and the semi-colon at the end of the property line.

There are several types of selector defined by the CSS 1 standard, which we will cover here. There are also several new selectors defined by both CSS 2 and CSS 3, but they are beyond the scope of this tutorial.

The most basic selector is the type selector, and it selects all the XHTML tags in the markup of the specified name.
The CSS above would apply the specified properties to any <p> or <div> element in the page.

Another basic selector is the class selector, which selects all XHTML tags with the specified class attribute value.
This example applies the specified properties to any tag which has a class of warning, or any <span> tag which has a class of timestamp. Note that you can combine type and class selectors together (as in the second rule in the above example), to produce a class selector which only applies properties to tags with the specified class, that also are of the specified tag name.

A little aside explanation about the XHTML class attribute is probably required here. As mentioned in the XHTML section above, it is a standard attribute, and as such can be applied to any element. It should contain a space-separated list of CSS class selector names to be applied to the tag. Usually, however, only one class selector is listed in the class attribute.
In that example, the <span> tag has two CSS classes attached. However, it should be noted that when naming CSS classes, you should name them for their function, rather than for their appearance. This is for maintenance considerations: if you name a class red, then change the colour to blue, you'd have to rename it, and change all the references to it, or leave it as a mess.

ID selectors are another basic selector type, which apply properties to elements based upon their ID attribute (for more information on the ID attribute, see the JavaScript section below).
Note that this rule should (in theory) only be applied to one tag in the entire page (if at all), as the ID attribute of any tag should be unique. Due to this, the ID selector isn't used as frequently as other selectors, and when it is used, it is usually used for basic page layout rules, such as positioning the title, main body, and menus. Note also that ID selectors can be coupled with type selectors, as with the class selector.

The final basic selector is the descendant selector, which applies properties to specific tags, but only if they are a descendant of another specified tag (or tags). Note that it applies the properties to the final tag in the sequence (i.e. the right-most tag in the selector).
This example applies the specified properties to any <a> tag which is beneath a level-three heading (<h3>).

Now that the basic selectors have been covered, we move on to properties and property values. A property can only accept one out of a list of predefined values. Some values are variable (such as widths, and other numeric values), but most are just text.

Some commonly used properties are listed below…

Property	Description
background	The background colour and image.
border	The border; a line (of specified width) that borders (in a box) the specified element.
display	Used to alter the display mode of the specified element (i.e. change it from a block-level to an inline element).
position	The mode with which to place the element.
height	The height.
width	The width.
font	Font options and configuration.
list-style	How to layout and draw a list.
margin	The margin options: the space around the outside of an element separating it from other elements (think of it as a “moat” for an element).
padding	The padding options: the space on the inside of an element (between the border and the content – think of it as the cavity in a cavity wall).
bottom	The space below an element, and above the element's parent's border.
left	The space to the left of an element, and to the right of the element's parent's border.
right	The space to the right of an element, and to the left of the element's parent's border.
top	The space above an element, and below the element's parent's border.
color	The colour of text.
text-align	The horizontal alignment of text.
text-decoration	Decoration applied to text, such as underline.
text-indent	Indentation applied to the first line of text.

Note that most of these properties can be split up into separate properties (i.e. margin can be split up into margin-left, margin-right, margin-top and margin-bottom).

All these properties are no use without property values. Although most elements only accept values from a property-specific predefined list, some elements accept more general values, such as pixel or percentage measurements.

Pixel measurements should generally be used for fixed-size objects, which are usually encountered when doing the basic layout of a page.
Percentage measurements are much better to use, however, as they allow dynamic resizing of page layout if the browser window is resized.

There are other general property values, but they are beyond the scope of this tutorial.

The final part of the CSS jigsaw is inheritance, or cascade. This is one of the main features of CSS, and gives it power and flexibility. The basic principle is that properties applied to one tag are automatically applied to any descendant tags of that tag (with a few exceptions for sanity's sake). So, for example, if you had a rule that applied a red text colour to an element, that element's descendants would also have red text, unless they had rules applied to them to override this.

Cascade is actually a variation of inheritance, on a larger scale. Specifically, it is the inheritance of rules in the hierarchy of stylesheets. Although only applicable for very large sites, it is important to know about: a stylesheet can import another stylesheet using something called the '@import' rule. Cascade is when the rules and properties from the first stylesheet cascade into the second stylesheet, and are applied to elements unless overruled.

JavaScript (advanced)

JavaScript is the final piece in the web development puzzle. It allows dynamic, event-driven, interactive functionality, and is the prime component of emerging technologies such as Ajax.

It would be pointless to go into a detailed explanation of JavaScript and how to script in it, as all the JavaScript a developer could ever require is available online already.
However, it is useful to be able to understand roughly what some JavaScript does, and the concepts behind it.

JavaScript is a client-side scripting language; the web server sends the raw JavaScript to the client's browser, which goes through it, performing the specified operations. It is very fast, and can manipulate a webpage in microscopic detail.

JavaScript generally consists of function s, which contain lines of code.
Functions have to start with the keyword function, then the name of the function, and the arguments required to be passed to the function in brackets. Following this should be the lines of code in the function, surrounded by curly brackets.

The lines of code themselves have to follow strict rules (which are beyond the scope of this document), and have to be terminated with a semicolon.

JavaScript is most powerful when applied to the DOM – the Document Object Model, which is a way of accessing the properties and attributes of every node in the document tree of an XHTML (or XML, etc.) page. You don't need to know about how to use the DOM in JavaScript, you just need to know that the DOM extensively references the IDs of XHTML elements, specified by their ID tag.

Another feature of JavaScript is its event model. You can specify JavaScript functions or code to be called when, for example, a link is clicked. You do this either via the event attributes in an XHTML document, or through event listening functions in JavaScript.

Event attribute	Description
onload	Called when the document loads. Can only be put in <body> or <frameset> tags.
onchange	Called when an input is changed. Can only be put in one of the form tags (<input>, <select>, etc.).
onsubmit	Called when the form is submitted. Can only be put in a <form> tag.
onkeypress	Called when a key is pressed (and released) and the element has focus. Can be put in any tag, with a few logical exceptions.
onclick	Called when a the element is clicked. Can be put in any tag, with a few logical exceptions.

To use these event attributes, simply put them into the tag.

You can also put more than just a function call into event attributes.

JavaScript is a flexible language, and many things can be achieved by using it. However, you must remember that styling should be left to CSS, structure should be left to the XHTML, and JavaScript should be used for interactivity.

It should also be stressed as a last point that JavaScript is not secure; if you write a login system in JavaScript that checks an inputted password against a one coded into the JavaScript, anybody can just view the source of the JavaScript using their browser, look through it, and extract the password with ease. This goes for other similar situations as well, such as quizzes; the answers, passwords, or any other potent information that should be kept secret. It should be stored, processed, and handled exclusively on a server!

Online tools and references

General web platform references

• http://webplatform.org
• http://w3.org
• http://caniuse.com/
• http://webdesign.about.com/
• https://teamtreehouse.com/

XHTML tools/references

• http://www.yourhtmlsource.com/
• http://www.html.net/
• http://www.tizag.com/
• http://www.davesite.com/webstation/html/
• http://www.w3schools.com/html/default.asp
• http://en.wikiversity.org/wiki/Web_design

CSS tools/references

• http://net.tutsplus.co…easy-to-understand-steps/
• http://www.yourhtmlsource.com/
• http://www.html.net/
• http://www.tizag.com/
• http://www.w3schools.com/css/default.asp
• http://www.blooberry.c…dot/css/propindex/all.htm
• http://www.westciv.com…e_master/house/index.html
• http://www.alistapart.com/
• http://enjoycss.com/start/
• http://www.skybound.ca/
• http://www.layerstyles.org/builder.html
• http://foundation.zurb.com/
• http://getbootstrap.com/
• http://engineering.app…2/11/16/css-architecture/

JavaScript tools/references

• http://www.tizag.com/
• http://javascriptkit.com/
• https://developer.mozi…en-US/docs/Web/JavaScript
• http://www.devguru.com…gies/javascript/home.html
• http://www.w3schools.com/js/default.asp
• https://developer.mozi…API/Document_Object_Model
• https://jquery.com/

Some cool effects:

• http://www.smashingmag…ul-javascript-techniques/
• http://www.turnjs.com/
• http://www.chartjs.org/
• http://inorganik.github.io/countUp.js/
• http://www.zachleat.co…b/bigtext-makes-text-big/
• http://freqdec.github.io/slabText/
• http://tympanus.net/Tutorials/3DHoverEffects/
• http://isotope.metafizzy.co/

Miscellaneous

• http://uitest.com/
• https://dev.twitter.com/cards/getting-started (you may want to implement this yourself if you use Twitter)

See also

• Themeing your site
• Designer themes, implementing a clean-room design
• Tempcode programming
• Helping improve site accessibility for disabled users
• Browser version requirements
• How the Internet actually works
• Composr site structure
• Using Chrome development tools to help with themeing

Feedback

Have a suggestion? Report an issue on the tracker.