The Importance of Knowing HTML in a WYSIWYG World

When I meet someone new and they learn that I do web development for a living, a common question that I get immediately afterwards is, "I do a little of that too, what program do you use?" My answer is that over the years, I've used several but about a decade ago I settled on Adobe (formerly Macromedia) Dreamweaver. But unfortunately that really doesn't tell the whole story.

Way back when, the initial web development application was one that everyone got for free with their Windows computer: Notepad. Because websites are built using plain-text HTML and are not compiled like C++ applications, for example, a basic text editor is all that's needed to get something online. There simply was no drag-and-drop WYSIWIG (What You See Is What You Get) application that wrote the code for you, so anyone interested in getting their ideas on the web needed to have at least a fundamental understanding of the web's language, HTML. But along came web editing applications such as Microsoft FrontPage and Adobe PageMill and suddenly a new breed of web designers was born: the WYSIWYGs.

So Why Do I Need to Know HTML? What's Wrong with Web Editors?

On the surface, nothing at all. By creating the HTML code for you as you drag-and-drop your way to a lovely layout, the editor can save you time, cut down on repetitive copying and pasting, and effectively eliminate the need for any programming knowledge. While that last one certainly sounds good the problem arises when you, well, have a problem. Without proper knowledge of the code that powers your website, you won't know how to handle the situation when one of your visitors sends an email that reads something to the effect of "I'm viewing your website in Firefox and everything is all jumbled together! What gives?" Furthermore, the code that these editors create can be bloated at best and a security risk at worst. The last thing you want is some script kiddie overwriting your well written blog article with links to spyware sites and the like.

Solving Problems in the Code

As I mentioned earlier, I do use Adobe Dreamweaver for 100% of the development work that I do -- but I use the code view, not the design view. I happen to like the way Dreamweaver formats code for readability, the integrated FTP client for uploading completed files, and the extremely helpful site-wide find and replace tools that it has, among other things. To that end, the code view makes it very easy to spot one of the most common web errors: unclosed tags. Depending on the browser and DOCTYPE declaration, an unclosed tag can be a minor annoyance that prevents a page from validating properly or it can cause a complete layout crash, whereby other elements lose their formatting and end up in the wrong places. In Dreamweaver, simply typing <⁄ and hitting enter will create the closing tag that it expects to see. If you're at the bottom of the page and Dreamweaver spits out a <⁄p> you know you've missed a closing paragraph tag someplace.

Many WYSIWYG editors still default to the old standard of web layout: tables. This is partially due to convention but it's also due to the complexity of integrating cascading stylesheets, images, linked JavaScripts, etc. in a graphically editable mode. As a result, your editor is generating code that is not only much more verbose than need be, it's also completely outdated and likely inaccessible to non-standard browsers (screen readers, mobile, WAP, etc.) Explaining the benefits of CSS and separation of content from markup vs table-based layouts is outside the scope of this article, but fortunately there's plenty of reading material on the subject. Suffice it to say, 9 times out of 10 you're starting off on the wrong foot if your web editor is generating table-based code.

Understanding the Code Eliminates Code Bloat

When I first started writing web applications I was extremely dependent on Dreamweaver's (née UltraDev's) built in behaviors which I then would modify if I were doing something outside the box. Eventually, I found that I was spending more time adapting and fixing the code created by Dreamweaver than I was saving by using it. Have a look at the example below -- it's a block of code that allows for paging (jumping from one page of records to the next):

<%
'  *** Recordset Stats, Move To Record, and Go To Record: declare stats variables

Dim rsBuildings_total
Dim rsBuildings_first
Dim rsBuildings_last

' set the record count
rsBuildings_total = rsBuildings.RecordCount

' set the number of rows displayed on this page
If (rsBuildings_numRows < 0) Then
  rsBuildings_numRows = rsBuildings_total
Elseif (rsBuildings_numRows = 0) Then
  rsBuildings_numRows = 1
End If

' set the first and last displayed record
rsBuildings_first = 1
rsBuildings_last  = rsBuildings_first + rsBuildings_numRows - 1

' if we have the correct record count, check the other stats
If (rsBuildings_total <> -1) Then
  If (rsBuildings_first > rsBuildings_total) Then
    rsBuildings_first = rsBuildings_total
  End If
  If (rsBuildings_last > rsBuildings_total) Then
    rsBuildings_last = rsBuildings_total
  End If
  If (rsBuildings_numRows > rsBuildings_total) Then
    rsBuildings_numRows = rsBuildings_total
  End If
End If
%>

The scary part is that what I posted here is only about 1/10th of the total code necessary to make this work. If you're interested, here is the whole thing. Keep in mind that's not including the initial connection to the database and query to collect the data and save it to a recordset that the page can use for display. So, around 300 lines of code just for the server-side code to handle pagination, every time you need to page through records. Now, let's compare that to the following:

<!--#include virtual="/includes/pagecount.asp" -->
<%=createPageCount(varMoreRecords,varCurrentPage,iRecordsPerPage,20)%>

That's two lines, if you're keeping score at home. Granted, the pagecount.asp that I include contains more than two lines of code -- but it's nice and reusable, unlike the WYSIWYG behavior that Dreamweaver has to create on every page that needs recordset paging. If you expand that out to an entire application you can begin to get an idea of just how much extraneous code you can lose by learning the code yourself.

Remember The Matrix

If you've seen the movie The Matrix (and I'll assume you have, since you're reading a programming/development blog) you may remember Cypher's line, "I don't even see the code anymore. All I see is blonde, brunette, redhead..." While you don't need to achieve that level of proficiency in order to create simple web pages and blogs, obtaining a basic, functional knowledge is not nearly daunting as it seems and the rewards are absolutely worth the time invested to learn it. Knowing what you're looking at will save you a great many headaches when things go wrong and can dramatically improve page load times while cutting down on the risk of unwanted intrusions simply by having clean code.