how-to block ads
|
|
3 Web Standards·What are web standards, and why should I care?
·Should I use frames for my web site?
·Where can I find guidelines regarding web standards and technologies?
·What are the HTTP error codes and their meanings?
| | | Web standards are simply defined structures for how content should be created and distributed on the web. The W3C has set forth various languages and methods with specific guidelines as to what can and can't be used.
Examples include markup and presentation languages, such as XHTML, and CSS. There are others as well, such as the Document Object Model, but the main bread and butter of any web developer will be primarily XHTML and CSS.
Who cares?
On the surface, these standards may seem unimportant. After all, even if your code isn't exactly correct it will still display, right? Well, not exactly. Your page may look how you intended in one browser, but look completely different in another. Or it may not render at all. Invalid code can also become unmanageable more quickly, making your job harder, and at worst you may drive away visitors who can't read or display your site. It also keeps your site "future-proof" by ensuring it will be compatible with new browsers when they come out, and you won't have to go back and rewrite your code to keep it working.
I use Internet Explorer, and so does most everyone else. So as long as it looks ok in IE, I'm fine with that.
This is an unhealthy attitude some designers seem to have. Internet Explorer may have a large market share, but that's no reason you shouldn't ensure compatibility with other browsers as well. Complying with web standards ensures your page will work in all cases, no matter what the popular browser of the day is.
Accessibility
Web standards go hand in hand with ensuring your site is accessible to all as well. It is estimated that 10% of the population online today have some form of disability which may impair their ability to access your site. This can range from vision impairments like blindness or color blindness, to reduced motor skills or reaction times.
It's not only just a good idea to keep these people in mind, it's also the law. In the United States and other countries as well, a set of standards has been developed to ensure people with disabilities can still access content on the web. Examples include U.S. Section 508 Standards and the W3C's Web Content Accessibility Guidelines 1.0.
Other advantages
Even if the reasons above aren't good enough, using standards can help make your job as a developer easier. Keeping your markup clean and semantically correct makes it easier to read and maintain, and helps reduce bloat. Linking to a single CSS file sitewide is certainly easier than writing several thousand FONT tags.
Use of XHTML and CSS means your site is much more likely to work with up and coming technologies, such as browsers on TV, handhelds, phones, and other future devices.
Simple steps to complying with web standards
Developing in accordance with these standards and guidelines is easy. These steps are just some of the basics.
- Pick a markup language and include a valid DOCTYPE.
- Pick a standard language for your markup, and code in accordance to its guidelines. Add the proper DOCTYPE at the top so the browser gets a heads up as to how your page should look. A DOCTYPE is important because without it, the browser will usually fall back on "quirks mode", rendering whatever tags it comes across basically up to its own interperetation.
- Put all style information about the page into CSS.
- Many of the old style tags found in HTML4 are deprecated. CSS is the new standard for defining how a page should look. CSS code can be placed either inline with the markup, or linked to an external file.
- Avoid vendor-specific tags.
- Some companies like Microsoft and Netscape have added to the language by coming up with coming up with codes that only work in their browsers. These additions are not approved by the W3C (although sometimes they are incorporated later on) and they will not provide a consistent look and feel for your site.
- Validate your code.
- Use tools like The W3C Markup Validation Service for your HTML and The W3C CSS Validation Service to make sure your pages are up to spec. There are also tools for checking accessibility standards, such as Cynthia.
- Use meaningful, well-formed link text.
- Links are the heart and soul of hypertext pages. You want to make sure the text you use in your link is meaningful to the link it represents, even if it's out of context of the page. Don't ever use the phrase "click here". Most people already know what to when presented with a link, so these directions are redundant. Also it's not relevant to the page you're linking to. A good rule of thumb is to think of links as nouns, not verbs. So avoid linking to action words, only people, places, and things. One good reason to do this is because people with vision impairments may use screen readers when visiting your page. A screen reader is software that speaks the text on the page with the use of a text-to-speech engine. A user with a screen reader may be tabbing through the links on your page and they need to know what each link represents.
- Avoid use of frames.
- In almost all cases use of frames is not needed and results in problems in accessibility, browser compatibility, search engine spidering and links found in search results. Read more in /faq/11216
- Test your pages in as many browsers and platforms as possible.
- Don't test exclusively in one browser, use a variety. Also keep in mind that even the same browser will render differently on alternate platforms. Take a look at your page in Windows, Mac OS, and Linux to get a better feel for how others view your site. If you don't have access to some of these systems, ask for a site check in /forum/webmonk and many users will be happy to provide screenshots.
Reading more about it
This FAQ entry only scratches the surface of web standards and accessibility. There's a lot of good resources for learning more:
/faq/webmonks
World Wide Web Consortium
Web Standards Group
The Web Standards Project
 show feedback form
 close
