Being a web developer
Is as awesome as Chewbacca riding a squirrel, fighting Nazis with a cross bow.
- @codepo8
Being a web developer
Is as awesome as Chewbacca riding a squirrel, fighting Nazis with a cross bow.
- @codepo8
This little book is to aid a shared understanding of front-end development best practice at PUP.
It's to help us deliver high quality content that works better, reaches more people - not only in today's browsers & devices, but in tomorrows.
Our own user logs are almost all that matters in deciding which browsers we officially support.
However, if we give our clients good reason to upgrade or switch to a newer, more standards compliant browser our jobs will be easier and our work higher quality as we won't need to be spending time fixing bugs in older browsers.
No. A page needs to serve its purpose in function and not appear broken.
It's not about browsers, it's about serving the users of our software by delivering content that is valuable to them.
The latest versions of all modern browsers, IE6-9 & top-level modern mobile browsers Opera & Safari.
Install the latest versions of these browsers from U:/
IE6-8 are currently best tested on VM's pageuptest-ie[6,7,8] or run your own VM's.
You can test Opera Mobile from your desktop machine - You can also introspect Opera mobile inside a phone using Opera Dragonfly.
The iPhone SDK comes with Mobile Safari but is mac only, there's plenty of iPhones and iPads around the office. Make sure error reporting is enabled in Safari settings.
If you write front-end code you will need to test in all of these browsers to ensure it looks ok and functions as it should.
Mobile is hugely important today, we will need to review our mobile support regularly and follow the industry and our user-base. It will soon be more important than the desktop.
Writing front-end code without considering mobile doesn't cut the mustard, it cuts the cheese.
@ppk writes about mobile at http://www.quirksmode.org/mobile/
To "Write once, deploy everywhere" was the great goal of the web standards movement. Thanks to the efforts of web designers & browser vendors supporting web standards, browser compatibility is far easier today than it ever has been.
The W3C and WHATWG are groups that debate "What the web should be", argue over APIs and publish standards for browser vendors and developers to implement. These are open groups, anyone interested enough in them can contribute.
Following changes to the specs and listening to developers& designers is important. Follow changes at @w3c @whatwg
People to follow @paul_irish @brucel @nimbuin @thecssninja @leaverou @slicknet @stubbornella
Read from great authors Dan Cederholm Andy Clarke Jeremy Keith
Join a forum SitePoint
The rendering engine in a browser reads HTML, CSS, other standards like XSLT, SVG, and paints the pixels on the screen.
Understanding the differences and quirks in these 4 rendering engines will reduce the amount of time needed to test layout & rendering.
HTML is the unifying language of the World Wide Web. Using just the simple tags it contains, the human race has created an astoundingly diverse network of hyperlinked documents, from Amazon, eBay, and Wikipedia, to personal blogs and websites dedicated to cats that look like Hitler.
- @adactio
HTML gives meaning to content so that browsers and devices can then give that meaning to a user. e.g.
If it's a heading use a heading.
If it's tabular data use a table.
If it's a list of links then make it so.
HTML should work without the presence of CSS or Javascript.
The content should be accessible, form submissions should work, the HTML on it's own should have value.
A good way to test the quality of the HTML is to disable images, CSS and Javascript and see how meaningful it is.
If we write our HTML like this when we get around to redesigning the UI, the HTML doesn't have to be rewritten.
HTML5 is the version we use, but HTML versions don't really matter. Browsers understand the tags they support, regardless of the doctype / version we validate against.
A doctype is necessary to force browsers to render in standards mode and prevent quirks mode head aches in ie.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>I ♥ HTML</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<h1>HTML5 <abbr title="For The Win">FTW</abbr>!</h1>
<script src="script.js"></script>
</body>
</html>* Lower case tags, double quote attributes.
We really should be thankful that non-ie browsers have such great consistency, I have never needed a CSS hack for a non-ie browser.
Without IE, web development would just be too easy.
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">When testing your work in IE start with the latest version and work your way back.
<!--[if lt IE 7 ]> <html class="ie6"> <![endif]-->
<!--[if IE 7 ]> <html class="ie7"> <![endif]-->
<!--[if IE 8 ]> <html class="ie8"> <![endif]-->
<!--[if (gte IE 9)|!(IE)]><!--> <html> <!--<![endif]-->If we replace our html tag with the above we can use classes to deliver styles to specific versions.
e.g. "float to fix" a bug with #myElement in ie6
.ie6 #myElement { float: left; width: 100% }The single most important thing you need to know about fixing bugs in IE! Giving an element "Layout" will fix 99% of ie rendering bugs, as if by magic. The other 1% will most likely be related to position: relative; or floats. Use "zoom: 1" as a trigger for whatever ie versions need it.
.ie6 #myElement, .ie7 #myElement { zoom: 1 }http://www.sitepoint.com/forums/2041209-post24.html
Deliver specific styles to different devices, they can test for things like:
You can optimise styes for different devices
@media only screen and (max-device-width: 480px) {
/* hide header and footer on small screen devices */
#header, #footer { display: none }
}
@media only screen and (max-width:800px) {
/* linearize navigation under 800px */
nav, nav li, nav a { float: none; width: 100% }
}See http://colly.com/ for a great example
The viewport meta tag is also needed to instruct a mobile device to keep the viewport to the amount of pixels it has on the screen i.e. prevent it from zooming out like a desktop version.
<meta name="viewport" content="initial-scale=1.0, width=device-width">
Great article on viewport and media queries http://dev.opera.com/articles/view/an-introduction-to-meta-viewport-and-viewport/
Hold on there Bald Eagle. Why are we always in such a hurry?
- @malarkey
Javascript sits on top of the HTML and CSS foundation and enhances the user experience & behaviour of the page, that's it.
Is an important concept, it means making a page work without a feature that may / may not be supported first. If a feature is supported the user gets the benefit, if not - it still works.
If we treat javascript like this it makes our code higher quality and prevents atrocities like:
<a href="javascript:myKillerFunction('sucks', true);">Click here</a>It means that if something breaks the page can continue to work without the enhancement.
Progressive enhancement also aids maintainability, keeping the javascript separate means there's no need to search all documents for function calls.
Because we are not cluttering the global scope we can have short awesome names for our methods& variables.
var Toggler = {
open: function() {},
close: function() {},
toggle: function() {}
}
Add only the absolutely necessary parameters as arguments, put all optional parameters into an options hash.
function circle(x,y,radius,options) {
options = options || {};
}
Controls are initialised via a container element with class="init" e.g. If you're initialising stuff onload use this.
<div class="init" data-control="AwesomeToggler">
On load this would pick up the above element and init the AwesomeToggler Control, there's two init functions that can be defined, "initOnce" is helpful for degelated events, "init" will run for each instance of the control on the page.
Controls.AwesomeToggler = {
initOnce: function() {
$body.delegate('.toggler .trigger', 'click', function() {});
},
init: function() {
alert('TOG');
}
});
If you want to use a library you must have read it, understood it, agree with it, and not be able to write a better one on your best day of coding.
- @sentience
Frameworks are not evil, they save time, fix cross browser compatibility issues and make us think in new ways. But, they do add overhead so before we jump in bed with them, see above.
We should only have one "Core" javascript framework, additional libraries for specific tasks not handled by the Core framework can be added if they meet the above requirements.
e.g. Effects & animation, SVG, Charting, Shims(Add support for features that aren't natively supported by some browsers)
Open source frameworks are the product of really interested people. Interested people create great stuff.
Schools out, but keep learning jquery mootools prototype scriptaculous raphaël
Gain heroes Paul Irish, Thomas Fuchs, John Resig, Dmitry Baranovskiy
Create something great and share it with me.
The YUI team has done as much research into front-end performance as anyone.
Here's a cut down version of the YUI best practices for performance, reading the full article is highly recommended though. http://developer.yahoo.com/performance/rules.html
Follow @souders if you're interested in web performance.
Combine all scripts and stylesheets & use image sprites to reduce the number of round trips to the server.
We should move all referenced files css, js, images etc. to dispersed servers like Akamai.
Putting stylesheets in the <head> allows the page to render progressively.
<script> tags block parallel downloads, put them last so other resources can be downloaded first.
Expressions are a way of running javascript as part of a CSS rule in ie6-7. They can be used to fix support for non-supported features - like fixed positioning. The problem is they are constantly evaluated which can really slow down the page.
.ie6 .fixed {
top: expression(0+((e=document.documentElement.scrollTop)?e:document.body.scrollTop)+'px');
}The Cache is our friend. The only exception would be pages with one view per session which may benefit from inline script.
We should use a minifier like JSMin, YUI Compressor or Closure Compiler to reduce the file size our CSS & js.
Removing variables from the global scope can get better results from compression as the names can be shortened as they can't be accessed outside of their enclosing functions.
var canIBeShortened = 'no';
(function() {
var willMyReallyLongVariableBeShortnedByTheMinifier = 'yes';
alert(willMyReallyLongVariableBeShortnedByTheMinifier);
})();// Minified
var canIBeShortened="no"function(){alert("yes")})()
Slows down the user experience.
Smaller pages with fewer elements are faster to traverse and modify.
Costly even if blank because they are new windows, they also block the page's onload event.
Look through monitoring and remove these unnecessary trips to the server.
Transferred in the page headers, remove unnecessary cookies, keep small, set an Expires date.
Save references to elements in variables to prevent lookups, innerHTML is generally faster than DOM, avoid fixing layout with js.
Minimise the amount of event listeners in a page with Event Delegation.
Prototype's "on" function registers an event listener on the body element once to handle all the occurrences of that event in the page. e.g.
<body>
<p>
<a href="#">
<span>linky</span>
</a>
<a href="#">
<span>linky 2</span>
</a>
When a <span> element is clicked the event moves up through the tree, all the way to the body where the event handler can find which <span> element fired it.
If you have 100 elements in the page you want respond to click events, Event delegation will save you.
Learn http://icant.co.uk/sandbox/eventdelegation/
Filters are "special features" in CSS for IE, they can slow down the page though, so use sparingly.
Batch operations like the YUI image compressor, ImageOptim or sprite generators should be used to make the images as small as possible whilst keeping their quality.
The iPhone won't cache anything bigger than 25K uncompressed.
Go to town, but keep backwards compatibility and progressive enhancement in mind. Making pages look identical is not the aim, just don't rely on an HTML5 / CSS3 feature for an important feature of a page.
CSS3 can be used, however with the majority of our users on ie6 still we should treat CSS3 features as visual rewards for capable browsers and things which save us lots of time, like gradients and border-radius. Use all vendor prefixes in alphabetical order with the prefixless version last.
#slides img:hover {
-moz-transform: scale(1.6);
-ms-transform: scale(1.6);
-o-transform: scale(1.6);
-webkit-transform: scale(1.6);
transform: scale(1.6);
}
HTML5 can be used, consider using shims to add support for more of our users and test the performance impact.
Learn http://diveintohtml5.info/ http://html5doctor.com/
Maintaining your own pages with test cases of standards being developed is the best way to keep up to date. It helps you to really learn how to use them, if you don't practice you quickly forget what you learnt.
Accessibility matters, it matters to those trying to use our software with a disability, it's in our contracts, it also directly relates to discrimination laws we need to know about, as well as simply being the right thing to do.
Writing semantic HTML, CSS that's flexible with layout & font-size as well as using Javascript to add keyboard support go a long way in making a web app as accessible as possible.
It's not always difficult to make something accessible. Always ask what you can do to improve a pages accessibility.
Supporting blind users of screen reading software like JAWS / NVDA is the obvious case but there are others. Use a sensibly sized default font and provide alt stylesheets for different font sizes. Use enough contrast between colours and foreground / background to enhance readability.
Use a screen reader, it's the only way to gain a good insight into what using our software is really like for blind users.
Keep tables simple and avoid nested headings. Using th elements for heading cells with appropriate scope is the first step for accessible tables.
<table>
<tr>
<th scope="col">Name</th>
<th scope="col">Age</th>
<th scope="col">Birthday</th>
</tr>
<tr>
<th scope="row">Jackie</th>
<td>5</td>
<td>April 5</td>
</tr>
<tr>
<th scope="row">Beth</th>
<td>8</td>
<td>January 14</td>
</tr>
</table>
Linking labels to inputs with the for attribute is the first step for accessible forms.
<label for="email">Email</label>
<input id="email">Learn
http://www.456bereastreet.com/archive/200410/bring_on_the_tables/
http://www.webstandards.org/learn/tutorials/accessible-forms/
Most of us can appreciate using keyboard short cuts for navigating forms, people with low mobility will appreciate being able to use our software without a mouse far more than this.
This one is not as obvious as the other points, but is as valid. A consistent UI will help all our users be able to access what they need to. It's rare to find a web application of our size and complexity that doesn't have a style guide, let's make one.
We have focused on WCAG 1 Level A compliance in the past, WAI ARIA is a fairly recent addition and focuses on the moving parts of a web app. The ARIA attributes can help explain dynamic changes to the page with javascript to users of assistive technologies.
http://dev.opera.com/articles/view/introduction-to-wai-aria/
People to follow @jkiss @stevefaulkner @vick08
Let's build something awesome and be home for dinner.