Back To Basics: HTML

Posted on September 02, 2004  |  

Posted in Development

10 comments

In this installment of Back To Basics I wanted to talk about HTML as we know it, or don't know it. Browsing around sites developed in ASP.NET I couldn't help noticing that most developers don't even code proper HTML. Why is ASP.NET development plagued with this? Let's analyze.

Numerous times I did View Source on .NET sites and noticed chunks of meaningless HTML right in the header.

<HEAD>
 <title>versioninformation</title>
 <meta name="GENERATOR" Content="Microsoft Visual Studio .NET 7.1">
 <meta name="CODE_LANGUAGE" Content="C#">
 <meta name=vs_defaultClientScript content="JavaScript">
 <meta name=vs_targetSchema 
     content="http://schemas.microsoft.com/intellisense/ie5">
</HEAD>

Looks familiar, anyone? I've already criticized this code and suggested improvements in my April 2004 article Remastering Web Form Templates. Most people don't even bother cleaning up this mess aside from the fact that it's pointless and meaningless on the web.

Looking further I also noticed that only 1 out of 100 developers codes proper HTML. That's pretty disturbing. Just when you thought you were proficient at it, open up an HTML 4.x spec and read it. It's a sobering experience.

How many .NET developers use samp, var, code, acronym and abbr elements? Whether you like pre better than code is a matter of personal preference, but, in the grand schema of things, they are a proper way to set apart code samples. Or, take quotes for example: anyone using blockquote and q? What's the difference between div and span?

There's no point to recite the spec here, but you get my drift, I hope. There's much more to HTML than <font size="2"> and <td vAlign="top">. There are many ways to express something with much more semantic meaning.

Blame Trail

There are way too many parties to blame for our incompetence. For one, it is the fault of server controls shipped with ASP.NET 1.x! Yes, quite a few of them produce horrendous markup. Most third-party server controls do, too. Standard compliance is nowhere in sight.

We can also blame adaptive rendering. Personally, I stay away from the asp:Panel control because it turns into a table from a div in any browser outside of Internet Explorer. I use asp:PlaceHolder instead. At least, it won't produce any markup anywhere.

We can blame Microsoft for their lack of commitment to standards. Consider SharePoint Server. Yes, you can write custom widgets, but have you seen a clean one yet?

Also, we can blame training companies and MCTs for not even mentioning good HTML practices. How many of them offer training in web standards? How about only CSS? Wintellect? No. New Horizons? No. Extreme Logic? No. DevelopMentor? No. There's plenty of coverage of Indigo, Avalon, Lonhorn, etc—all the funky technologies due in almost two years from now. I challenge trainers to introduce a course or two in web standards. I guarantee: if taught properly people will love them!

Finally, we can blame Microsoft's marketing machine for hyping up betas and technology previews of all kinds, and disregarding what we need here and now. There's little attention, if any, is paid to the current tools. I haven't read a single article on MSND for weeks, neither have I been to an MSDN event or a newsgroup meeting for a few months. With an insane whirlpool of projects at work I can't drag my a## across Long Island and half of Manhattan to listen to yet another presentation on TabletPC, Yukon or Whidbey. None of it helps me get my job done, and, consequently, none of it servers our customers. That's some reality check right there for Microsoft folks, ain't it?

What Is It With Web Standards Compliance?

Why am I tooting this horn? ASP.NET is a powerful framework for web development. As far as I'm concerned, the most powerful to date. Maybe this is exactly what blurs our sight. After all your hardcore HttpModules and HttpHandlers are done processing pipeline events, after all your templated databound controls and triple nested datagrids fired their Render and RenderContens methods, it is HTML that travels back to the user!

Where Do We Start?

How about we start with Roger Johansson's Developing With Web Standards? It's an outstanding head start. How about we learn from mistakes of others made over and over again? How about we start paying attention to DOCTYPEs? A couple of books by prominent designers will sure put you on the right path. In upcoming installments of Back To Basics we'll talk about XHTML, CSS, web form templates and so on.

Conclusion

If Soma got his numbers right, according to Forrester Research 56% of decision makers at large companies in North America indicated that they'd be doing the majority of their development work on .NET this year. What I think we're missing at this point is a breed of ASP.NET developers who truly, deeply care for the web and are committed to serving it to the best of their ability.

Remember: there's no shame in learning HTML!

Good luck in your endeavors! If y'all need help, advice, consulting services, etc, in this field, please let me know.

10 comments

SimonT
on September 2, 2004

Take a look at html specs and a lot of those attributes are marked depricated.

I definately agree that more coders should learn html and whats deprecated and how to use css instead of the damnable font tag.

Panels so much easier to type than placeholder though isnt it ;-)


SomeNewKid
on September 5, 2004

One of the reasons ASP.NET sites provide such awful HTML is that the rendered HTML is never "shown to be wrong". It's not that the developers do not care that it's wrong, but they often don't *know* that it is wrong.

When the developer is creating his codebehind, any syntax error is flagged by the compiler. He gets *feedback*. His errors are apparent, and he cannot proceed without fixing them. He cares, because he is forced to care.

Or consider how a developer drags data from his database. Developers spend many many hours trying different techniques, trying to find the best alternative. Why do they spend time here, and not on the rendered HTML? Because they can test and *measure* the results of their data access. They care to get this code right, because they can *see* the difference it makes.

But when it comes to the rendered HTML, there is no feedback, visual or calculated.

In terms of visual feedback, IE is too forgiving of invalid HTML. If ASP.NET developers tested their sites in Mozilla, *then* they would care ... they'd see the results of invalid HTML.

