Showing posts with label Web standards. Show all posts
Showing posts with label Web standards. Show all posts

What is a Microformat?


"Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards"

The concept of a Microformat might be best seen as a subset of an existing technology focusing on solving a specific problem or an open source data format that can be used to solve a problem.


It's hardly new - not in web terms. Microformats are a method of marking-up types of content to be easily lifted or shared with other websites or applications. For instance, the name and address of your company can have certain class names attributed to your HTML elements. These class-names can then be read by a web app, which will allow a site visitor to insert those details directly into your address book with the click of a link. Microformats are not that difficult to apply - in most cases it's just a slight modification of your HTML classes.


Put in more plain English, it’s about marking up your (X)HTML with semantic and predefined class names and ids. If everyone uses the same class names for a certain type of data, we can write programs to parse it.

More info found in
Read more!

Fix Your Site With the Right DOCTYPE!

by JEFFREY ZELDMAN
You’ve done all the right stuff, but your site doesn’t look or work as it should in the latest browsers.

You’ve written valid XHTML and CSS. You’ve used the W3C standard Document Object Model (DOM) to manipulate dynamic page elements. Yet, in browsers designed to support these very standards, your site is failing. A faulty DOCTYPE is likely to blame.

This little article will provide you with DOCTYPEs that work, and explain the practical, real–world effect of these seemingly abstract tags.
by JEFFREY ZELDMAN
You’ve done all the right stuff, but your site doesn’t look or work as it should in the latest browsers.

You’ve written valid XHTML and CSS. You’ve used the W3C standard Document Object Model (DOM) to manipulate dynamic page elements. Yet, in browsers designed to support these very standards, your site is failing. A faulty DOCTYPE is likely to blame.

This little article will provide you with DOCTYPEs that work, and explain the practical, real–world effect of these seemingly abstract tags.

WHY A DOCTYPE?
Per HTML and XHTML standards, a DOCTYPE (short for “document type declaration”) informs the validator which version of (X)HTML you’re using, and must appear at the very top of every web page. DOCTYPEs are a key component of compliant web pages: your markup and CSS won’t validate without them.

As mentioned in previous ALA articles (and in other interesting places), DOCTYPES are also essential to the proper rendering and functioning of web documents in compliant browsers like Mozilla, IE5/Mac, and IE6/Win.

A recent DOCTYPE that includes a full URI (a complete web address) tells these browsers to render your page in standards–compliant mode, treating your (X)HTML, CSS, and DOM as you expect them to be treated.

Using an incomplete or outdated DOCTYPE—or no DOCTYPE at all—throws these same browsers into “Quirks” mode, where the browser assumes you’ve written old-fashioned, invalid markup and code per the depressing industry norms of the late 1990s.

In this setting, the browser will attempt to parse your page in backward–compatible fashion, rendering your CSS as it might have looked in IE4, and reverting to a proprietary, browser–specific DOM. (IE reverts to the IE DOM; Mozilla and Netscape 6 revert to who knows what.)

Clearly, this is not what you want. But it is often what you’ll get, due to the preponderance of incorrect or incomplete DOCTYPE information this article hopes to correct.

(Note: The Opera browser does not play by these rules; it always attempts to render pages in standards–compliant mode. Go, Opera! On the other hand, Opera does not yet offer solid support for the W3C DOM. But they’re working on it.) {Ed: Since this article was first published, Opera has delivered the DOM-compliant Opera 7 browser.}

WHERE HAVE ALL THE DOCTYPES GONE?
Since DOCTYPES are vital to the proper functioning of web standards in browsers, and since W3C is a leading creator of web standards, you might expect W3C’s website to provide a listing of proper DOCTYPEs, and you might also expect to be able to find this information quickly and easily in a single location. But as of this writing, you can’t. {Ed. Prompted in part by this article, the W3C now lists standard DOCTYPEs on its site. You will find the listing a few screens into the W3C tutorial, “My Web site is standard. And yours?”}

W3.org is not A List Apart, WebReference, or Webmonkey. It’s not intended to help web designers, developers, and content folks get up to speed on the latest technological recommendations and practices. That’s not its job.

W3C does publish a series of tutorials, though most web developers are unaware of it. Mainly, though, W3C’s site houses a collection of proposals, drafts, and Recommendations, written by geeks for geeks. And when I say geeks, I don’t mean ordinary web professionals like you and me. I mean geeks who make the rest of us look like Grandma on the first day She’s Got Mail.™

You can search for DOCTYPEs all day at w3.org without finding one page that lists them all. And when you do hunt down a DOCTYPE (generally in relation to a particular Recommendation or Working Draft), it’s often one that won’t work on your site.

