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?

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!

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!

Web Design Basics

Guide to Web Design / HTML
Web design uses all the same elements as print design. You need to explore the space and layout, handle fonts and colors, and put it all together in a format that puts your message across. These resources will help you learn Web design whether you are already a professional Web developer or just getting started in the Web arena.
Elements of Good Design
Fonts and Typography
How to Use Color
Graphics and Images
Web Layout Basics
Tackling Web Navigation
Accessibility and Usability
Web Design Software
Elements of Good Design Read more!

Process of Web design

Web design is a process of conceptualization, planning, modeling, and execution of electronic media content delivery via Internet in the form of technologies (such as markup languages) suitable for interpretation and display by a web browser or other web-based graphical user interfaces (GUIs).

The intent of web design is to create a web site (a collection of electronic files residing on one or more web servers) that presents content (including interactive features or interfaces) to the end user in the form of web pages once requested. Such elements as text, forms, and bit-mapped images (GIFs, JPEGs, PNGs) can be placed on the page using HTML, XHTML, or XML tags. Displaying more complex media (vector graphics, animations, videos, sounds) requires plug-ins such as Flash, QuickTime, Java run-time environment, etc. Plug-ins are also embedded into web pages by using HTML or XHTML tags. Read more!