Developer Tools

1: Programming Editors

One of the most important tools for web development is a good text editing program. While Notepad will do for some basic work, serious web development work requires something with a bit more in the way of tools provided, and is generally referred to as a "programming editor". Note that this is a very different piece of software than a "word processor", or even what would be called a "wysiwyg" web page editor. Programming editors do not present you with a display of your finished page, they always focus on the code, and making that code easy to edit and read, rather than hiding it from you.

Here is a list of useful features to look for in a programming editor:

1. Syntax Highlighting: Preferably for multiple programming languages. (ie: HTML, CSS, Javascript) This allows you a clear view of where the various parts of your page/program are located, and makes it easier to find things you want in the page.
2. Line Number Indicator: This is actually very important - when using the XHTML and CSS validators, they will tell you the line number on which an error has occurred. If you can not find that line, you will have a hard time fixing that error, and using the cursor down key to count off 143 lines gets tiresome very quickly.
3. Multiple File Opening: Much like tabbed browsing is a very common feature that no self-respecting web browser is without, tabbed editors which allow you to open multiple files are a very useful tool. This will save you from having 30 notepad windows, and not being sure which of the three "index.html" windows you have is actually the correct one to be saving. Often in tabbed editors, the tabs with altered files that have not been saved yet will be highlighted.
4. Spelling Checker: Part of effective communication is correct communication - that includes spelling words properly. Most modern programming editors include an option to check spelling, or even the ability to turn on "Autocheck", which will have the editor automatically underline any incorrectly spelled words.
5. Good Search/Replace tools: Occasionally you will need to change something that you have done very frequently in your files. Perhaps you changed the name of a class and need to fix all of the places you used it, or perhaps you've made the same XHTML error 50 times in the same file, and need to fix it. Search and Replace can be your best friend in situations like that, as rather than needing to look through the file by hand and find all of the places with <li class "potato"> so that you can add the missing =, you can just use Search and Replace to get them all at once.
6. Automatic Indenting: Code that is properly indented is much easier to read, and thus much easier to go back and edit later on. Some of the editors out there will not only track your indentation, but when you close a tag or structure that has been indented, they will reduce the indentation for you automatically as well.
7. Structure Tracking: Some editors will also be able to help you locate where the matching opening or closing brace is for the one the cursor is currently on top of. To use this feature in the editors which have it, simply place the text cursor on the opening or closing brace, and the matching brace will be highlighted. This can be very useful when writing large programs in JavaScript.

Below is a screenshot of a programming editor in operation. Note that of the three tabs, the first one is marked with a *, indicating unsaved changes. Also, the text cursor's current position in the file is indicated at the bottom of the window, and the various types of code in the file are highlighted for clarity.

Many different programming editors are available for different operating systems. Here are a few which you might find useful:

• Notepad++ and Crimson for Windows
• TextWrangler for Mac (Use nano in a terminal window if TextWrangler is not installed)
• Bluefish and gedit for Linux do syntax highlighting, nano works in linux as well.
• Touchqode for Android

On a similar note, there are a few editing programs you should avoid at all costs when making web pages. On Apple's OS/X operating system, there is a built in editor called "TextEdit", which will corrupt your .html and .css files, and render them unusable by adding invalid characters between every actual character in your file. While it is possible to re-configure TextEdit to not damage your files, it's very difficult, and will not correct files that are already corrupted. The best thing to do is just download TextWrangler to use on your Mac. Here's an example of what a TextEdit corrupted file looks like when viewed in the browser:

Windows users on the other hand, may feel tempted to use either WordPad, or MS Word, or some other word processing program. This, unfortunately, will also cause problems. First, MS Word (and other Word Processors like OpenOffice Writer) contains a "Save As HTML" function - this does NOT save the code you have typed in as a .html file - instead, it creates an HTML coded file (which is likely to contain a large number of errors when run through the validator), which will display your file exactly as you saw it in the word processor's window, or as close to it as the program is able to manage. As a practice exercise, open up a word processor, type in a short HTML file, then "save as HTML" from the browser. Look at the size of the resulting file, and compare it to your hand-coded HTML file's size if you save it in a text editor. Open the file produced by the word processor in an actual text editor, and you'll see something like this:

The above example is the start of an html file produced by MS Word - the only contents of the file were the word "test" - the resulting file was over 20K in size. A hand coded file to do the same thing would be less than 100 bytes.