Scattered throughout W3C’s site are DOCTYPEs with missing URIs, and DOCTYPEs with relative URIs that point to documents on W3C’s own site. Once removed from W3C’s site and used on your web pages, these URIs point to non–existent documents, thus fouling up your best efforts and the browser’s.

For instance, many sites sport this DOCTYPE, copied and pasted directly from w3.org:

"DTD/xhtml1-strict.dtd">
If you look at the last part of the DOCTYPE (“DTD/xhtml1-strict.dtd”), you’ll see that it is a relative link to a document on W3C’s site. Since that document is on W3C’s site but not yours, the URI is useless to the browser.

The DOCTYPE you’d actually want to use is:


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Notice that the latter DOCTYPE includes a complete URI at the end of the tag. Since the tag provides a valid location on the web, the browser knows where to find it, and will render your document in standards–compliant mode.

DOCTYPES THAT WORK
So what DOCTYPEs should we use? Glad you asked. The following complete DOCTYPEs are the ones we need:

HTML 4.01 STRICT, TRANSITIONAL, FRAMESET
"http://www.w3.org/TR/html4/strict.dtd">


"http://www.w3.org/TR/html4/loose.dtd">


"http://www.w3.org/TR/html4/frameset.dtd">
XHTML 1.0 STRICT, TRANSITIONAL, FRAMESET
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
XHTML 1.1 DTD
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
NEXT STEPS
How can you help improve support for standards on the web? Besides bookmarking this page (and copying and pasting these DOCTYPEs for your own use), if your web editor inserts DOCTYPEs, you might want to check them out and compare them to the list above.

Many well–intentioned software makers have cut and pasted incomplete DOCTYPEs from W3C into their software. Result: when you use these programs’ built–in functionality to insert DOCTYPEs in your pages, the browsers go into Quirks mode, undoing all your hard work.

It’s worth contacting the folks who make your favorite authoring package, showing them the proper DOCTYPEs, and politely requesting them to address this issue in an incremental upgrade. (In some cases, you may also be able to modify your editor yourself.)
Read more!

Building a site with web standards

Why and How to use Web Standards?

1. What are web standards?
“Web standards are intended to be a common base… a foundation for the world wide web so that browsers and other software understand the same basic vocabulary“.
Eric Meyer



Who sets the webstandards?
The World Wide Web Consortium (W3C) and other standards bodies have established technologies for creating and interpreting web-based content. These ‘web standards’ are carefully designed to:

deliver the greatest benefits to the greatest number of web users
ensure the long-term viability of any web document
simplify code and lower the cost of production
deliver sites that are accessible to more people and more types of Internet devices
continue to function correctly as traditional desktop browsers evolve, and as new Internet devices come to market

2. The web standards
Structural Languages
Extensible Hypertext Markup Language (XHTML) 1.0
XHTML 1.1
Extensible Markup Language (XML) 1.0
Presentation Languages
Cascading Style Sheets (CSS) Level 1
CSS Level 2
CSS Level 3
Object Models
Document Object Model (DOM) Level 1 (Core)
DOM Level 2
Scripting Languages
ECMAScript 262 (the standard version of JavaScript)
Additional Presentation Languages (Markup)
Mathematical Markup Language (MathML) 1.01
MathML 2.0
Scalable Vector Graphics (SVG) 1.0

3. What are the benefits of using web standards?
Benefits for you:
Less code means sites are easier to maintain
Less browser specific coding - compatible with current browsers
Less revisiting of old sites - compatible with future browsers

Benefits for your audience:
Less code means sites are faster downloads
More accessible - will work in a wider variety of user agents

4. What do standards mean to web developers?
Web designers and developers should be aim to build sites that use:

Semantic markup
Valid code
Accessible code
Separation of style from content

5. Semantic code
Semantic code uses html elements for their given purpose. Well structured HTML will have semantic meaning for a wide range of users and user agents (browsers without style sheets, text browsers, PDAs, search engines etc.)

In simple terms, this means:

for headings, use heading elements starting with h2
for paragraphs of text, use a paragraph element
for lists, use a list item element
You should use standard HTML elements for your markup and avoid styling HTML elements to look like other HTML elements. For example, avoid styling
elements to look like headings.

6. Why use valid code?
Valid code will render faster than code with errors.
Valid code will render better than invalid code.
Browsers are becoming more standards compliant, and it is becoming increasingly necessary to write valid and standards compliant HTML

