How should we incorporate W3C's recommendations into our Web development?

With experience, professionals gain more and more knowledge about doing things, which their peers consider "right", and other things their peers consider "wrong".

In time the list grows and you have the option of being realistic and pick what is "right" and "wrong" and what is just "ok" on a strictly per-project basis, so that you meet your project requerements.

Or you have the option of thinking in absolutes where every project "must absolute follow all these with the punctuation and the spaces" and religiously defend your best practises at the cost of project deadlines, expenses and common sense (and claming otherwise anyway).

Web standard "zealots" fall into the latter group. Standards are here to help us develop, not help us find reasons to call our peers "stupid" for not being religious enough about putting a legend tag in their forms.

We have modern English because human language was not set in stone as a standard couple of hundred thousand years ago: instead people left it develop and transform in a natural way to conform to the changing requirements of the society. Not that there are no linguistic experts to mock you for using a dialect form of a word, which is basically their manifestation of "standard zealots", but the other folks realize this is not actually so important, as long as we can convey the meaning and data we want to, in speech and writing.

Web development has come a long enough way, so that it has segmented into different "sub professions" - like server side development, server administration and management, graphics site design, HTML/CSS design and so on.

To see how shallow our religious arguments seem in the real world, it's enough to see how much that ALT tag missing from the navigation images seem to a PHP developer, who on his own is fanatic about using single quotes instead of double quotes in his code string literals, because they are 0.001% faster (that's true btw), and he doesn't care about HTML "properness" at all, as long as it looks right and is secure on his side.

In the same fashion the color scheme balance or how soft the shadows under those icons mean nothing to a usability expert who only wants that the text is large and readable, the navigation easy to access and the page is light.

