DTD - The Document Type Declaration

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!

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

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!

What is JQuery

What is JQuery

jQuery is an amazing JavaScript library that makes it easy to create wonderful web effects in just a few lines of code. As the website says:”

“jQuery is a JavaScript library that takes this motto to heart: Writing JavaScript code should be fun. jQuery achieves this goal by taking common, repetitive, tasks, stripping out all the unnecessary markup, and leaving them short, smart and understandable.”

Maybe you are thinking… “Why I would need another JavaScript library”? Just give a try and you will see how simple and powerful it is even if you have already used Moo.fx, Scriptaculous, TW-SACK or Prototype.

Why I should use jQuery?
Simple. In just one glance at the source code of a page using jQuery you’ll see how easy it is to use, how much it accomplishes in so few lines of code, and how graceful it is.
My mind was opened one day when I stumbled across some code written with jQuery. I was flipping through the RSS feeds and reading my daily dose of web design blogs when I came across an example of JavaScript loveliness that used jQuery. Truth be told, the code on that site had some browser related bugs… but the concept was something I hadn’t seen before.

What about the code?
The code looked almost simple. Like nothing I had seen before. It made sense.
I started reading through the documentation and was amazed to see how much could be done with so little extra code.

When you can use jQuery?
You should use jQuery when you need:
A small library that gives you powerful control over the Document Object Model
With very little effort or work on your part
Or
Quick access to AJAX
Without a lot of bloat (overhead - wasted code)
And some basic animation effects to spice things up
But…
If you need super fancy effects for animation, drag and drop, and super smooth animation then you’ll probably want to use Prototype and one of the many great library created to enhance the effects.

Where to get it?
You can download the source code (15k), a lot of plugins and read some excellent tutorials at the

jQuery website. jQuery was created by John Resig.

Thanks to http://www.html-advisor.com/javascript/what-is-jquery/

Read more!

jQuery

jQuery

jQuery is a fast, concise, JavaScript Library that simplifies how you traverse HTML documents, handle events, perform animations, and add Ajax interactions to your web pages. jQuery is designed to change the way that you write JavaScript.

jQuery is an amazing JavaScript library that makes it easy to create wonderful web effects in just a few lines of code. As the website says:”

“jQuery is a JavaScript library that takes this motto to heart: Writing JavaScript code should be fun. jQuery achieves this goal by taking common, repetitive, tasks, stripping out all the unnecessary markup, and leaving them short, smart and understandable.”
Maybe you are thinking… “Why I would need another JavaScript library”? Just give a try and you will see how simple and powerful it is even if you have already used Moo.fx, Scriptaculous, TW-SACK or Prototype.

Why I should use jQuery?
Simple. In just one glance at the source code of a page using jQuery you’ll see how easy it is to use, how much it accomplishes in so few lines of code, and how graceful it is.
My mind was opened one day when I stumbled across some code written with jQuery. I was flipping through the RSS feeds and reading my daily dose of web design blogs when I came across an example of JavaScript loveliness that used jQuery. Truth be told, the code on that site had some browser related bugs… but the concept was something I hadn’t seen before.

What about the code?
The code looked almost simple. Like nothing I had seen before. It made sense.
I started reading through the documentation and was amazed to see how much could be done with so little extra code.

When you can use jQuery?
You should use jQuery when you need:
A small library that gives you powerful control over the Document Object Model
With very little effort or work on your part
Or
Quick access to AJAX
Without a lot of bloat (overhead - wasted code)
And some basic animation effects to spice things up
But…
If you need super fancy effects for animation, drag and drop, and super smooth animation then you’ll probably want to use Prototype and one of the many great library created to enhance the effects.

Where to get it?
You can download the source code (15k), a lot of plugins and read some excellent tutorials at the jQuery website. jQuery was created by John Resig.

Read more!

Check your markup and style validity

Check your markup and style validity

http://xhtml-css.com :
This is a website that helps you check the markup and style validity of web pages. It does this by submiting the urls that you want to check to the W3C Markup and the W3C CSS Validators. Read more!

What does a front-end web developer do?

What does a front-end web developer do?

Front-end web developers, the "artists" formerly known as web designers are the bunch of people in the company that make sure that the data coming from the backend gets displayed on the browser. They also make sure it looks as closely as possible as the design, that , CED came up with, and that the user can navigate through it, accessing the data.



Front-end web developers, the "artists" formerly known as web designers are the bunch of people in the company that make sure that the data coming from the backend gets displayed on the browser. They also make sure it looks as closely as possible as the design, that , CED came up with, and that the user can navigate through it, accessing the data.


Web developers don't have it as easy as it sounds though. True enough, markup languages are easy to learn and scripting languages are not much harder, but there is an aspect of uncertainty, that has to be taken into consideration, when judging their skills.

As a web developer you work in an uncertain environment. What looks good and works on your computer can be a popup hell and dire to look at on the machine next to you or on the machine of a customer. The first is not much of a problem, just ask your colleague to upgrade his browser, the second, however, is a problem.

As a web developer, your work can be wrecked by users and customers in many ways:

They can

* use a browser that is completely outdated
* set his browser font to "very small" or "very large"
* use a video card that displays 16 colours only
* run a resolution of 640x480 pixels and still have the large font setting
* run a resolution of 1024x768 but still keep his window as large as 200x200
* use loads of toolbars to make the area of the screen available for your site pitifully small
* turn off any scripting support for safety reasons
* turn off images to load the pages faster
* use a modem with the speed of two tins connected through a wire
* use a PDA
* use a text-only browser

and if the site does not work with that, they'll blame you for it.