7. How do you make your code valid?
Start with the right doctype
Be aware of doctype modes (standards compliant, quirks mode etc)
Use a character set
Close HTML elements
Use alt tags for images
Avoid HTML hacks
Use HTML validators regularly
Fix any bugs you find before you go live
Make validation part of your normal work process

8. What is accessible code?
Allows your site to be accessible to a larger audience (vision impaired, motor skill impaired, cognitive impaired)
Allows your site to be accessed by wider range of devices (hand helds, screen readers, text browsers, search engines)
Is a requirement for Federal and State Government sites

9. How do you make your code accessible?
Provide text equivalent for non-text elements
Use accessible data tables (identify row and column headers)
Use accessible forms (label for, id, fieldset, legend)
Use markup rather than images to convey information.
Provide visible skip menus
Provide access keys
Use style sheets with relative units to control layout and presentation
Make sure documents can be read without style sheets
Provide metadata to add semantic information
10. Separating style from content
Easier to make site-wide changes - one css file rather than all pages
Smaller files/faster download - less code on the page
Less code on the page - easier to code
Allows users to customise to their own needs - style switchers
More control over code - can deliver code in preferred order for screen readers
Files are more accessible to a wider variety of mediums - separate css files for other devices

11. How do you separate style from content?
Decide on a browser support level and code methodology
If full CSS is the chosen methodology, decide on a CSS positioning method
Place content into containing boxes
Use CSS positioning to control layout of containing boxes
Use CSS to control the visual appearance of all html elements
Test on a wide variety of browsers at each stage
Read more!

Front End Developer ( who is ..)



You have been working with (X)HTML and CSS for anywhere from 1-4 years. You prefer front end development because you're creative and visual and have a good eye for design. You write standards-compliant / semantic (X)HTML and CSS without Googling the syntax or using WYSIWYG editors.

You understand the difference between standards mode and quirks mode. You know what the box model hack is and what versions of IE it works for. You may love Firebug because it saves your life or you are so good you don't need it. You can use Gimp, Fireworks or Photoshop to cut up images and are handy with designing an icon or two in a pinch.

You are not uncomfortable working in the context of a complex Java web application even if you don't understand its intricacies. You won't get scared off by scripting markup like Velocity or JQuery showing up in the code here and there.

You are a self starter who loves working with technology and you stay up late putting the finishing touches on your code. You don't need to be told what to do to see what needs to get done. You are excited about working with a leading open source software company with cutting-edge opportunities at Fortune 500 companies around the world.

Read more!

What happens in Quirks Mode?

Quirks Mode is a mode of operation of web browsers such as Internet Explorer (IE), Firefox, and Opera. Basically, Quirks Mode (also called Compatibility Mode) means that a relatively modern browser in ten tio nal ly simulates many bugs in older browsers, especially IE 4 and IE 5.


Quirks Mode is a mode of operation of web browsers such as Internet Explorer (IE), Firefox, and Opera. Basically, Quirks Mode (also called Compatibility Mode) means that a relatively modern browser in ten tio nal ly simulates many bugs in older browsers, especially IE 4 and IE 5.

Quirks Mode is triggered by doctype sniffing, also known as doctype switching. This means that the browser inspects the start of an HTML document to see whether it contains a doctype declaration as required by HTML specifications.
The purpose of Quirks Mode is to make old pages to display as their author intended. Old pages may have been written to utilize known features of old browsers or at least to adapt to them. For more information about Quirks Mode in general, consult the QuirksMode.org site.

There is no authoritative specification of what happens in Quirks Mode. After all, the mode is, by essence, an inten tional violation of CSS and HTML specifications. However, since authors may need a description of what may actually happen in Quirks Mode, I have composed this document.

If you have an existing page that seems to work well but lacks a doctype dec la ra tion (required by HTML specifications) at the beginning, you should not simply put such a dec la ra tion there. The reason is that the dec la ra tion makes browsers work in the so-called Standards Mode as opposite to Quirks Mode. This may mean just about anything. I have seen the entire content of a page disappear when you add a doctype dec la ra tion. More often, the layout changes in rather un ex pect ed ways. Well, the ways are not that un ex pect ed if you know what may happen in Quirks Mode. Before adding a doctype dec la­ra tion, you should check both the HTML and CSS code for syntactic correctness by using validators and checkers. This may not be enough, since the page might still have been written relying on things that just “work”—in Quirks Mode. Thus, you should test the page at least on IE 7 and Firefox 2 in Standards Mode, i.e. after adding a doctype dec la ra tion. If the page doesn’t work then, the following list might be useful for spotting the problem.
When creating a a new page, you need not know about Quirks Mode and should usually not think about it. Simply write according to HTML and CSS specifications; this includes using a doctype dec la ra tion that puts modern browsers into Standards Mode. Moreover, put the doctype declaration at the very start, since some browsers go to Quirks Mode, if there is anything (even a comment) before it. (This causes trouble if you are using XHTML, but in most cases, you shouldn’t use XHTML for web pages anyway, for the time being.) But if you decide to use some features that might only work in Quirks Mode, such as a height="100%" attribute for a table element, you should check the list for other possible implications.
Read more!

