Showing posts with label XHTML. Show all posts
Showing posts with label XHTML. Show all posts

hackIE

<!--[if gt IE 6]>
<link rel="stylesheet" type="text/css" href="css/ie7fix.css" media="screen" />

<![endif]-->
<!--[if lte IE 6]>
<link rel="stylesheet" type="text/css" href="css/ie6fix.css" media="screen" /> 

<![endif]-->


<script language="Javascript" >

    var useragent = navigator.userAgent;
    var bName = (useragent.indexOf('Firefox') > -1) ? 'Firefox' :
navigator.appName;


    if (bName == "Firefox") 
    {
        
        document.writeln('<style> #nav_bar_t6 {padding-left:33px;
padding-right:33px; } #footer {margin-left:18%}</style>');
    }

    if(navigator.userAgent.indexOf ("Netscape")!=-1)
    {
        
        document.writeln('<style> #nav_bar_t4 {WIDTH:
14.2%;padding-left:2px;} #footer {margin-left:18%}</style>');
    }
    
    if(navigator.userAgent.indexOf ("Opera")!=-1)
    {
        document.writeln('<style> #nav_bar_t6 {padding-left:38px;
padding-right:33px;} #footer {margin-left:18%}</style>');
    }
</script>



Read more!

DTD - The Document Type Declaration

A DTD is a Document Type Definition, also know as DOCTYPE. In a document served as text/html, the DOCTYPE informs the browswer how to interpret the content of the page.

If the the doctype is not declared, the browser assumes you don’t know how to code, and goes into "quirks mode". If you know what you are doing and include a correct XHTML DOCTYPE, your page will be rendered in "standards mode".




A DTD is a Document Type Definition, also know as DOCTYPE. In a document served as text/html, the DOCTYPE informs the browswer how to interpret the content of the page.

If the the doctype is not declared, the browser assumes you don’t know how to code, and goes into "quirks mode". If you know what you are doing and include a correct XHTML DOCTYPE, your page will be rendered in "standards mode".


All of the above declarations will inform the browser to render the browser in standards mode. When authoring document is HTML or XHTML, it is important to Add a Doctype declaration. The declaration must be exact — both in spelling and in case. And, the URL must be included. If not, you risk having your page rendered in quirks mode. A list of the DTD’s and how browsers handle them can be found at http://hsivonen.iki.fi/doctype/

There are other DTD’s, such as for MathML and "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd"> for mobile. A list of valid DTDs is maintained at http://www.w3.org/QA/2002/04/valid-dtd-list.html

The XML declaration for XHTML web pages of is optional. Older browsers such as IE5 for the Mac choke on this. And, if you include it, IE6 renders in quirks mode, but IE7 renders in standards. So, for now, omit it. But, if you do include it, it must be the very first line, before the DTD


Why is quirks mode bad? Ever code a page and have the font inside your data tables be huge? That’s because in quirks mode browsers render td’s based on the browser default, not on the declared body default size. The box model is rendered differently and images as block instead of inline.

Why are DTD’s good? In addition to everything above, a DTD enables you to have valid code. To test validity, a page is compare to the rules for that document type. If you don’t have rules, how do you compare it? The DTD tells the validator what rules to use.

What is the difference between strict and transitional? Transitional allows depreciated tags and attributes to pass validation. The strict doctype is strict: depreciated tags and attributes will fail to validate under a strict doctype and may well display incorrectly as well. See Comparing XHTML and HTML, Strict and Transitional and Deprecated Elements and Attributes.

What does PUBLIC mean? In the above DOCTYPEs, all of them include the term "PUBLIC". If you are creating your own DTD then put your DTD on your sever and include the term "SYSTEM" with the path to your DTD file. On the other hand, if you are using PUBLIC DTD’s, such as those listed above, and the public identifier which starts with -//.

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!