Finally, the last reason you want to avoid using a Word Processor to build your web pages is something called smart quotes. Smart Quotes are the fancy right and left-facing quotation marks that you see in a word processor to make your text look nice - the problem is, they are not actual ASCII quotation mark characters (ascii value 32), but instead are a special Unicode character representing the fancy directional quote you see in the word processor (usually character number around 221 and 223, but it varies). Since it isn't really a quote, it doesn't work for HTML, CSS, or JavaScript programming, and it will also cause an error in the XHTML validator for every Smart Quote in your file. The only way to then fix those smart quotes is to go through your file in a proper text editor one line at a time, and delete every Smart Quote, replacing it with a real one.

2: Bookmarklets

Bookmarklets are small bits of javascript code built into a bookmark in your web browser, that allow you to run javascript code on a page that has been loaded in the browser. The javascript code in the bookmarklet will run exactly as though it was part of the page itself. To build a bookmarklet, you need to follow 4 steps:

1. Develop some javascript code that does the task you want - usually in a regular script tag on a page. This code must be able to run in it's entirety, so if a function is needed, that function must be part of the code.
2. Modify that code so that it is able to be formatted all in a single line of text. (ie: delete all newline characters, and make sure it still runs.)
3. Place it in the href= attribute of a link, with javascript: at the start.
4. View the resulting page in a browser, and bookmark the link you created.

As an example, we can create come code that pops up a window that says "Hello World" - the code is very simple, just window.alert("Hello World");, so that's steps 1 and 2 already done. Next, we need to embed that code into a link, like this:

This will create a link that looks like this: [Hello World] which, when clicked on will pop up a "Hello World" window, and which we can then bookmark and have this work while any other page is loaded.

Most bookmarklets are considerably more complicated than the above code, but they are also more useful. Here are a few example bookmarklets:

