It isn't that difficult to create a modern website based on current web standards. If your website was built using the latest technology, your site will be super-fast, modern, clean and responsive.
Everyone wants their website to cost less, work better, and reach more people in today's browsers, screen readers, and wireless devices. The inescapable technological advancements that are happening as we speak are breaking websites all over the internet. A modern website built using the latest coding practices ensures that your website will function properly across all devices and help individuals with disabilities who are using special devices to access and interact with the internet - and stand the test of time.
You don't have to spend money on trendy, short-sighted, proprietary solutions that will end in disaster. No one can afford to piecemeal a website that will ultimately break sooner than later.
Coding several different stylesheets might have seemed like a great idea at the time, but it is not a rational solution to problems that are continuing to plague site owners and builders.
WaSP (www.webstandards.org) advocates standards that reduce the cost and complexity of site creation and ensure simple, affordable access for all. Today, every browser supports web standards as a matter of course. They work with the designers of development tools such as Dreamweaver. You can find a myriad of web standards educational tools and this information can be found in most languages today.
Apple's latest WebKit based Safari browser, which powers the iPhone's web browser, Mozilla powered Firefox, Opera, the WebKit based Google Chrome, and Microsoft Internet Explorer 7+ understand and correctly support XHTML, CSS3, JavaScript, and the DOM.
*Internet Explorer 6 does not support many of the latest web standards, and we can only hope that everyone has moved passed this version of IE. Developers know that we can fix IE6 to some degree, but there comes a time when you have to move forward and not look back. We've stopped overkill fixes because newer phones are equipped with the latest browsers and it just doesn't warrant the extra time and expense anymore to work out ALL the fixes needed for IE6 to view properly.
JavaScript creates action. This language has given us the ability to create action! In a perfect world, browsers perfect their support for every single standard. Considering that most software doesn't come out bug-free, and standards are sophisticated and complex, cross-browser support is actually pretty solid enough that we do develop using the latest standards. HTML5, more accessibility, CSS3, structured markup and deeper DOM and JavaScript function calls are becoming the progressive-enhancement that is pushing the internet into the future. All the big companies such as Apple, MSN, Wikipedia, and WordPress have embraced web standards. Of course, they don't always achieve perfect validation or pure semantic markup, but a trained developer can make these markup fixes very quickly, and let's face it, modern browsers are lenient.
More than 90% of all websites are obsolete. They might look good on desktop browsers, but outside of that, the symptoms of decay are starting to appear. Carefully constructed layouts have begun to fall apart, and expensively engineered behaviors have stopped working. As browsers evolve, site performance continues to deteriorate.
Modern browsers are not merely newer versions of the same old thing. They differ fundamentally from their predecessors, and in many cases, they've been rebuilt from the ground up. They have a new job: to comply as well as possible with the web standards. As the newer browsers comply with web standards, they are becoming increasingly intolerant of broken code and markup.
We believe in "write once, publish everywhere". It isn't wishful thinking. We are proud of the fact that our mission statement is "Because it matters". Our mission follows some basic rules:
Control layout, placement, and typography in desktop browsers while allowing users to modify the presentation to suit their needs.
Develop and support sophisticated behaviors that work across multiple browsers and platforms.
Comply with accessibility laws and guidelines without sacrificing beauty, performance, or sophistication.
Redesign quickly - reducing costs and eliminating unnecessary work.
Support emerging devices from wireless gadgets and smart phones to Braille output devices and screen readers used by those with disabilities with one website.
Offer sophisticated printed versions of any web page.
Stay educated and ahead of the curve to always use real semantic markup.
SEO and Analytics go hand-in-hand. Believe it or not, companies do not have to spend a lot of money for SEO or Analytics. Well thought out SEO makes your website findable. Content is king. Focus on lean, keyword-rich, buzzword-free content that's relevant to your customers, and use semantic markup. Copy, CSS layout and HTML5's latest coding practices are the golden keys to findability.
Accessibility makes sure your content can be read and your site can be used by everyone, no matter what device they browse with, and regardless of physical ability. Innovation is the soul of accessibility. Accessibility is legal standard for judging and enforcing the accessibility of sites. This is great news because the world is being pushed into one single standard.
If you use standards-based designing principles, you not only make your content easy for search engines to find, it will also enable visually disabled people who use screen readers to navigate your websites content.
Screen reader users navigate web pages by tabbing from h2 to h2 and from section to section, just like sighted users navigate by visually scanning. When structuring your site semantically, pay particular attention to forms and tables. Provide keyboard access for those who are unable to use a mouse. Keyboards and assistive devices are the gateway to online user experience.
Google web crawlers look for relevancy of content when a user types in an inquiry.
Think of web crawlers as blind users - Google is the biggest blind user on the web. Dish out appropriate content, well written and well structured, and you not only serve the blind folks in your audience, you also attract millions of sighted ones.
It wouldn't be smart to exclude disabled Americans. This demographic would take up a city the size of Los Angeles or New York City. Millions!
If you think blind people don't buy products online is missing the point and the boat. Don't be blind yourself to the true nature of the audience you reject - you are still reaching the non-disabled populace this way by conforming to access guidelines and many others who would have ordered your products over the phone if only your site let them.
Section 508 requires all websites under its jurisdiction to provide "equal or equivalent access to everyone" to accommodate the visually impaired, the hearing impaired, the physically disabled, and people who have photosensitive epilepsy and it spells out what accessibility really means. This law covers computers, fax machines, copiers, telephones, transaction machines, and kiosks, as well as other equipment used for transmitting, receiving, or storing information. It also covers many websites. Section 508 became U.S. law in 2001 and applies to the following:
The bottom line is that if you design with web standards and follow the guidelines, your site should be accessible to screen readers, Lynx, mobile devices, and old browsers as it is to modern, compliant browsers. Standards and accessibility converge in agreeing that one web document should serve all readers and users. Even Flash and PDF's can now be made accessible.
Most tasks to bring a website to its best take minutes to accomplish. Simple tasks like adding a label to your web form or writing a table summary. Type a brief alt text for each image - which is a no-brainer. High level conformance is going to obviously fall under another category and will cost more. If you want to author closed captions for web videos or to caption live streaming media news feeds in real time see Joe Clark's "Best Practices in Online Captioning" . (www.joeclark.org/access/captioning/bpoc)
I highly recommend the following cited book for anyone who builds things for the internet. Web Standards is such an exciting concept that ties us all together. Where we go from here who knows, but right now we are accomplishing a great thing using Web Standards, and this book is a must have.
You can find the latest Standards and beta versions of some brilliant new concepts existing on the W3C website. Their HTML5 Validator is a great place to find semantic errors within your page. Go to http://validator.W3.org/ for the latest information.
Jeffrey Zeldman with Ethan Marcotte (2010). Designing with Web Standards, Third Edition. Berkeley, CA. New Riders.
The "box model" in CSS looks like this:
width + padding + border = actual visible/rendered width of box height + padding + border = actual visible/rendered height of box.
The border and padding values go inwards into the width/height of the box rather than expand it. Expansion of an element is always mind bending.
Block level elements - a div inside a div - the child div defaults to 100% size of the parent, without any CSS styling. If you add padding or border and declare the child to be 100% width, it will blow out of the parent from adding those values to the original width amount (default).
So that's where the border box value (as opposed to the content-box default), which keeps the styling inside the box.
html {
box-sizing: border-box;
}
*, *before, *:after {
box-sizing: inherit;
}
According to Paul Irish, the need to state prefixes for Webkit or Moz is no longer necessary, and most browsers and devices are totally onboard. The universal (*) selector works great, too, and is a great CSS tool.
article reference: http://css-tricks.com/box-sizing/related article on Box-Sizing as explained by Paul Irish: www.paulirish.com/2012/box-sizing-border-fox-ftw
Device pixels are the actual physical dots that the device screen can display. On the iPhone, this is 1136 x 640 (which one is width depends on how you're holding the device).
A display pixel, also known as a device-independent pixel, a point, or a dot, is what the browser uses to display webpages. It is also what you're using when you specify dimensions in CSS.
Depending on the zoom level, a device-independent pixel may be larger or smaller than a device pixel. You can use a ratio to show the zoom level. For example, if you zoom in to double the size of the content, the ratio of device-independent pixels to device pixels is 2:1 (two to one). In other words, display pixels are twice the size of device pixels.
You can control the size of display pixels by controlling the width of the viewport. You do this using the viewport meta tag. On iOS, the mobile Safari browser uses a default value of 980 points wide in either landscape or portrait mode. In landscape mode, the browser zooms in on the page a bit to take advantage of the larger width. The viewport size remains the same.
This 980-point-wide viewport works great if you've designed your site to be 980 pixels wide and your fonts are readable on a small screen. More often, what you see by default on iOS looks great. However, if you design your Web app to be 320 pixels wide in portrait mode, with the default viewport width (which is 980), your app won't look good and will only take up about a third of the viewport.
To display your webpage as large as possible in mobile browsers, and to take into account that different devices have different scene sizes, you need to set the viewport equal to the width of the device screen. You can do this with the simple Viewport HTML meta tag:
This tag sets the width of your viewport to the width of the device, rather than 980 points, and sets the initial scaling of your viewport to 1 - meaning that it won't be zoomed in.
The viewport meta tag has a couple of other, less frequently used properties that you might want to know about:
I hope this helps explain how pixels are viewed and used in developing Web apps. Thanks for reading!
Sometimes you take a photo that is great - minus the background. The background just ruins your picture. Photoshop's Background Eraser Tool is awesome. Here is an image that I would like to do something with, but the background has to go. Here are the steps I used to fix my awesome cowgirl's photograph while keeping her hair realistic:
You might think that using a lot of images is great - I know I do, however, you need to add imagery in an accessible way so people with visual impairments still get the information.
People surfing on mobile devices might still have images turned off because of small screens and the cost of downloading data.
Those visiting your site might be blind or visually impaired to such a degree that they cannot see our images properly.
Other visitors might be from another culture and they don't understand the icons you use.
Search engines only index text - they don't analyze images (yet), which means that information stored in images cannot be found and indexed.
It is important to choose images wisely and use them when appropriate. Always offer a fallback for those who cannot see your images. Navigation and menu issues can arise with images.
You have content images and background images. Content images (<img> element) always get an alt tag and are relevant to the paragraph or other section. If, however, an image is only being shown as eye candy, no alt tag is required, so alt="" is appropriate. CSS control offers many design options as well.
The alt attribute of image elements - your image fallback - may be necessary due to several reasons, such as the image not being available because it could not be found, loaded, or because a browser (or other user agents) does not support images. Assistive technologies read web pages out loud to their users. It is sometimes called "alt tag" when it is actually an attribute of the <img> element.
Use the title attribute if you have a lot to say about an image which, if the user has mouse capabilities and the browser is capable, acts like a tooltip popup.
The longdesc attribute allows you to link to complex data like charts and graphs. There is no visual clue that this attribute is there, but assistive technologies will let their users know there is an alternative available.
The are several image element attributes such as, width, height, src, md, units, align, alt, ismap, id, lang, and class.
HTML5 introduces the figcaption and summary elements. Figcaption acts as the optional caption or legend for any content within its parent figure element. A figcaption element must be the first or last child of the figure element.
The figure element is used to mark up any self-contained content that may be referenced from the main flow of a document but could also be removed from the primary content (for example, to an appendix) without affecting its flow. This makes it suitable for various types of content ranging from graphs and data tables to photographs and code blocks. Example:
<p>This is one of the most interesting places on earth</p> <figure> <audio src="where-are-we-going.mp3" controls></audio> <figcaption><cite>Where are we going?</cite>by Jamie Lee Jones</figcaption> </figure>The creation of the figcaption element is an important step forward for HTML5 because it reliably markups the caption for content that is best marked up as a figure.
The summary element represents a summary, caption, or legend for any content contained within its parent details element. The summary element must be the first child of a details element and if there is no summary element present then the user agent should provide its own. This is because the details element has a specific function - to markup additional information and allow the user to toggle the visibility of the additional information. Although it is not specified in the spec, it is expected that the summary element will act as the control that toggles the open-closed status of the contents of the parent details elements. Example:
<details> <summary>Technical details</summary> <dl> <dt>Bit rate:</dt><dd>190KB/s</dd> <dt>Filename:</dt><dd>bongo-mix.mp3</dd> <dt>Duration:</dt><dd>01:02:34</dd> <dt>File size:</dt><dd>78.9MB</dd> </dl> </details>The introduction of the summary element seems to secure the future of the details element and the new behavior for now. When user agents begin to add support for the details element you won't need JavaScript, or even CSS, to have expanding or collapsing sections in an HTML document. When and how it is implemented is still being worked on.
Best bet? Use different-sized images. Unfortunately, this comes with a slight hit on load but you use them dynamically with JavaScript. You can have two images of different sizes and serve up the correct one for a specific device using Media Queries. It's not the resolution that is important, it is the size of the image.
There are many tutorials out there that explain how to use Media Queries to target specific browsers and devices and apply special rules to them. It is really painless.
Right now, most images on the web are served up as 72 pixels per inch (ppi), which is the standard. Ppi is really only relevant to print. An image sized at 200px x 200px will display the same regardless of resolution at the same dpi, but what does matter is width and height. If you change an image 200px x 200px unconstrained except by its resolution, to say 96 from 72, the dpi would automatically increase and make the image larger. I didn't say better, I said larger. This is why you need to know how to manipulate images for the web. Always start big and work your way down. Don't go the other way when it comes to image sizes for the web.
We have been getting prepared for High Definition. CSS3 renders user interface elements with borders, shadows much the same way vector graphics do. They are completely resolution independent and will display crisp and smooth no matter how much you zoom into them.
Utilize web font icons. @font-face CSS allows you to embed a custom font that has been specifically designed with simple pictographs in place of normal characters. This allows you to have an arsenal of re-useable vector icons at your disposal on the web.
So, while I was researching this post, I learned that the way to go right now - if you care about how your images appear to all visitors, all the time, on every type of device, is to build a responsive site, and using media queries, serve up a higher res image via your stylesheets and media queries based on these situations, use proper HTML practices for captions and alternative text elements for your image elements & use vector icons via sprites for some navigation or menu items if your design allows for it. Watch your load times and do everything you can to eliminate unnecessary file sizes.
I always say you have 3 seconds for your page to load. That's it. If it takes longer than that, there might be a defect in your design.
Gallagher, Nicolas. New HTML5 elements summary & figcaption, 2010
Heilmann, Christoper. Images in HTML, dev.opera 2012
The onreadystatechange event is triggered every time the readyState changes. So basically, it is saying, request.onreadystatechange = doSomething. After you've specified where the object should send a request and what it should do once it receives a response, you can start the process using the send method: request.send(null). You must remember to assign a reference to the function itself, not to the function's result.
When a browser doesn't support the XMLHttpRequest object, the getHTTPObject function returns false, so you'll need to handle that as well. When the server sends a response back to the XMLHttpRequest object, a number of properties are made available. The readyState property is a numeric value that is updated while the server deals with the request. There are five possible values:
The status returned can be 200 for "OK", or 404 for "page not found".
Once the readyState property has a value of 4, you have access to the data sent by the server. You can access this data as a string of text provided by the responseText property. If the data is sent back with a Content-Type header of "text/xml", you can also access the responseXML property, which is effectively a DocumentFragment. You can use all the usual DOM methods to manipulate this DocumentFragment. This is where the XML part of XMLHttpRequest comes from.
A document fragment is a lightweight container that can hold DOM nodes. It is part of the DOM 1 specification and is supported in all modern browsers. You can insert nodes as children of another node. You can take nodes and append them to a fragment and append the fragment to a document, but back to onreadystatechange...
Here is a great example of onreadystatechange with an alert:
function getNewContent() {
var request = getHTTPObject();
if (request) {
request.open( "GET", "example.txt", true );
request.onreadystatechange = function() {
if (request.readyState == 4) {
alert("Response Received");
var para = document.createElement("p");
var txt - document.createTextNode(request.responseText);
para.appendChild(txt);
document.getElementById('new').appendChild(para);
}
};
request.send(null);
} else {
alert('Sorry, your browser doesn\'t support XMLHttpRequest');
}
alert("Function Done");
}
addLoadEvent(getNewContent);
The Ajax methodology can improve the usability of websites by providing very fast responses to user actions without refreshing the whole page. Every action taken by the user should have a clear and obvious result. Web designers must rise to the challenge of providing meaningful feedback when the user initiates a request to the server and when the server provides a response.