Printing the Web: Solutions and Techniques

Users don’t read, they scan. In fact, after many years, reading online still didn’t manage to assert itself against reading offline. Therefore long articles are usually printed out and read on paper. However, not every page will be printed out correctly by default - sometimes layout doesn’t fit, sometimes font size isn’t chosen properly or leading simply isn’t big enough. It is also important to include some further references to the printed version of the page, so users can get back to you, once they’ve read the printed version of your article.
Good news: web-developers can control the way web-site looks on the paper.To make sure that no data will lost and the legibility of content remains optimal after the printing, you can, of course, use CSS.
There are many options and techniques you can use developing print layouts. Here is a quick overview of some interesting solutions you can use to generate print layouts “on the fly”.
Printing the Web: CSS-Techniques
Five Simple Steps to Typesetting on the web: Printing the webMike Boulton gives an example on how to design a nice print layout, which looks like print layout in traditional magazines.
Footnote Links: Improving Link Display for PrintAaron Gustafson presents a CSS+JavaScript-based method, which replaces all links on a page with corresponding footnotes. Elegant and extremely (!) useful solution.
10 Minutes to Printer-Friendly PagePrint-layouts can be generated with PHP. Marko Dugonjic shows, how.
From Screen to Print: Creating a Print CSS in DreamweaverThis article will examine how our layout displays one set of elements on the screen, yet when printed, prints a different layout using elements that do not display on screen.You’ll learn about media types and how to take advantage of them and using the cascade to create lightweight, compact pages for print. Since Community MX constantly tweaks its site, some things may be slightly different if you read this article a few months from its publishing date.
A Print CSS PrimerA detailted introduction and tutorial by Kenji Ross.
Print DifferentQuite an old article by Eric Mayer, in which he describes different media types you should consider designing print layouts.
ALA’s New Print StylesEric Meyer about A List Apart Print-Layout. The article is a “follow-up” of the article CSS Design: Going to Print, which was published in ALA 2002.”Say no to “printer-friendly” versions and yes to printer-specific style sheets. CSS expert Eric Meyer shows how to conceive and design print style sheets that automatically format web content for off-screen delivery. Includes tips on hiding inappropriate content, styling text for the printer, and displaying the URL of every link on the page.”
CSS Styling for Print and Other MediaIan Lloyd about the media-attribute and development of user-friendly print layouts.”There are many different media types that you can apply to CSS, some of which are more useful than others, and they let you specify the look, feel, or sound of the web page that is linked to the CSS files. In this section, we’ll look at the various media types that are available.”
Complete CSS Guide: PrintingIn CSS2, the page properties are defined by the @page rule, while several new properties help control page breaking. John Allsopp explains in detail, which guidelines you should keep in mind designing print layouts and how you use @page-rules such as page-break-before, Widows, Orphans etc. efficiently.
Printing The WebJames Kalbach describes common mistakes and discusses important aspects of print layouts regarding usability.”Consider how users interact with other formats and media, particularly paper, and address the reality that people print web pages. With a little planning and foresight creating printable pages is relatively easy and extends a positive user experience to paper.”
Dive Into Mark Print-friendly Linksworks just the way Footnote Links work, but also adds the URLs of Links in the brackets after the links.
Print-Friendly CSS and UsabilityRoger Johansson discusses, whether print layouts, which are different from the page structure, are user-friendly. Themaninblue’s post on the same topic.
Print to PreviewPete McVicar’s JavaScript creates a preview page with a warning message users can use to navigate back to the original page.
Printing Web documents and CSSJim Wilkinson explains, what print layouts should have, (e.g. the URL of the original web-page), which elements should be removed (e.g. navigation) and what how you should handle links, footers and headers. Also problems in different browsers are taken into consideration.”This document describes some of the issues concerning the use of CSS to reformat Web documents for printing (using the media type “print”). We also discuss those aspects that CSS is not able to control or even influence. We assume a good knowledge of CSS and concentrate on practical issues, given the current deficiencies in browsers in implementing print-related CSS.”
Read more!