This is our seventh and last post on XHTML/HTML.  With this post we want to draw some conclusions with regards to all the information that was provided.

HTML and XHTML offer very similar functionality in terms of describing and marking up documents for the web.  XHTML has a number of advantages in terms of its interoperability with other markup documents, and its consistent syntax.

A few years ago, it seemed clear that XHTML would be the “future of the web”, but more recently, HTML has grown in popularity, as browser support for XHTML has often not kept pace with developments. The competition on who is going to be more popular is still open. even if we believe XHTML has some definite advantages.

But if you’re ready to make the transition from HTML to XHTML, you’ll want to check out Aggiorno – a plug-in for Microsoft Visual Studio that has embedded knowledge about the differences between HTML and XHTML – to make your transition easier.  It automatically targets XHTML 1.0 Transitional documents and makes sure your pages are error-free and up-to-date before going on to offer additional improvements, such as improving accessibility, automatically upgrading table layouts to use CSS and extracting master pages from sites with similar formatting.

"We don’t have the time to waste on cleaning up the code. We have to get this feature implemented now!"  Have you ever heard such a comment?  Have you ever made such a comment?  Chances are that you probably have both heard and made the comment!  Well this is probably one of the most common objections to Refactoring as it is explained in the book Refactoring HTML by Elliotte Rusty Harold and summarized in the following series of posts: The Cafes » Objections to Refactoring.

But let's start from the beginning.  What is a Refactor?  As stated on Wikipedia, in software engineering, "refactoring" a source code module often means modifying without changing its external behavior, and is sometimes informally referred to as "cleaning it up".  A refactor is a source code transformation that does not alter the behavior of the program.  Historically refactorings have been applied to make the code more maintainable and have been almost within the exclusive realm of sophisticated programmers.  In recent years IDEs like Visual Studio.NET have started to support refactoring and the term is starting to become part of the standard programmers language.  However, the concept of a refactoring has only been applied to small localized changes in the source code.  Changes that somewhat improve code  maintainability or that perform some modification in an automated manner that help the programmer increase its productivity while editing code.  Of course refactorings are a good thing, and in general if you can improve the maintainability of your code you should, specially when you know that your code has to continue to evolve.

When we were designing Aggiorno the first way of referring to what Aggiorno would do was: "Refactoring for the Web".  However, we soon realized that even if Aggiornings are similar to refectorings in the sense that they perform transformations on code they are different in their purpose and this is why we coined the name.

Aggiornings are a form of encapsulated knowledge aimed at providing business value as directly as possible.  For instance, an aggiorning will help you make your page XHTML compliant (web standards).  And we already know from previous posts that making a page standard helps you with SEO, accessibility, maintainability, etc.  Another scenario where aggiornings help is when you want to separate content from style.  The immediate business benefit is that maintainability costs go down, but also, it is much easier to port the code to mobile browsers and it is also easier for google to index your page and not get confused by cluttered markup.  Aggiornings might or might not preserve equivalence in the code they transform (refactorings always do) and even if we preserve equivalence when it makes sense to do so, we also make other changes that produce a big return on investment even if they do not preserve equivalence.  Another big difference about aggiornings is that the user can always request an explanation and aggiorno will show exactly where the changes happened so the user can ultimately decide if he wants to go trough with them or not.

Going back to the title of this post, source code improvements that are aimed at improving maintainability are in general a very good thing to do.  If you look at refactorings from the perspective of aggiornings the code improvements are even more important.  We are talking about improvements whose ROI can immediately be measured from the business perspective.  There really should be no objections to using refactoring techniques or aggiornings on your code.  If you have an objection, let me know!

ahh... and let me encourage you to download aggiorno Beta and explore aggiornings for yourself.

By David Alfaro 

What do I mean by “shuffled tags”? It’s my shorthand for what some authors have called Invalid Markup  or Malformed markup as a cause of Tag soup.  More precisely, it refers to placing “end tags in the wrong order”, as stated in the HTML TIDY documentation. For example, consider this fragment:

<p>
    here is a para 
    <b> bold <i> bold italic</b> bold?</i> normal?
</p>

  At a glance, you can see that the end tag </b> appears where </i>  should and, conversely, the end tag </i> is where the </b>  should be placed.

 

Well, well, not so bad. But remember that anything between <i>  and </i> is in italics and anything between <b> and </b> is in bold. That’s the way browsers render it, at least in Internet Explorer 7 and Firefox 2 . IT DOESN’T MATTER THAT <i>… </i> AND  <b>… </b> ARE OVERLAPPED! That is, I will take THIS specific behavior as consistent between IE7 and FF2. I’ll assume that THIS specific browser rendering is what the “web developer” understood and accepted.

In the aforementioned HTML TIDY documentation, you will find the latter shuffled tag example is supposedly corrected to:

<p>

here is a para
<b>bold <i>bold italic</i> bold?</b> normal?

</p>

Hmmm, what do you think? Hmmm, wait a minute!  Something is wrong. Let’s see the behavior in Internet Explorer 7:

Source:

 

“Corrected”:

 

 

 

I knew it! Remember our today’s mantra:  “anything between <i>  and </i> is in italics and anything between <b> and </b> is in bold: so, it doesn’t matter if they are overlapped”.

A more realistic solution is:

<p>

here is a para
     <b>bold </b><i><b>bold italic </b>bold? </i>normal?

</p>

 This solution is a little bit verbose, isn’t it? Well, yes, but this solution expresses author’s intention using the semantics of HTML/XHTML. Thus, you rely on standards rather than relying on browser interpretation. Does it really matter? Undoubtedly!  Search bots don’t necessarily read pages exactly as browsers do.  In this context, relying on standards is always a safer bet. Ask Chris Maunder of CodeProject about his experiences with Google when it comes to reading and indexing pages related to HTML syntax and DOCTYPE.

[Search bots don’t necessarily read pages exactly as browsers do. In this context, relying on standards is always a safer bet]

How many kinds of “shuffled tags” exist? Maybe a more useful question is: Which kinds of “shuffled tags” are more popular in the web? What are their solutions? We are preparing a serious study about it and we’ll post it very soon. Stay tuned. [Update: A new post about the top ten shuffled tags scenarios]

So far, my “realistic solution” is for me the best solution regarding HTML syntax. Do you agree with me? Do you have a better solution? Please let me know; we depend on your feedback to create a better web.

 Your comments are welcome!