by rjackson  edited by big greg
last modified: 2005-07-16 08:45:31 | | | 99.5% of the time, frames should be avoided when developing a website.
To the novice webmaster, frames may seem wonderful. However from the user's perspective, frames present a number of challenges.
Navigation
The biggest (mis)use of frames on a website is to include a static menu on each page. However a frame will break the basic functionality of a browser feature people have come to rely upon: Back and Forward buttons. Trying to navigate back and forward on a frames page may not work exactly like the user expects, since the browser will only go back and forward within a certain frame - not the whole page.
Bookmarking
Because the actual web address of each page in a frameset is hidden, you won't be able to bookmark to a specific page, only the main framed site. Yes, you could certainly view the source in your browser to determine the actual address and bookmark that, but this is cumbersome and too much to ask of the average surfer.
Search Engines
For the same reason as above, frames make it difficult for search engines to index your site. Some may even ignore framesets altogether, or in most cases a user will get a result from a search query that links to a single page on your site, and they would view that page out of context since the rest of the frames wouldn't be present.
Accessibility
Not all user agents are capable of rendering frames. This means that some visitors may simply be presented with a blank page. The HTML noframes tag is supposed to be used for non-frames browsers, but then you end up having to maintain two versions of your site - frames and no frames. This is more work in the long run for anyone. Usually most people just use the noframes feature to say something like, "Sorry, this page uses frames". This could completely lock out some visitors from your site - don't do that!
Frames Alternatives
Even if all the reasons above don't apply, there's still hardly a good argument for frames when presented with a number of options for developing a site.
If you have a navigation section, or some other bit of content you want to remain the same on every page, you can use server-side scripting languages to include this information on the fly when the page is loaded. Examples of server-side languages are: SSI (Server-Side Includes), PHP (PHP Hypertext Preprocessor), and ASP (Active Server Pages). What is available to you depends on the type and configuration of your webserver, contact your hosting provider if you are not sure. Even if you are not fluent with these languages, it is very easy to learn how to use the include functions.
If you are using an iframe (inline frame) now, you can easily get the same look by putting your content into a block-level element (such as div or p) and style that element with height and width specifications, and using overflow: auto, which will render a scrollbar for any content that does not fit in the div. This method also has the added benefit of degrading gracefully in browsers that wouldn't support iframes or CSS: the content is still available without providing an alternate version.
So what about the other 0.5% of the time?
So basically frames suck and there's newer, hipper alternatives. When might it be acceptable to use a frame? Perhaps if you have complete control of the user agents and the people accessing your site, you may be able to get away with frames. An example of this might be an intranet site that is only available for employess of a certain company, all of which use the same browser and don't have any disabilities which may make page viewing difficult.
Consider the alternative methods above first though! They give you way more flexibility over your site with the benefit of less work, and they'll make things a lot easier on your users as well.
show feedback form
close
by rjackson edited by big greg
last modified: 2005-07-12 07:03:45 | | | The World Wide Web Consortium (W3C) provides recommendations, specifications, and tools that will help with your web development projects.
You may be interested in the sections on HTML and XHTML, Cascading Style Sheets, and XML.
ou can also validate your HTML/XHTML and CSS to see if you are up to the standard mentioned in your DOCTYPE.
The first line of your HTML or XHTML document specifies the DOCTYPE (or "document type"). This is where you specify your document as a certain version of HTML (old school) or XHTML (new school).
If you are using HTML, you should easily be able to have your page validate as HTML 4.01 Transitional (or HTML 4.01 Frameset if you are using frames).
If you are using XHTML you should strive to make your pages validate as XHTML 1.0 Transitional. The XHTML 1.0 Strict standard is a bit too confining for real world web sites.
For more informstion about web standards and technologies, please see
World Wide Web Consortium
Web Standards Group
The Web Standards Project
show feedback form
close
by imp$ edited by big greg
last modified: 2005-07-12 07:04:34 | | | We all know what a "404" means, but what are the rest? Here's a list:
100 Continue
101 Switching Protocols
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
303 See Other
304 Not Modified
305 Use Proxy
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Time-Out
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Request Entity Too Large
414 Request-URL Too Large
415 Unsupported Media Type
500 Server Error
501 Not Implemented
502 Bad Gateway
503 Out of Resources
504 Gateway Time-Out
505 HTTP Version not supported
show feedback form
close
by climbers edited by big greg
last modified: 2005-07-12 07:04:14 |
|
