|Home||Reviews||Tools||Forums||FAQs||Find Service||ISP News||Maps||About|
how-to block ads
3 Web Standards
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.
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.
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.
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.
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:
World Wide Web Consortium
Web Standards Group
The Web Standards Project
To the novice webmaster, frames may seem wonderful. However from the user's perspective, frames present a number of challenges.
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.
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.
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.
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!
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.
got feedback?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
101 Switching Protocols
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
402 Payment Required
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Time-Out
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