• [Cookies] This one will give you a popup window displaying a list of all cookies associated with the current web page.
• [validate html] This one will allow you to send whatever page you are currently viewing (as long as it's actually on the internet) off to the W3 Consortium's HTML validator.
• [Validate CSS3] This will send the page you are currently looking at to the W3 Consortium's CSS Validator, and will force it to use CSS Level 3 as the validation ruleset. Again, this will only work properly with files that you have already uploaded to the internet.
• [invert lightness] Less practical, but a good demonstration of things that can be done, this bookmarklet will scan through your entire file, and alter the CSS to invert the brightness of everything in it (except images, which are not controlled through CSS).

A few places you can find pre-made bookmarklets:

• Squarefee.com - source of the "Invert Colors" and "Validate html" examples above.
• Bookmarklets.com - provides a variety of tools, and lists browser compatibility for each.

3: Using and Interpreting Validator Information

The W3 Consortium provides a valuable resource to web developers in the form of a pair of validation services. First, an (X)HTML validator, which allows you to verify that your HTML files have been coded properly in the HTML version you wanted to use, and second, a CSS validator which allows you to verify the correctness of your stylesheets, and any CSS in your HTML files.

The XHTML Validator

When using the XHTML validator, there are four important things to keep in mind:

1. The validator will validate your document against the DOCTYPE at the start of your file - if you set the wrong DOCTYPE, it will check against that instead. Remember that for our class project, you should be using XHTML 1.0 Transitional. If your document validates properly, you will see a green bar with the text "This document was successfully checked as XHTML 1.0 Transitional!" inside of it. If your document did not pass validation, a red bar will appear which says "Errors found while checking this document as XHTML 1.0 Transitional!", and the "Result" entry beneath it will indicate the number of errors found.
2. The validator will tell you where the errors it found are, to the best of it's ability to process. This means that sometimes an error will appear to be in one location, when it is actually in another. The most common cause of this is if you forget to close a tag such as the <p> tag - since you are not allowed to place a paragraph inside of another paragraph, the next opening <p> tag will register as an error. The typical message for this will be "document type does not allow element "p" here;" (with a red "x" icon marking it as an error), and likely further into the list of errors will be another error stating "end tag for "p" omitted, but OMITTAG NO was specified". After such a message will be an information line (with a blue "i" icon beside it) indicating where the unclosed tag began. In this case, fixing the missing closing </p> will fix both errors at once.
3. ALWAYS fix the first error first, and re-validate. As mentioned, sometimes fixing one error will correct many other errors at once. The only exception to this is when you see a list of the same error being repeated many times - in that case, it's safe to just fix all of them at once.
4. The validator will only check the page you send to it! If you have more than one page to check, you need to send each one individually to the validator, as it will not crawl your site and validate every page for you.

Here are a few common error messages, and what they typically mean:

element "P" undefined

The tag being indicated does not exist in the version of HTML being validated for. First, check to make sure the DOCTYPE was sending the correct version, then check to make sure the tag name is spelled correctly and in lower case letters. Here's an Example of this problem, being caused by the <p> tag in question being capitalized.

document type does not allow element "[whatever]" here; ...

This means that the tag indicated is not allowed to be placed inside of whatever tag you have placed it inside of. Most often, this is the result of forgetting to close a tag earlier in the file, and will usually result in another error further down in the page which reads "end tag for "[whatever]" omitted, but OMITTAG NO was specified". An example for both of these messages can be found here.

end tag for "[whatever]" omitted, but OMITTAG NO was specified

This means you forgot to close a tag somewhere in your file. This error message is always followed by an information message (marked with a blue diamond-shaped "i" icon) indicating where the validator believes the tag that is missing it's closing starts, which will say "start tag was here". The previous entry's example works for this as well.

required attribute "[whatever]" not specified

This means that the tag indicated in the error message requires the presense of the attribute listed. Adding in that attribute will correct this error.

an attribute value literal can occur in an attribute specification list only after a VI delimiter

This, and messages similar to it most often occur because you forgot to include the "=" after the name of your attribute in an XHTML tag. Other times it can mean you forgot the quotation marks, or to include the value of the attribute at all. (All XHTML attributes MUST be included, and MUST have quotes.) This error type, and the previous one can be found in this example.

The XHTML validator can be found at http://validator.w3.org/, or you can use the bookmarklet in the previous section to be able to automatically send the page you are viewing to be validated.

The CSS Validator

As with the HTML validator, the W3 Consortium also provides a CSS validator, which can help you find errors and problems in your web site's stylesheets. It functions very similarly to the HTML validator. When a page validates properly in the CSS validator, you will see a green bar which reads "Congratulations! No Error Found.". You should note of course, that "No Error Found" is not the same thing as "your page has CSS in it" - a page with no CSS at all will pass validation perfectly, as it only detects when there are errors. When it does find errors, a red bar reading "Sorry! We found the following errors ([number here])" will appear, with the number given representing how many errors were located.

When submitting a CSS file or web page for validation, you should always remember to set the "Profile" being used - to do this from the CSS Validator site, click on the "more options" link, and make sure your Profile is set properly. (For 60-270, you may use any of CSS levels 1, 2, 2.1, and 3, but grading will be done in CSS level 3.)

Here are a few typical errors:

Parse Error [something that didn't parse here]

This means that something in your stylesheet was completely not expected as part of a CSS file.

Property [whatever] doesn't exist

The property being indicated doesn't exist in the level of CSS you are validating against - first check which "profile" you are using, and then check the spelling of your CSS property name. Note that CSS property names are not case sensitive.

Value Error : [whatever] only 0 can be a length. You must put a unit after your number : [numbers]

You forgot to include a unit on your CSS property - the only measurement value that can be used without a unit on most CSS values is 0.

Value Error : z-index [whatever] is not a z-index value : [the value used]

You used a unit on the z-index property's value. z-index is a special CSS property in that it is the only CSS property which requires a number value, but can not have a unit.

The CSS Validator can be found at http://jigsaw.w3.org/css-validator/, or you can use the bookmarklet in the previous section to be able to automatically send the page you are viewing to be validated as CSS level 3. Remember for your project that you need to validate all of your XHTML files, as well as any .css files you are using!

4: Firefox's Web Developer Tools

The Firefox browser is typically the most commonly used browser for web developers for several reasons, the largest of which is the number of built in tools it provides to assist in the development process. (You can confirm this by looking at the browser usage statistics at W3 Schools (a developer resource site) compared to the usage statistics provided by Nearly anyone else.) Older versions of Firefox provide only a Javascript/CSS "Error Console", but newer releases also include other tools.

To access the Error Console in older Firefox versions, you would enter the "Tools" menu, and select "Error Console". In newer (ie: version 6 and up) releases, this console is located under the "Tools" menu in the "Web Developer" sub-menu. A typical Error Console will look like this:

An advantage of the Error Console is that it allows you a quick and easy place to type in short bits of JavaScript Code to test them, as well as providing feedback on your page.

Newer tools have also been added to the most recent version of Firefox under the "Tools->Web Developers" menu, including a "Web Console", which provides more detailed information about what your page is doing, including in the stylesheets, javascript, and other places. It provides most of the information from the error console, though in a slightly different format, as a separate "frame" region at the top of the browser window. As with the Error Console, you can enter JavaScript to be processed in a command prompt, but other commands can be used as well. (Type "help" and hit enter for more information on that.)