Professional Web teams build Web sites not only to serve static content but also to serve dynamic applications and sites from Content Management Systems (CMS). These should employ user interface (UI)-layer code, further subdivided into markup, CSS, and JavaScript. The importance of this is magnified the larger the Web site or the longer the duration between major site overhauls. Why not reduce dependence on backend programmers or CMS experts, when the UI coders could largely manage UI changes themselves?
Add the challenge of integration with third parties and older and newer Web properties from across a Web enterprise, and you’ll see there are endless aspects that can benefit from Web standards. In fact, anything within end-user interface has code that should be implemented using Web standards-based techniques.
Many Web application developers learned HTML in the 1990s and haven’t updated their coding techniques to incorporate lessons learned since then. It can be an interesting experience to share new levels of separation and strict adherence to a standard or specification with an application developer who’s grown tired of the tag soup of yesteryear. Modern standards-based approaches are much cleaner, more efficient and logical, and tend to appeal to software engineers’ sense of “either it works or it doesn’t”—often reviving their interest in front-end development.
By definition, standards-compliant Web sites strive for strict adherence wherever possible. When Web-based software intersects with or even produces UI layer code, the same levels of discipline should be expected. This benefits the site and the application in the long run by reducing the risks that come with a number of software modifications. Web standards-based approaches increase compatibility and accessibility, and reduce resources and efforts required to change the UI of the application or the static portions of a site alike.
The problem is that there is a huge amount of archaic, undisciplined, or just downright old-school code being implemented where Web software is concerned. We need to take a comprehensive look at custom-developed, in-house software and commercial product implementations to evaluate how and when sites’ software can benefit from Web standards.
In order to determine the nature of the situation, each and every piece of Web software employed in a project should be inventoried, cataloged, and evaluated for compliance (or noncompliance) with Web standards.
From a Web standards perspective, the trouble usually surfaces where the application developers need to create their UI layer—in the areas of maintenance, redesigns, subtle design tweaks, and of course accessibility and browser compatibility.
Typically, a Web programmer is either dropping code into templates provided by a design team or attempting to match a look and feel demonstrated in static representations of their application. There are also software packages that generate UI code with different levels of customization available. And, of course, application programmers writing their own front-end code will achieve varying degrees of standards compliance—some are quite successful and adept; others are not.
A multifaceted problem, of course, but the point is that application frameworks, education materials, generated code, and tools are seriously lacking in best-practices demonstrations. Many developers rely on some form of integrated development environment (IDE), code libraries, or copied code that may or may not follow any sort of best practices.
The results are backend code that produces ugly markup with inline presentation, table-based layouts, extra unnecessary markup, and front-end scripts that conflict, are browser specific, or don’t take into account other front-end scripts. Design changes become a real problem—and they don’t need to be.
The UI layer is either generated by human effort or it’s generated by software (with little effort) and blindly accepted by humans.
But how much effort? Since today’s application engineers, server platforms, and tools don’t typically create standards-based front-end code by default, the quality is all over the board. It takes a certain amount of effort to achieve standards-compliance on the front end of applications and content management. By establishing a set of best practices for the UI code in server-side software applications, we have something against which software can be evaluated for improvement.
It’s important to acknowledge that there is a real tradeoff between solving a problem that will eliminate issues later and simply trying to get the product out the door. Striving for Web standards-based UIs will, in the long run, reduce risk by pulling apart the layers of application logic, presentation, and UI. However, sometimes it takes time to get there.
For each document within an application, a series of questions or evaluation criteria should be considered:
Where does the UI layer come from?
How is the front-end code structured?
Does it use valid HTML or XHTML?
Is there a DOCTYPE declaration and is the document rendered in standards or quirks mode?
How are presentation aspects declared?
Do the application developers understand the UI code?
Do the UI programmers understand the backend code?
How many staff members understand how the UI and the backend are integrated?
Does the software reference any current presentation code, such as CSS files? If so, which files? Are those files changing in a redesign?
How tied to the backend business logic, if at all, is the front-end code?
Is there any way to abstract the UI code from application code?
If the application generates front-end code, is there any way to control how?
If users have the ability to generate content or code, is there a way to lock down what they can do?
What is the level of effort involved in UI layer modifications?
What is the risk to the application of UI layer modifications?
What are the potential hazards or drawbacks of not redesigning the application?
What are the limitations of how third-party software may need to be customized?
Clearly, there is an enormous amount of information to be collected, evaluated, and weighed.
In the end, aspects of some software may be beyond help. There may simply be no way to bring them up to date with the latest Web standards front-end code, either due to architectural issues or unacceptable risk. In these cases, the efforts become an exercise in compromise. Either there needs to be a long-term plan to resolve the issues or both the users and the business will just have to suffer through painful update processes.
This is essentially a tradeoff between short-term effort and risk, and long-term effort and risk. Some partial solutions include either an implementation of some styles (even extracts from or specific CSS files) or a superficial re-creation of the look and feel for a given application. In the long run, though, the organization suffers because it will become more difficult to apply changes to applications that become special cases and need to be evaluated every time a change is made. The critical turning point varies by organization.
An organization’s Web applications can benefit from establishing standards, coding guidelines, and interaction points and references for the way the UI code should be written and styled.
These are coding-quality and consistency standards much like those frequently placed on application developers; however, they now extend to their front-end code, which may be a new thing.
Any UI code should be built following basic Web standards-based best practices involving the use of POSH, CSS, and unobtrusive JavaScript (as described in Chapters 1, 2, and 3 respectively).
Browser independence, accessibility, and graceful degradation are key.
Programs should reference UI CSS classes and
IDs by pulling them from deep within application logic to reachable points in the code, so that making changes to the presentation information poses minimal risk to the application. These CSS classes andIDsmight be superficial properties of object classes, stored in configuration files, or application-level variables, so they can easily be changed later.Avoid inline presentation styles or attributes at all costs.
Collaborate on JavaScript applications with front-end coders to share scripts as much as possible and avoid conflicts.
Distill the applications to the most simple and semantic markup possible.
Create basic, standard CSS rules for forms so that when new ones are added, they can have CSS applied without effort.
By following these guidelines and adopting clean, separated, Web standards-based code, you will ensure that applications and business-critical software won’t need significant or risky modifications when a redesign is required.
Unfortunately, these sorts of guidelines can only go so far with software packages, tool kits, and code generated by IDEs or WYSIWYG editors. These tools let authors go only so far to remove inline presentation settings, push the settings into CSS classes, and so on. It may take some effort to examine alternative settings or experiment with one feature over another to get the tools to do what needs to be done. However, there are often simple steps to decouple application logic from backend code.
Most Web-based applications include some variety of forms. It is not uncommon for Web authors to use an HTML table to obtain a nice layout for these forms.
While there is nothing inherently wrong with this practice, tables are for tabular data. Here there is no tabular data and no reason for the table. There are also presentational attributes such as bgcolor, align, and width, and no accessibility gains from any modern Web standards-based approaches. Additionally, often this form will include some server-side code to populate the values of the form (more on that later).
For example, here is a table being used to display a very simple data form (FIGURE 4.1):
<p>Please complete the following form:</p> <p><b>User Information</b></p> <form action="submit.php" method="post"> <table width="300" border="0"> <tr> <td bgcolor="#cccccc" width="30%" align="right">First Name:</td> <td><input type="text" name="txtFName" size="30" /></td> </tr> <tr> <td bgcolor="#cccccc" align="right">Last Name:</td> <td><input type="text" name="txtLName" size="30" /></td> </tr> <tr> <td bgcolor="#cccccc" align="right">Title:</td> <td><input type="text" name="txtTitle" size="30" /></td> </tr> <tr> <td colspan="2"><input type="submit" value="Go" /></td> </tr> </table> </form>
Consider a newer version of code for essentially the same form (FIGURE 4.2):
<p>Please complete the following form:</p>
<form action="submit.php" method="post">
<div id="formBlock">
<fieldset>
<legend>User Information</legend>
<p>
<label for="txtFName">First Name:</label>
<input type="text" id="txtFName" tabindex="1" />
</p>
<p>
<label for="txtLName">Last Name:</label>
<input type="text" id="txtLName" tabindex="2" />
</p>
<p>
<label for="txtFName">Title:</label>
<input type="text" id="txtTitle" tabindex="3" />
</p>
<p><input type="submit" value="Go" tabindex="4" /></p>
</fieldset>
</div>
</form>
The above can be paired with the following CSS, which could be applied to every form on a site to make them all follow the same setup. While this might seem like extra code, setting up a consistent way that forms are to be marked and styled, external to the program, is a huge benefit.
h1 {
margin: 0;
font-weight: normal;
font-size: 15px;
}
#formBlock {
width: 300px;
}
#formBlock p {
margin: 0 0 3px;
}
p {
width: 100%;
}
label {
background-color: #ccc;
display: block;
float: left;
width: 28%;
text-align: right;
margin-right: 2px;
padding: 2px 0;
}
input {
float: left;
width: 65%;
margin-bottom: 4px;
margin-top: 1px;
padding: 1px;
}
input[type=submit] {
width: 10%;
}
fieldset {
border: none;
padding: 0;
margin: 0;
}
legend {
font-weight: bold;
margin-bottom: 12px;
}Looking at the new XHTML standards-based approach reveals several fundamental enhancements over forms created without a semantic approach:
There is no longer a meaningless HTML table required for the markup of the form.
The form now features
<label>elements that associate the text label with the actual form control—a great accessibility and, in general, user-centric feature supported by most browsers.A tabindex is applied, to facilitate a tabbing order and increased keyboard accessibility.
The form is grouped into a
<fieldset>and labeled with a<legend>,which groups and explains the form for greater accessibility.Because it is a much cleaner piece of code, the form itself, which is bound to be tweaked by the application developers, is much easier to read and modify.
Several Web scripting technologies have been around for some time, including PHP (PHP: Hypertext Preprocessor), Classic ASP (Active Server Pages), and Adobe (formerly Macromedia) ColdFusion, to name a few popular ones. These language platforms for server-side tasks have models that put front-end alongside backend code in the same files. On one line, authors will see programming logic inside technologies delimiters (examples include <%...%> and the like), and then the following line will have standard HTML. Additionally, the server-side code will use print statements to output HTML, oftentimes with inline presentation information.
There are also frameworks and coding techniques—such as the ColdFusion Fusebox (fusebox.org) framework and the PHP Smarty templating system (http://smarty.php.net)—that modularize these layers, attempting to pull the logic and front end apart, creating template files that include front-end code while the backend code is in different sets of files. In reality, the results are often mixed, because the bottom line is that the server-side code still must output a UI.
The question in the end is this: What is the quality of the markup for the UI even with it separated from business logic? All the application software tiers in the world will not help if the basic HTML code violates best practices or resides in files that the UI developers can’t control or wade through.
All frameworks or templating systems aside, some simple steps can be taken to limit the potential damage even with a barebones PHP or similar environment. In the most basic sense, any application data output or UI code being generated would be subject to the same rules that pertain to UI code that has nothing to do with databases. The only difference is that such code is simply generated, as opposed to coded by hand.
It should be noted that the challenges involved in producing clean separation of server-side business logic and presentation layers are not unique to PHP, as most server-side languages depend on good programming practices and discipline. PHP, “Classic ASP,” and ColdFusion in particular share the characteristics of the application logic frequently being embedded into the same files as the front end.
<?php
// Printing results out
echo "<table border="1" width="400">";
while ($row = mysql_fetch_assoc($result)) {
echo "<tr valign="top">";
echo "<td bgcolor="#ffffcc"><b>$row['username']</b></td>";
echo "<td>$row['firstname']</td>";
echo "<td>$row['lastname']</td>";
echo "<td><font color="grey">$row['notes']</font></td>";
echo "</tr>";
}
echo "</table>";
?>The preceding code does a simple thing in PHP: It iterates through rows in a data set returned from a database query. Most scripting languages like this have similar techniques for outputting database results with looping structures. Obviously this is a small and simple example, but it could be buried inside other looping structures or complex business logic.
There are drawbacks to the above PHP (and to other similar server-side code):
Inline presentation elements are buried inside of the looping iteration.
Design changes require changes to the application. A programmer may need to be involved, instead of having it be a CSS change external to the application.
Any time there needs to be a change to the way the table looks, a programmer must locate the presentation code and make the modification directly inline inside the application logic.
The presentation attributes are escaped because of the quoted attributes in HTML, making the code difficult to manage.
The presentation aspects must be applied manually to every table on the site.
While simple, this example demonstrates intermingling of code with presentation attributes. Imagine that the results were in nested tables just to create borders and menus, and there were different presentation attributes per column... the code would begin to get quite hairy. A cleaner alternative is:
<style type="text/css">
#results {
border: 1px solid #000;
width: 400px;
}
#results td {
border: 1px inset #000;
vertical-align: top;
}
td.username {
background-color: #ffc;
}
td.notes {
color: gray;
}
</style>
<?php
echo "<table id="results">";
while ($row = mysql_fetch_assoc($result)) {
echo "<tr>";
echo "<td class="username">$row['username']</td>";
echo "<td>$row['firstname']</td>";
echo "<td>$row['lastname']</td>";
echo "<td class="notes">$row['notes']</td>";
echo "</tr>";
}
echo "</table>";
?>While this shows only the CSS in a <style> block for convenience, it demonstrates that to change the look of the table and the alignment of the table cell content or font settings, not a single line of PHP would need to be touched. A rudimentary example, to be sure, but the point is clear: The more complex the business logic, the more benefit to the application logic in not having inline presentation information.
Note
In the table above, the ideal solution would also include a row with <th> element table headers to label the columns. This is an added accessibility benefit, as well as more semantic. If the design does not call for the headers to be displayed, they can be hidden with some creative CSS, while still making them available to assistive technologies.
The benefit of technologies such as PHP or even Classic ASP is that the Web programmer has full control over the UI code being produced—an advantage that shouldn’t be undervalued. Upkeep and maintenance of an application’s user interface can get difficult in a team environment, where it is possible that the UI code was not written by the programmer. In these cases, communication and simple iterations of review are critical. Obviously, these are business procedures as opposed to a coding technique, but these critical processes often do not happen.
The problem is, in today’s world there are many newer products and technologies gaining wide acceptance, which make reviews and UI development involvement in the backend phases harder than ever. For complex business applications, scripting languages like those discussed so far have fallen out of favor in some circles because the framework itself doesn’t impose layered application architectures. The onus is on the programmers to follow structured design patterns that enforce good programming practices. Older tools such as PHP and ColdFusion were often more accessible to UI designers or developers than some of the newer technologies.
The fundamental problem remains, or has even gotten worse, in most new server-side coding environments. It can apply whether it is inline server-side scripting such as PHP or Classic ASP, or now ASP.NET, which has a layered approach that attempts to separate business logic and backend code. It can also come up where XSLT is being used to generate XHTML or HTML from XML.
So, what is this fundamental problem? While the software engineers were building with more mature and tiered backend to front-end environments such as Java, ASP.NET, or XML/XSLT, the front-end designers and developers don’t know the front-end portions of these software environments—and frequently never will.
Typically the front-end portions of these software platforms just output the same bad legacy nonstandard code for the front end that they always have. The challenge is in pushing Web standards into the front end of these applications.
Some more modern application environments have features designed to help remove the “burden” of generating HTML or other UI code from the application developers’ plate. The concept is that HTML (or XHTML) can be easily abstracted and then dynamically generated by commands passed into the programming language of the tool kit. These are usually properties assigned to data sets being returned from database queries, or other similar structures that control the dynamic output.
The problem with this is that both the design and the ultimate code that is outputted are largely at the mercy of the writers of the software framework that abstracts and generates the code. Success also depends on the level of effort put in by the programmer to exploit whatever UI features are available. Different frameworks have different levels of quality. Authors will need to “view-source” and actually observe how the markup code is structured when it is output as opposed to just how it looks, because the markup is dynamically generated.
Nothing can replace the human element in most cases. It just takes that extra step of seeing what the code is doing and figuring out how to mold it. Sometimes there are things that can be done; sometimes there aren’t. Having made it this far into this book, it should be obvious that getting the front end standards-compliant can be a significant benefit.
One framework that has gained massive adoption, particularly in large commercial enterprises, is Microsoft’s critically acclaimed ASP.NET framework (the successor to “Classic” ASP). The .NET foundation classes, objects, and APIs are powerful.
ASP.NET enforces, by its model, layers of code that abstract database and program logic to a degree from “front end” files with the ASPX extension. These files are HTML and custom ASP.NET tags, which will be discussed later. In theory, UI coders learn these tags to control the front end with hooks for the programmers to use. This is certainly a possibility, but in reality is rarely done. The Web team would need to make a conscious decision to educate the UI team and collaborate on these efforts, and the UI team would have to be willing to learn. It could happen.
Typically, ASP.NET Web applications are created in an IDE called Microsoft Visual Studio.NET. This IDE has a WYSIWYG window that complements the programming view and allows programmers to rapidly drag form objects onto pages and set properties, including presentation attributes, without writing a line of code. These settings generate HTML.
From a Web standards standpoint, there are several issues that can be of concern with Visual Studio.NET, particularly versions earlier than 2005, and ASP.NET’s server-generated code:
Most ASP.NET examples, which everyone learns from, feature bad code.
Visual Studio.NET 2003 and earlier was notorious for (when a programmer entered this design mode) rewriting and reformatting the HTML of the page in question, even if it was created and carefully crafted in another application or plain text editor by a UI coder.
Form inputs and data controls can be ASP.NET “tags,” which frequently have presentation attributes applied to them. The code output is often not valid XHTML or HTML code, although in version 2005 this situation improved greatly. These tag attributes output a massive amount of inline presentational attributes if the author does not make the extra effort to control the output.
In versions 2003 and earlier, when an author uses the built-in tools to create a page, it creates HTML pages in quirks mode, because the DOCTYPE declaration applied to the document does not include a URI.
ASP.NET features “adaptive rendering,” which means the server makes decisions about what type of UI layer code to send to the Web browser based on server-side settings that “guess” the level of support a browser has for certain technologies.
ASP.NET’s server-side code makes great use of
IDattributes on the controls embedded in the page code. Frequently, depending on the context, theseIDs are dynamically renamed based on their location in the document, so CSS and JavaScript authors may have difficulty referencing page objects by theirIDseven though that is the open, internationally recognized, standards-based way of doing things. In some cases a CSS class might be more appropriate, or trying to apply the requiredIDto a parent element and referencing the object by context. Ideally, front-end designers and backend programmers will collaborate on setting UIIDs in the best way to leverage the strengths of both front-end code and backend code—but this is not always the case.
It is interesting to note, however, that even these concerns can be mitigated with some extra effort, time, and attention to the front-end aspects of the code.
Tip
One way to cope with “adaptive rendering” is to set the ClientTarget settings to “Uplevel,” so ASP.NET will stop assuming the only browser with any advanced features is Internet Explorer and will send advanced code to everyone. However, this can open up trouble with regard to some features, particularly ASP.NET 1.1 JavaScript features, which might only be supported by IE because Microsoft wrote browser-specific code in some places. Be aware, and carefully test before deploying ASP.NET solutions. Further, these features changed slightly in ASP.NET 2.0—another reason to test early and often.
Like other languages, ASP.NET features database output; however, one way Microsoft implements this is through its server-side tags. These tags all have presentation-related attributes that allow the programmer to control the XHTML presentation aspects of the output. Here is a typical sample of controls using an ASP.NET feature called a DataGrid control to output a table of items from a database. This code is embedded in an ASPX file surrounded by the rest of the document’s (X)HTML (FIGURE 4.3).
<asp:DataGrid ID="catalog" runat="server" AutoGenerateColumns="false"
CellPadding="2" Width="600" BorderColor="black">
<ItemStyle Font-Names="Arial" Font-Size="12px"
ForeColor="#800000" VerticalAlign="top" />
<AlternatingItemStyle Font-Names="Arial" Font-Size="12px"
ForeColor="#400000" BackColor="#cccccc" />
<HeaderStyle Font-Bold="true" Font-Names="Arial" Font-Size="15px"
ForeColor="white" BackColor="black" VerticalAlign="top" />
<Columns>
<asp:BoundColumn DataField="Name" HeaderText="Name" />
<asp:BoundColumn DataField="abbr" HeaderText="Common Name" />
<asp:BoundColumn DataField="typeof" HeaderText="Tech Type" />
<asp:BoundColumn DataField="notes" HeaderText="Notes" />
</Columns>
</asp:DataGrid>This describes a data output table including alternating row colors. The attributes that describe the look and feel of the table are just some of the options that are available; the options are in fact extensive. The source of the data coming back is in another layer of code, an ASP.NET feature for separating data and presentation, which is, in theory a great idea. Here is the code the above sample generates:
<table cellspacing="0" cellpadding="2" rules="all" border="1" id="catalog" style="border-color:Black;width:600px;border-collapse: collapse;"> <tr valign="top" style="color:White;background-color:Black; font-family:Arial;font-size:15px;font-weight:bold;"> <td>Name</td><td>Common Name</td><td>Tech Type</td><td>Notes </td> </tr><tr valign="top" style="color:Maroon;font-family:Arial; font-size:12px;"> <td>HyperText Markup Language</td><td>HTML</td><td>Markup </td><td>Used to markup documents. Loose syntax.</td> </tr><tr valign="top" style="color:#400000;background- color:#CCCCCC;font-family:Arial;font-size:12px;"> <td>eXtensible HyperText Markup Language</td><td>XHTML </td><td>Markup</td><td>HTML as an XML syntax, XML-like strict rules.</td> </tr><tr valign="top" style="color:Maroon;font-family:Arial; font-size:12px;"> <td>Cascading Style Sheets</td><td>CSS</td><td>Presentation </td><td>Separates design, look and feel information into separate documents from the markup.</td> </tr><tr valign="top" style="color:#400000;background- color:#CCCCCC;font-family:Arial;font-size:12px;"> <td>JavaScript</td><td>JS</td><td>Behavior, Interaction, Events </td><td>Sometimes called the behavior layer, this controls user interaction, events, and behavior of Web pages.</td> </tr> </table>
The table is simple, with alternating colors and font family settings, and nicely uses CSS as opposed to <font> tags. However, this is a common sample of the code used in tutorials in describing DataGrid use. The CSS gets repeated inline within the generated code due to the use of the ASP.NET tagging attributes such as ForeColor, BackColor, and others. Additionally, the top row of content, which is intended to be a header row, is simply contained in <td> elements and is set as bold.
It is a shame, because ASP.NET does in fact feature the ability to assign CSS classes for most of these values, and in ASP.NET 2.0 there are features to generate <th> elements for headers. The CssClass attribute is available for most tags and there are others that allow classes to be assigned to tags in many scenarios. Note the UseAccessibleHeader attribute of the <DataGrid> element used below. It’s too bad that programmers have to go out of their way to intentionally make the code accessible, but that is the nature of the beast—and it’s fortunate the features are there in ASP.NET 2.0.
Here are the small adjustments that can be made to the ASP.NET code to improve the quality of the output:
<asp:DataGrid ID="catalog" runat="server" AutoGenerateColumns="false" CssClass="grid-class" UseAccessibleHeader="true"> <ItemStyle CssClass="item" /> <AlternatingItemStyle CssClass="item-alt" /> <HeaderStyle CssClass="item-header" /> <Columns> <asp:BoundColumn DataField="Name" HeaderText="Name" /> <asp:BoundColumn DataField="abbr" HeaderText="Common Name" /> <asp:BoundColumn DataField="typeof" HeaderText="Tech Type" /> <asp:BoundColumn DataField="notes" HeaderText="Notes" /> </Columns> </asp:DataGrid>
Pair the above code with CSS such as
.grid-class {
border: 1px solid black;
width: 600px;
border-collapse:collapse;
}
.grid-class td {
vertical-align: top;
padding: 2px;
border: 1px solid black;
}
.item {
font: 12px arial, sans-serif;
color: #800;
}
th {
font: bold 15px arial, sans-serif;
background-color: black;
color: white;
vertical-align: top;
text-align: left;
padding: 2px;
}
.item-alt {
font: normal 12px arial, sans-serif;
background-color: #ccc;
}In this case, the HTML table looks identical with a better, more Web standards approach to the same code. Here is the new XHTML output (FIGURE 4.4):
<table class="grid-class" cellspacing="0" rules="all" border="1" id="catalog" style="border-collapse:collapse;"> <tr class="item-header"> <th scope="col">Name</th><th scope="col">Common Name</th> <th scope="col">Tech Type</th><th scope="col">Notes</th> </tr><tr class="item"> <td>HyperText Markup Language</td><td>HTML</td><td>Markup </td><td>Used to markup documents. Loose syntax.</td> </tr><tr class="item-alt"> <td>eXtensible HyperText Markup Language</td><td>XHTML </td><td>Markup</td><td>HTML as an XML syntax, XML-like strict rules.</td> </tr><tr class="item"> <td>Cascading Style Sheets</td><td>CSS</td><td>Presentation </td><td>Separates design, look and feel information into separate documents from the markup.</td> </tr><tr class="item-alt"> <td>JavaScript</td><td>JS</td><td>Behavior, Interaction, Events</td><td>Sometimes called the behavior layer, this controls user interaction, events, and behavior of Web pages.</td> </tr> </table>
Note the addition of the <th> tags (complete with a scope attribute), CSS classes on most elements including the alternating rows of color, and lack of (most) inline presentation. While the code is not perfect, it is a great improvement, with a small technique to improve the output. This sort of improvement requires front-end coders with knowledge of the backend, or backend programmers who know the front end.
There are a dozen or more options for tags to output ASP.NET database code. Sometimes, another tag altogether might be a better option because there is more control over what UI code is being produced. For instance, a Repeater control is a great choice for simple data output, as it defines an output loop with small templates of code an author can specifically set as she or he sees fit:
<asp:Repeater id="catalog" runat="server">
<HeaderTemplate>
<table class="grid-class">
<tr>
<th>Name</th>
<th>Common Name</th>
<th>Tech Type</th>
<th>Notes</th>
</tr>
</HeaderTemplate>
<ItemTemplate>
<tr class="item">
<td><%#Container.DataItem("name")%> </td>
<td><%#Container.DataItem("abbr")%> </td>
<td><%#Container.DataItem("typeof")%> </td>
<td><%#Container.DataItem("notes")%> </td>
</tr>
</ItemTemplate>
<AlternatingItemTemplate>
<tr class="item-alt">
<td><%#Container.DataItem("name")%> </td>
<td><%#Container.DataItem("abbr")%> </td>
<td><%#Container.DataItem("typeof")%> </td>
<td><%#Container.DataItem("notes")%> </td>
</tr>
</AlternatingItemTemplate>
<FooterTemplate>
</table>
</FooterTemplate>
</asp:Repeater>The above code generates an HTML table as follows, and, paired with the same CSS as in the first example, is fairly clean, and free of even more unnecessary inline presentation attributes. While it is a little more code in terms of the Repeater tags, it does give more control of the output (Figure 4.5).
<table class="grid-class">
<tr>
<th>Name</th>
<th>Common Name</th>
<th>Tech Type</th>
<th>Notes</th>
</tr>
<tr class="item">
<td>HyperText Markup Language </td>
<td>HTML </td>
<td>Markup </td>
<td>Used to markup documents. Loose syntax. </td>
</tr>
<tr class="item-alt">
<td>eXtensible HyperText Markup Language </td>
<td>XHTML </td>
<td>Markup </td>
<td>HTML as an XML syntax, XML-like strict rules. </td>
</tr>
<tr class="item">
<td>Cascading Style Sheets </td>
<td>CSS </td>
<td>Presentation </td>
<td>Separates design, look and feel information
into separate documents from the markup. </td>
</tr>
<tr class="item-alt">
<td>JavaScript </td>
<td>JS </td>
<td>Behavior, Interaction, Events </td>
<td>Sometimes called the behavior layer, this controls
user interaction, events, and behavior of Web pages. </td>
</tr>
</table>This is a clean example of HTML code generated from ASP.NET server-side logic, showing that reasoned application of the features does provide some control of the output.
Looking over the tag-based code, it is obvious why Microsoft’s pulling the application logic into other files and using these front-end ASPX files with tags is not a bad concept. Some front-end teams could certainly manipulate and modify this code without having to learn C# or Visual Basic.NET.
There are some other areas where ASP.NET commonly generates UI code for the programmers. Instead of sticking to simple HTML tags, ASP.NET has features that output HTML tags and provide server-side access to the document in ways quite similar to the DOM, although with their own proprietary syntax. Examine the following screen and code (FIGURE 4.6):
<script runat="server">
void Clicker(Object sender, EventArgs e)
{
Response.Redirect("http://www.cherny.com");
}
void Page_Load()
{
if (!IsPostBack)
{
// Web Controls
myLink.Text = "Pro Web Book Dot Com";
myLink.NavigateUrl = "http://www.prowebbook.com";
myLink.CssClass = "webControl";
// HTML Anchor Controls
myOtherLink.InnerText = "NavigationArts";
myOtherLink.HRef = "http://www.navigationarts.com";
myOtherLink.Attributes.Add("class","htmlControl");
// Label Control
myLabel.Text = "Hey Look! This span is meaningless!";
// Literal Control
myLiteral.Text = " (A Bad Link!)";
// Paragraph HTML Control
myPara.InnerHtml = "Pro Web Book " +
"Links <strong>Rock!</strong>";
// Paragraph HTML Control 2
myPara2.Visible = false;
}
}
</script>
<form id="form1" runat="server">
<ul>
<li><asp:HyperLink runat="server" id="myLink" /></li>
<li><a runat="server" id="myOtherLink" /></li>
<li><asp:LinkButton Text="Click This"
OnClick="Clicker" runat="server" /></li>
</ul>
<p><asp:Label id="myLabel" runat="server" /></p>
<p id="myPara" runat="server" />
<p id="myPara2" runat="server">This will be hidden.</p>
</form>
There is a lot to look at here, to illustrate a number of different points:
The whole thing must be a
<form>element withrunat=serverin order to use the<asp:LinkButton />control. This control should be avoided if possible, as will be seen in a moment when the resulting XHTML is examined.Note the first ASP.NET server tag in the unordered list is in the form of
<asp:HyperLink />.This is a Web Server Control that generates an HTML link and provides program access to all the attributes and text of the tag, as demonstrated in the <script> block above where the myLink references are located.Note the second link has no
hrefattribute and is also programmatically controlled from the<script>block above. This is a server-side HTML control (note therunat=serverattribute) that also allows programmatic access to the item’s attributes. This grants more control over the output but fewer server-side features.
Adding an ID and the code runat=server to just about any HTML tag provides access to the tags, which is exceptionally powerful because programmers can control the tag’s visibility, content, and attributes with a few lines of code, located at the programming layer.
Both link controls do virtually the same thing, and while the Web controls provide added features over and above the HTML controls, the Web control is less predictable and features presentation attributes frequently used by programmers after the quick fix. When using Web controls, programmers should try to stick to the CssClass attributes, avoid presentation attributes, and use HTML controls for greater predictability in the code output, unless it is necessary for the specific case.
Keep watching the paragraphs at the end of the document:
<p><asp:Label id="myLabel" runat="server" /></p> <p id="myPara" runat="server" /> <p id="myPara2" runat="server">This will be hidden.</p>
These are all executed server-side as well.
The <script> is the server-side code that is not sent to the browser, and frequently this code is in a separate file altogether. It programmatically generates the following XHTML (aside from some other .NET code that is meaningless to this discussion):
<script type="text/javascript">
<!--
var theForm = document.forms['form1'];
if (!theForm) {
theForm = document.form1;
}
function __doPostBack(eventTarget, eventArgument) {
if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
theForm.__EVENTTARGET.value = eventTarget;
theForm.__EVENTARGUMENT.value = eventArgument;
theForm.submit();
}
}
// -->
</script>
<ul>
<li><a id="myLink" class="webControl" href="http://www.prowebbook.com">Pro Web Book Dot Com</a></li>
<li><a href="http://www.navigationarts.com" id="myOtherLink" class="htmlControl">NavigationArts</a></li>
<li><a href="javascript:__doPostBack('ctl00','')">Click This</a>
</li>
</ul>
<p><span id="myLabel">Hey Look! This span is meaningless!</span>
</p>
<p id="myPara">Pro Web Book Links <strong>Rock!</strong></p>Some more observations about the code output:
Note that there are several ways to output a simple link in ASP.NET: the first two as described above with Server and HTML controls and another that creates the third link, the
<asp:LinkButton />control.The third link code generated above demonstrates why it is best to avoid using the
<asp:LinkButton />control under most circumstances, as it produces anhrefattribute with a JavaScript link, which breaks every rule in this book.The
<asp:Label />control used in the first paragraph above outputs a<span>for no reason. The label control is considered nice because programmers can assign presentation aspects to it, but it is possible to use the<asp:Literal />control instead, which outputs the lovely message “(A Bad Link!)” above. It is often claimed that one downside to using this control is that there are no presentation aspects for it—which is exactly why using it is a great idea.Programmers can also control the text of tags with HTML controls for paragraphs, as demonstrated by the paragraph above with the
IDof myPara.Note that programmers can also hide and show HTML controls: The last paragraph in the server-side code is set to
visible = falseand not sent to the browser.
HTML controls offer ASP.NET code a lot of power, but for various reasons ASP.NET tutorials downplay their use. From a Web standards perspective, however, these are very powerful tools and often preferable to Web server controls.
The bottom line is that programmers, developers, and designers should collaborate as closely as possible when programming server-side applications, to make sure the UI markup follows Web standards-based best practices. This often means picking the right tool on the server. Keep the UI out of the application and use classes and clean code; this keeps the design in the hands of the UI team, reducing risk and the potential need to involve a programmer just for a UI change. When applications are complex or based on older code bases, compromises may be necessary, but ultimate goals, standards, and guidelines should be set toward the goal of bringing consistency in the long run.
When a Web site needs to be updated by nontechnical users, gets larger, or includes content that needs to be reused, cataloged, searched, or shared, the typical solution is content management software. Content management software is one of the most common Web applications that any Web development team will encounter. This is because it is a common solution to business users’ request for more control over a site.
Unfortunately, content management applications often insist on producing their own markup or require a fair amount of effort to shoehorn into a Web standards-based world. Fortunately, this is often not as hard as it seems initially, at least with a decent content application. Honestly, the hard part is often determining where to look for the right pieces of code that actually generate output.
There are countless content management systems (CMS) of varying degrees of flexibility and Web standards compliance. The flexibility, from a standards perspective, depends on the nuances of the software’s capabilities as well as the implementation, which is the responsibility of the Web team.
The better CMS solutions allow a team to generate the UI code they want—as opposed to what the tool wants. There are a number of ways Web standards can assist with a content management solution:
Abstracting content’s presentation away from the content store
Employing fewer CMS templates through effective use of CSS
Reusing content, because its markup will not be presentation-specific
Simplifying content authors’ jobs, through fewer presentation aspects being required of them
Expanding the ability of redesigns with less CMS team involvement
The simple process of storing content in a central content repository, with clean markup, is in and of itself a good way to facilitate content reuse, because the markup will be simple and can be styled with CSS on different portions of pages based on context. Beyond that, here are some common best practices and scenarios involved in professional content management and design with CSS:
Design with CSS based on context. For example, an article description can be rendered as an
<h1>level header set in a large maroon font on the article page, but a smaller black font on the archive page, because the CSS can control that difference.Store content in as plain a format as possible. Use as few CSS classes as you can, and minimal if any presentation-specific element attributes.
Stick to semantic markup alone, leaving the content marked up in a meaningful and portable format that can be styled and reused at will. Recall that expert CSS coders can apply different styles based on contextual position in the site template via an
IDor class.Teach content authors only basic HTML structure tags. Ideally, content authors will need to learn few if any CSS classes. They just need to know that the first-level header in the content area is an
<h1>.Or, that making a plain bulleted list will result in little icons for bullets, and the header in the related content region on the right is dark blue. Design can all be applied via CSS and not stored in the CMS content repository. Content authors can concentrate on content, not design.Context on a given page is a useful tool, but context within a site can be equally important. A common design scenario these days involves different sections of a site having different color themes extended from the primary brand. Content itself, stored in a database, does not need to know these things, and should be portable between site sections. CSS can be driven from a
<body>tag class orIDset by site section, which can toggle different color themes down through all semantic tags for that portion of the site.
Content management tools can pose a challenge when it comes to figuring out how to control the output and produce standards-based code. The hard part is often determining where to start and whether the output can be controlled. Typically, a CMS outputs pages formatted with code sourced from one of several areas:
The most challenging portions of a CMS application in terms of outputting valid standards-based code are often the built-in features over which a team has little to no control. The features to watch out for include what someone claimed to be the great thing about a tool since supposedly the tool can be installed and you have a Web site out of the box.
Risky portions can include
Administrative modules embedded on public pages
Traffic-tracking code or built-in scripts
Advertising modules
Anything that generates menus
Special controls that might produce lists of content (like a News or product archive)
Search results
Tip
Anything “out of the box” is suspect unless the tool has already been brought up to modern standards.
A powerful tool will let a Web team have access to the code that produces this output or insert custom modules that can replace or extend built-in functionality. Ideally, there are built-in templates or snippets of code that can be updated. Be especially wary of tools that claim to allow customization of the look and feel through some sort of control panel, unless it actually exposes code that can be modified.
Most CMS tools associate pages with templates, each of which is a reusable layout. Authors pick the correct template for the section or type of page. The more templates, the more the content authors need to keep track of—and the more confusing site maintenance becomes. Intelligent use of CSS and Web standards can actually mean fewer templates.
Templates are typically driven by the grid of the page, and this typically means different markup. In the Web standards and CSS world, this isn’t necessarily the case.
Imagine a three-column layout such as what follows here (FIGURE 4.7):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Template One</title>
<link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body class="typeA">
<div id="wrapper">
<ul id="nav">
<li><a href="...">Navigation 1</a></li>
<li><a href="...">Navigation 2</a></li>
<li><a href="...">Navigation 3</a></li>
<li><a href="...">Navigation 4</a></li>
</ul>
<div id="content">
<h1>Content Area</h1>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Nam sit amet nulla. Ut ut urna ac lectus</p>
<p>Ut ut urna ac lectus tincidunt sollicitudin. Sed rutrum
interdum lorem. Integer aliquam pellentesque
neque.</p>
<p>Curabitur a neque a libero gravida dignissim. Sed
eget tellus.</p>
</div>
<div id="related">
<h2>Related Links</h2>
<p>Related Links and Content</p>
<ul>
<li><a href="">Section 1</a></li>
<li><a href="">Section 1</a></li>
</ul>
</div>
</div>
</body>
</html>
The above document sample has three <div> elements with IDs: nav, content, and related (or #nav, #content, and #related, in CSS selector terms). These can be easily styled with CSS to be three columns. The content inside of the #content and #related <div> elements might be created by a content author and is here represented by “Lorem ipsum” and the “Related Links and Content” text respectively. Furthermore, the related column link might even be generated dynamically server-side, based on content relationships, and there may be cases where this column is not needed.
Note the class on the <body> element. A content author might need to select this template in order to queue up a page with the appropriate number of columns. Program logic can tweak the <body> class of the document to restructure the page into navigation and a single column of content so multiple templates do not need to be created in the CMS tool, and so a content author does not need to select a different template (FIGURE 4.8).
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Template Two</title>
<link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body class="typeB">
<div id="wrapper">
<ul id="nav">
<li><a href="...">Navigation 1</a></li>
<li><a href="...">Navigation 2</a></li>
<li><a href="...">Navigation 3</a></li>
<li><a href="...">Navigation 4</a></li>
</ul>
<div id="content">
<h1>Content Area</h1>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Nam sit amet nulla. Ut ut urna ac lectus</p>
<p>Ut ut urna ac lectus tincidunt sollicitudin. Sed rutrum
interdum lorem. Integer aliquam pellentesque
neque.</p>
<p>Curabitur a neque a libero gravida dignissim. Sed
eget tellus.</p>
</div>
<div id="related">
</div>
</div>
</body>
</html>The #related <div> is collapsed and no content is output. At the CMS level, changing the <body> class to typeB switches the page layout without changes to the markup and means one less template than might otherwise be required. This also preserves the separation of markup from presentation. Here is the style sheet required:
body { font: normal .9em Georgia; }
body.typeB #related { display:none; }
body.typeB #content { width: 600px; }
#nav { list-style-type: none; width: 100px; float: left;
margin: 30px 0 0 5px; padding: 0; }
#content { width: 400px; float: left; margin-left: 10px;
border: 1px solid red; padding: 3px; }
#related { width: 150px; float: left;
border: 1px solid red; margin-left: 10px;
padding: 3px; }Content management tools are just another software mechanism to deliver a Web site. They are a fact of life in larger organizations, and most are full-featured development platforms that can be leveraged to allow standards-based output, which can only help make a site more accessible or compliant. Whether the tool features raw output or content being transformed from XML with XSLT (eXtensible Stylesheet Language Transformations), the output should be clean and thought through. As a complement, effective use of Web standards can also reduce the number of CMS templates and make it easier to author content.
When working in Web content environments, most nontechnical content authors use some form of lower-end WYSIWYG software tool to help facilitate content entry. These tools can range from browser-based editors to tools like Adobe Contribute for simple site maintenance. They are not development platforms such as Adobe Dreamweaver or Microsoft Expression Web, and have far fewer features. Just like any other software, these tools have configuration options and varying degrees of Web standards compliance.
As a general rule, the strongest editor setup for content authors is one where as many formatting features as possible are disabled, because the formatting features rely on code that a Web team won’t be able to control. Effective support for CSS is the key.
Browser-based editors have been around for a while. Microsoft first introduced an ActiveX-based editing component in Internet Explorer 4. Since then, native JavaScript support has been added and editors are usually script-based, Java-based, Flash-based, or ActiveX-based. Script-based components for browser-based editing are showing up with support in most modern Web browsers, including Safari and Opera. For widest compatibility, one of these should be chosen.
Unfortunately, out of the box these browser-based editors are not very robust. Internet Explorer outputs <font> tags and Mozilla generates inline styles. They render exactly what the browser can render, but the editor features must largely be built from the few hooks that are available in the browser’s DOM. That being the case, it is exceptionally hard work to churn out a custom editor, although they are getting better every day. You can find a modern editor to create valid code and support CSS.
Web developers should take steps to prevent these browser-based editors from jeopardizing all the hard work that has gone into defining styles and coding standards for their sites. They may have to go so far as to integrate new user steps, or even new software.
Considerations include
Perform reviews of the WYSIWYG editor’s code output under a variety of situations. It’s not unusual for these editors to generate invalid code; however, the marketplace is maturing, and many can output valid HTML or even XHTML with configuration changes.
Some editor tools include a source-code view. This may need to be disabled or enabled depending on the skill levels of the authors. Some tools include a permission model, which can enable the source code view for some users and not for others.
Features that control presentation should be limited. Disable features that control font face, font colors, and background colors. These should be controlled only from CSS.
The editor should be able to apply CSS classes. A good editor will support association of a CSS file with the editor. Some will require developers to configure which items appear in the CSS class menus. The best will support context and only allow application of some classes based upon the CSS rules, such as not allowing a rule
p.errorto be applied to a<span>.Support for CSS class application should include some facility to apply CSS to specific elements. That is, it should be just as easy to apply a class to a
<ul>as an<li>nested inside via a selection process of some form. A common way to enable this is a simple click to select DOM tree in the status bar (body > div > ul > li > a).CSS files that are associated with an editor may need to be an extract of the main CSS files because the rules may be too complex to be interpreted, and full context rules, such as
<p>elements inside of#contentas opposed to#related, might not be supported or possible. Depending on the editing context, multiple CSS files may be another solution.The editor should support basic XHTML semantic tags such as the built-in headers (1–6), paragraph formatting, at least two types of lists, blockquote, preformatted text, and addresses.
A good editor will also strip garbage and invalid tags from content pasted from the clipboard, or have multiple options for cleaning pasted content. Often, content copied from word processors or Web pages will retain its formatting information when pasted into WYSIWYG editors. This information, when introduced into valid code, often invalidates it, and can modify styles that should be applied only from outside the content via the CSS.
You may want to tell content authors that if their editing application won’t strip invalid tags from incoming content, they should strip the formatting by pasting that content into a plain text editor prior to pasting into the WYSIWYG editor.
Ideally, locate a browser-based editor that can support as many browsers as possible and achieve the above feature sets. It is not uncommon to find WYSIWYG editors configured only for IE; however, today editors are available for Windows and Mac OSX in just about every browser.
Following the above rules and evaluation criteria can mean the difference between creating a reliable, standards-complaint site and having a content editor program destroy a lot of hard work. The quality and performance of any editor program you’ve already got in production should be evaluated against these standards and modified to produce code that is as close to valid as possible.
Larger Web sites often need to propagate a certain look and feel to third-party sites or business applications hosted elsewhere, such as an Investor Relations site or perhaps a job board. These sites can be branded to look like the main site, and users are intended to not know that they have navigated to another site altogether.
Web standards-based approaches are ideal for such scenarios because not only can the artwork and scripts be hosted on the main corporate servers, but so can all the CSS files, or at least the CSS that controls the main look, feel, and corporate brand standards. In these cases, a company can have third parties link to some or all of the CSS files, and tweak them as necessary over time, with the changes showing up without hosting the third-party applications.
In such cases, you will probably need to provide the third parties with documentation of the correct style classes and image headers for certain design touches. You should also supply sample code, with example templates that represent how the pages and designs should be built.
Just like any organization or software platform, however, third parties are going to have varying degrees of ability to accommodate a Web standards approach. For example, their platform may not be compatible with a corporate style sheet. In these cases, compromise may be necessary. Again, this may mean simple extracts of CSS files or creating different markup templates for the exceptions. In the long run, however, a transition plan should be considered and discussed with third-party vendors who can’t keep up with the rest of the industry.
A Web standards-based approach means a strict separation of content from presentation, so it follows that it also means the separation of business logic from presentation. Web teams building Web-based applications and software can benefit greatly from building their user interfaces with modern approaches that reference CSS as opposed to inline presentational attributes.
Less inline presentation means less to risk to business logic when design changes are pushed into software. Additionally, in a potentially complicated software environment it can mean that the expert front-end developers can help make these UI changes without having to update backend code or even involve backend programmers.
A challenge going forward is to know where to start to update Web applications and exploit the features of the technologies that are available. New features of Web standards-based techniques can be a powerful ally for a Web team both in Web applications built from the ground up and in commercial off-the-shelf content management tools.