That same site to a graphics designer would look like a "wrongly done" site, since noone would enjoy to visit and use it, because it looks like a home page attempt from the 90-s (I'm looking at you, Jacob Nielsen). And this graphics designer would proceed making the site "right", using techniques that would make a usability guru pull his hair out.

To a copywriter, neither design nor accessibility or server security would matter, but he'll start making fun of me if I skipped a comma or had a typo in this post, for example.

But even more, to our end user, who in most of the projects is just your average folk, who won't judge for your site by the presence of the XML prolog in the source, completely different stuff matters: "is it good enough", "is it usable enough", "is it accessible enough", "is it nicely looking enough", "does it work well enough on my device".

Surprisignly, the barriers a regular user uses for considering your product (ex. a site) "overall good enough for me, so I pick it" is a lot less a function of being extreme in any of those disciplines, and a lot more about having a smart balance and compromise between all of them.

And this, zealots will never tell you about.

I believe that standards are a very important aspect of any business. While more important in for instance construction since not adhering to standards could lead to a loss of life. They are still important web development. It's these standards that application developers follow when producing products designed to parse html (such as web browsers). If the standards are also followed by the website developers it's more likely that the site will work in untested browsers.

Before tables were invented (with the ability of not having borders) the layouts were basic, then tables came along and it didn't take long before people discovered that they could use tables to create much fancier looking websites. Broadband then arrived and amount of graphics on websites went up, however at that point no one really gave much thought to accessibility since IE was still pretty much all that was used to browse the web. We've now entered a time where many different devices and so different browsers can access the web, portable devices etc. Due to this there is a push away from using tables and to using HTML the way it was originally designed for (marking up paragraphs as paragraphs etc). CSS is then used to add style however the designer wishes. Unfortunately CSS that is supported is still in a relatively infantile state many of the issues and complications that are involved by using CSS are fixed in CSS3. For example instead of using floats for layout which like tables were not really designed for the job, we have CSS3's Advanced Layout Module which is designed for the job.

Basically what I'm saying is that web development is no different to any other business. Standards should be followed and techniques will constantly evolve. It is the job of the web developer to keep up to date with these techniques. No site designed today will be good code in 15 or so years when CSS3 is usable. Just as computers, cars etc made 15 years ago tend not to be considered all that great.

Everything in moderation... going zealot doesn't help anyone. All you end up doing when you become a fanatic is lose focus and take the purpose of web development way out of context. Real web development isn't building blogs that validate. Real web development is meeting your clients requirements in the best way possible. That includes not only conforming to standards, but making sure you also fall within budget, deadline, and user base constraints. You can't just drop your head and run headlong toward "web standards, web standards, web standards" and trample everything else in your path. You need to think "business" as well as "conformance".

Besides, who ever said the W3C recommendations were gold? If anything, technical specs should NEVER be left open to interpretation. What kind of silliness is that?

The order of how you should design a page is:

1. Figure out what your site's reason for being is.
2. Who is your audience
3. What is the life cycle of your audience - do they have different needs at different times? If so treat them as different groups.
4. How can you do #1 for everyone in #3
5. Layout an architecture that makes sense and servers everyone in #3
6. Get meaningful content for everyone in #3 that can be refreshed on a regular basis (i.e., give them a reason to come back)
7. Create an interface that everyone in #3 will understand - i.e., where they always know what page they are on through perhaps a breadcrumb, page title, consistent and highlighted navigation, etc.
8. User testing on sample audience of #3 to see if your layout works.
9. Now build your site using standards

As you can see, a site that works - that actually thinks about it's audience, goes through at least 8 steps before getting to the web standards issue.

Web designers spend too much time thinking about how a site will be built, and how it will look - and not enough about thinking about who a site serves, how it serves them, and give them a reason to come back. Users come back to sites that serve them what they want without a lot of hassle - not one that was built on standards.

Standards are very important - but a designer should get the first 8 steps right first.

Sarven, greeting, good points in this article.

Especially this one: The Standards developers can then only show their competency among other developers whom already follow the good practices. By this, there exists a perception of being more competent then the average good developer, yet overlooking the core project goals.

I would love to hear more about your ideas on project goals being overlooked. I'll talk to you soon.

"Design for today" is a good point but it leaves a lot of space for interpretation. Some think that tables for layout is "today" and some think not. Determining this is not something we can get help from the standards bodies with, they are busy with CSS4.

Instead I think a good way is to read and talk with a lot of real web developers and ask them what's the best way of making a website is. Today I wouldn't say that they would answer "tables for layout" any longer.

I also have to disagree with suv4x4: The use of technology have very little to do with whether someone picks your product or not. Suv4x4's comment about breaking away from current best practices for the best of the customer have never been more false.

I'm still waiting for the day when what you design in photoshop or some equivilant is exactly what shows up in EVERYONE'S browser. Hopefully bandwidth with no longer be any relevant issue in the next 10 years. I'm all for standards... but it's sad in todays 'web tech' fields... web standards has become an oxy-moron.

Yes, you make a really great point here! Its great to have pure w3c complient code but it can take a lot longer to implement complex designs under tight timelines and budgets.

I do tend to largely blame internet explorer and its pathetic support for web standards, which has greatly obstructed the progress of the web over the past 5 or so years, not to mention costing developers countless headaches / hours of extra work and clients billions of dollars. Hmmm we can dream though... universal CSS4 support!

Regarding "design for today": most definitely things will change in the future and no web site will be everlasting. However, different parts will change in different ways.

I can't think that, as long as we use HTML for the content, that it will move away from proper semantics (e.g. from h1 to a div with). So, in the future when a web site needs to be updated, you will probably only have slightly modify the HTML but then apply a new CSS with new features do it.

My belief is that while designing properly for today, I don't think it has to be rewritten from scratch the next time around.

A Proposed Recommendation is still a "work in progress" and may still be updated, obsolete, and replaced. But even if it does not imply any official endorsement by the W3C, most often a Proposed Recommendation is close to the final Recommendation both in content and in time.

I agree with the point of departure of the article. Bad designers ignore standards, good designers adhere to them, and the best designers are intelligent enough to know when the rules stop being applicable. Common sense kicks in.

In fact, a designer who wouldn't even break a rule when abiding by it yields bigger problems than it solves, is not unlike an Immanuel Kant adherent who wouldn't lie, even to save lives. What duty-based ethics and web standards have in common, is that they both provide a very sturdy framework, aiding us in deciding WHAT IS RIGHT. They're great, but all too often, people trade in common sense for blind reverence.

"One must not go the other way around by altering the requirements of their projects just to satisfy incomplete specifications." Because that would be like Microsoft's approach to backwards compatibility - staying compatible with a precursor built like a card house is never worthwhile. XD

Now, I do think you made a few (possibly) false assumptions, or at least omissions.

1. You seem to assume that each and everyone of the people reading this is fully adept in web design, and can make a right judgment on the applicability of standards each and every time. However, some people, especially those who haven't yet fully grasped the abstract concepts behind separating structure and form, might even see this as an excuse to perpetuate bad design practices. Causing bad user experiences every day. (._.) 2. The attitude towards standards adherence shouldn't be dictated by economics and scale alone, but also by the very nature of the content that is being represented. While this pragmatist attitude will yield excellent results for an online store, it could turn out very badly when dealing with archival, historical and similar content, that will be stored for decades or even hundreds of years, and needs to remain legible whatever the case. It simply wouldn't be viable to make changes and fixes to those documents every few years or even decades. 3. I could be very wrong, but I don't think using tables for layout was ever a recommendation by any standards body. The number of standards being dropped, elements being deprecated; in other words the pace of evolution, has been catalysed a lot by bad design practices (and emerging new possibilities, of course), necessitating further development of standards. However, I feel that those efforts are directed for a large part towards decreasing the need for future game changers, and making the implementation of the remaining few easy for designers/authors. For instance, separating structure and form save us editing unbelievable amounts of spaghetti HTML code, even when most of HTML would be rendered a thing of the past.

(Also, hasn't the standards movement mostly been about either restoring or pushing forward concepts that where conceived at the very beginning of the web? I guess it's too early to tell whether standards will keep evolving at this pace, and whether they will need to.)

(I would like to hear more of your thoughts on this topic if at all possible)