In other words, you never know what is going to be the mean of display at the other end.

What to do about that? Don't fret, there are standards that the World Wide Web Consortium (W3C) defined a long time ago. Just follow these standards and you are safe.

The only problem is that the browser industry keeps telling their products follow these standards, but, in reality, they don't.

So by doing the right thing, you do the wrong thing. By following the standards, you make sure that your site will perform fine in future browsers and display units. On nowadays and yesterdays browsers though, there might be loads of issues.

What you do need to do is to make sure your site is following the standards and still looks OK on older browsers. This is the perfect option. Another would be to define a certain browser and platform environment. This is possible when we are talking about Intranets and B2B sites, but B2C means you are in trouble.

You are really in trouble, when the design you got was done by a designer who is not firm in web design. The web is a media, not a sheet of paper. Designs that look really nice on paper (and impress customers) might not work on the web. Same as screen layouts do not work on television or game consoles.

Users are able to resize the text part of your page, or, in newer browsers even add own rules of display onto your site (through own stylesheets). This means that every layout, that relies on fixed font-sizes, and text, that can only use up a certain area, is doomed to fail.

You can go the other extreme and keep everything flexible, which may result in really ugly texts, with lines too long to be readable. This is a minor issue though, as, when the user has a problem with that, he can simply resize his browser window.

In any case a good web developer needs to know a lot about the media he works in.

He needs to know

* what browser/platform configuration breaks your page when you use which technology
* which technology or elements to use to create the navigation in
* what to do to avoid wrong display on browsers
* how to keep the size of the final document small
* how to convert graphics so that they are small in file size and yet good looking
* how to deal with data coming from the customer in various and sometimes rather exotic formats
* how to keep his work from stalling when there is no data coming in that he can use.
* How to communicate to colleagues or customers that the amount of final data in the product does not really fit the design (which is a case of bad planning to begin with, but it does happen)
* How to keep up with the rapid web development market and techniques.

These are the most obvious bits. Another obstacle a web developer has to tackle all the time is the media and software market hype.

At every computer fair and in magazines software companies advertise products, that help you do a web site in 20 minutes without knowing anything about code. For good measure you can also add all the multimedia you want and connect it to the database, you don't know anything about either.

When looking at these ads one starts to wonder why people care about hacking in their HTML. Front-end development is considered a task that can be fulfilled by any application or even the export filter of a graphics development program.

True, these applications do put out HTML and Javascript. True, the results look good. Wrong, they can replace a web developer. They can replace a "web designer", someone who hand-codes "HTML designs". When talking about HTML designs, I mean web sites without any other purpose but being eye candy. Standalone, plain HTML documents, a few links, some rollovers, but no back end connections or interactvity. Sites that are nothing but an ad can be safely done with them. As soon as you need the site to fulfil a specific task, be really optimised and fit the other components in your development framework, these WYSIWYG editors (like Dreamweaver, Frontpage, Adobe Pagemill and so forth) stop being that handy.

The worst nightmare for a front-end developer is to be confronted with markup code generated by these programs. A script or application can never optimise like a human being can, the code is bloated, unreadable and not logically structured in most of the cases. Keeping in mind that the outcome was meant to look great for 20 minutes work, why would it? The user never sees the source code. The developer does, and it's his job to keep it as small, fast and readable as possible. Especially when you remember, that he might have to hand it over to another developer for changes.

The availability of web content is amazing and great, but also has a downside to it. Content and code can be published immediately and is available to everybody. This is very nice and actually one of the main reasons to make people start web developing. After all it's easier to create your first web site than to try and get some time on TV or radio. The downside of it is that content gets published without any quality testing. Any enthusiastic developer, with more drive than skill. creates some new, cool design or effect, and publishes it on his web site. As it is cool and new, other developers see it, and implement it as well, to stand out from the crowd. Looking at this effect closely makes it obvious that it only makes sense in a very restricted browser environment and only for some content. Sometimes it might not even make sense at all. Nevertheless it becomes more and more spread and used, and sooner or later customers will see it and want it as well. Or colleagues see it, don't realise the flaws it might have (as it works on their browser) and offer it to the customer.

Then the web developer gets asked to implement it, and gets blamed when it does fail in the quality test.

There is no such thing as free lunch. Also there is no such thing as a perfect web site that you assemble from free content from the web without knowing what you do. Script libraries and personal developer sites advertise their content much like software companies. They claim their products have perfect output. Truth is, you can find anything on the web, and that is great, but make sure you test it thoroughly before you even think about using it in a product someone pays you for.

To conclude, the web developer is the developer on the project that has it all: A very unstable display environment, a skill set that needs to range from code to design and usability, and the blame when the end product does not look the way it should.

It's a hybrid position, you are someone that paints with code. Programmers don't accept your work as real code, and designers don't consider it design.

Now you might be at the point where you ask yourself: If that is such a horrid position in the development circle why bother taking it?

Well, the love for the media I suppose. The challenge to make things visible to users and not exclude a lot of them. The hybrid position in between programmers and designers and dealing with both. The satisfaction of seeing things you have done online and realising that people use it. The immediate satisfaction of hacking in some funny words with brackets around them and controlling the layout of a text by doing so.

It is a position that needs constant improvement, and interest in the media you work for. The days of front-end developers that attend a 2 day course and make a lot of money the week after are over. Now it is the job to clean up the mess those "web designers" left behind. To work with design and backend and project managers to make sure the customer gets something that is looking good and works fast and reliable.

So next time you think about smiling about those tag coders or HTML monkeys (I saw that as an official title in a work contract) you are welcome to try it yourself.

Read more!