In terms of calculated feedback, that's where the W3C validators come into play.

Now, asking developers to (1) test in Mozilla and (2) test against the W3C validators simply won't happen. Most VS.NET developers seem reluctant to use any tool other than VS.NET. That's reality, and we must accomodate it.

So, what's the solution?

Simple: update VS.NET so that it provides feedback on the rendered HTML.

First, VS.NET could incorporate its own standards-based browser for testing and debugging, rather than passing this off to IE. If the developer hits F5 to test his site, and watches as it falls apart in the standards-based browser, *then* he would truly care about valid HTML.

Second, VS.NET could incorporate the W3C validators. The free HTML-Kit editor incorporates the validators, so why not VS.NET? Just as hitting F5 shows the results of the compiler, it too could show the results of the W3C validators.

Additionally, VS.NET could incorporate HTML Tidy for checking on the validity of the rendered HTML. Again, the free HTML-Kit incorporates HTML Tidy, so why not VS.NET?

If these tools were incorporated into VS.NET, providing visual and calculated feedback on the HTML, then the developers *would* care about valid HTML ... and give it just as much importance as getting their data access right.

Asking VS.NET users to use *other* web browsers and *other* tools is an exercise in futility ... it will not happen. These users spend their entire day in VS.NET, and neither want nor care to use anything else. That's reality, and we can spend every waking hour trying to point them to other browsers and other tools. But it will be wasted effort.

We should be calling for VS.NET to change, not for its users to change.


Milan Negovan
on September 5, 2004

I agree, it's an uphill battle. I think once ASP.NET developers understand that coding with web standards renders tangible benefits, such as wider reach of people with various browsers, less markup = bandwidth savings and fater downloads = less money spent on hosting, much easier code maintenance, etc, we will see a shift in the mindset. Money talk always gets the message across faster. :)


Frank Zehelein
on September 5, 2004

Really good writing - so true.

About visual feedback:
This can only be one step into the right direction (deprecated and this stuff).

All you can do (and does the compiler) is a grammatic check. This is easy and should be implemented - yes.

But the much more tricky part are semantics. You can't teach a compiler to give you back "good" code. All the Design Patterns and best Practises - no compiler can implement these for you.

Same for semantic use of HTML. You will never get VS.NET to tell you - "hey - you should use a abbr/code/pre/... here". That is the point.

And yes - at least the Server Controls should be done in an accessible and semantic correct way. This would be a real great step into the right direction.


Jamie Geiges
on September 7, 2004

This article was forwarded to me by a friend and co-worker, Tanny O'Haley. Over the past year or so he has "shown me the light" of using HTML rather that ASP.NET (I consider them to be separate languages, just look at the source).

I build Intranet websites for my company and I know first hand that the developers that taught me HTML in the past have corrupted me. The first lesson they taught was how to build everything using Tables (why, because it is easier and faster).

I'm not sure if Microsoft is to blame for this one (completely), I think the developers are getting too lazy. Before I had VS.NET, Dreamweaver, or any other HTML editor, I had the best editor ever Notepad. It helped me realize the how to build an HTML pages from the ground up. Try challenging any ASP.NET developer to build an ASP.NET page from scratch and they will more than likely fail.

If it wasn't for Tanny, I would still be using the VS.NET Drag and Drop controls. Leaving the source alone with its Swirling mess of inline style tags. I would then try to bump my controls using the arrow keys to align them.

Let's not get on Microsoft’s case about this one, let's get the developers off their butts and have them start to code from the 'HTML' section in VS.NET not the 'Design' section.

I know I'm not perfect and I know I will never be perfect, but I'm trying and on my way (Thanks to Tanny)


Milan Negovan
on September 7, 2004

Keep it up, Jamie! That's what I'm trying to get better at myself and encourage others to do: master the basics. :)


Ryan Farley
on September 15, 2004

So true Milan. When I do asp.net developer training, I don't even show that controls can be dropped on to a page. Instead I force them to focus on the markup. There's no controlling some of the markup from server controls, but at least they won't go adding to the mess with even more bad markup generated for them by VS.

Keep up the great content.


James
on April 22, 2005

Honestly, half the fault is VS.NET itself. It constantly reformats your code (even if you tell it not to).

Trying to code in XHTML, for instance, is impossible. Whenever you view your page in the designer, it will reformat all your code and spit back plain HTML, screw up your whitespacing and tabs and strip all your XHTML formatting.

It's frustrating beyond belief and I know alot of ASP.NET developers just give up.

Sometimes using the designer is necessary. Dragging and dropping half a dozen SQLDataAdapters is much, much, MUCH faster than typing up definitions and setting up table mappings and relations etc

If VS.NET let you drag and drop that kind of stuff into the HTML view, it wouldn't be that big a deal and you could avoid ever looking in design view thereby keepng your X/HTML safe.

I bet we'd see much better code on ASP.NET sites when Microsoft fixes VS.NET so it doesn't reformat your HTML.

I'd also like to just mention that my default testing browser is Firefox. Not all of us ASP.NET developers are ignorant standards snubbing Microsoft zombies.

I love ASP.NET, but Microsoft's blatant disregard for webstandards is getting old...


Kumari arati
on June 16, 2005

can i have codes in asp.net to access the table generated in HTML


Milan Negovan
on June 16, 2005

Kumari, if I understand the question correctly, the asnwer is "it depends". If you build a table as a server-side control, then the answer is yes, you can get to its code. If it's a plain HTML table, then, no, you can't get to it from code-behind. You can set up a page filter (see my article on producing XHTML compliant pages) and manipulate HTML directly.