Table Layouts vs. Div Layouts: From Hell to… Hell?

Over the last several years, developers have moved from table-based website structures to div-based structures. Hey, that’s great. But wait! Do developers know the reasons for moving to div-based structures, and do they know how to? Often it seems that people are moving away from table hell only to wind up in div hell.

This article covers common problems with layout structure in web design. The first part goes through what table and div hells are, including lots of examples. The next section shows how to write cleaner and more readable code. The final part looks at what features await in future. Please join us on this journey from hell to heaven.

Table Hell

You’re in table hell when your website uses tables for design purposes. Tables generally increase the complexity of documents and make them more difficult to maintain. Also, they reduce a website’s flexibility in accommodating different media and design elements, and they limit a website’s functionality.

MAMA (Metadata Analysis and Mining Application) is a structural Web page search engine from Opera Software that crawls Web pages and returns results detailing page structures. If we look into MAMA’s key findings, we see that the average website has a table structure nested three levels deep. On the list of 10 most popular tags, table, td and tr are all there. The table element is found on over 80% of the pages whose URLs were crawled by MAMA.

Semantically speaking, the table tag is meant for listing tabular data. It is not optimized to build structure.

EASE OF USE

Using tables to build structure is quite intuitive. We see tabular data every day, and the concept is well known.

And the existence of table attributes makes for a rather flat learning curve because the developer doesn’t have to use a separate style sheet. With divs, the developer must use the style attribute or an external style sheet, because the div tag doesn’t have any attributes attached to it.

Also, tables don’t break when the content is too wide. Columns are not squeezed under other columns as they are in a div-based structure. This adds to the feeling that using tables is safe.

MAINTAINABILITY

Table contains different tags: the table tag being the wrapper, tr for each row and td for each cell. The thead and tbody tags are not used for structural purposes because they add semantic meaning to the content. For readability, each tag is normally given its own line of code, with indention. With all of these tags for the table, several extra lines of code are added to content. The colspan and rowspan attributes make the code even more complex, and any developer maintaining that page in future has to go through a lot of code to understand its structure.

<table cellpadding="0" cellspacing="0" border="0">
 <tr>
  <td colspan="3" height="120px">....</td>
 </tr>
 <tr>
  <td class="menu" valign="top">...</td>
  <td class="content" valign="top">...</td>
  <td class="aSide" valign="top">...</td>
 </tr>
 <tr>
  <td colspan="3">...</td>
 </tr>
</table>

<div id="header">...</div>
<div id="menu">...</div>
<div id="content">...</div>
<div id="aSide">...</div>
<div id="footer">...</div>

As we see from the example, the table-based layout contains more code than the div-based version. Imagine now if this difference in size stays consistent as the code base grows (by a ratio as much as 2:1). In a div-based structure, it is also possible to skip the menu div and use an unordered list (ul) as a container instead.

Nested tables are code smell that a website is stuck in table hell. The number of lines of code is endless, and the complexity is overwhelming. Tables are far from clean code and don’t bring anything semantic to the content unless you’re dealing with actual tabular data. And if you’ve happened to inherit the maintenance of a website that has poor readability, it’s a nightmare. Nested tables are a poor substitution for semantically meaningful, block-level elements.

Another drawback to tables is that they make it harder to separate content from design. The border, width, cellpadding and cellspacing tags are used in about 90% of all websites that use tables, according to MAMA. This adds code to the HTML that should instead go in the style sheet.

Excess code slows down development and raises maintenance costs. There’s a limit to how many lines of code a programmer can produce per hour, and excess code is more complicated for others to understand. Developers may not even understand their own code after a while.

More lines of code mean larger file sizes, which mean longer download times. Developers should keep in mind new media, such as mobile devices, which usually have low bandwidth. Websites will have to support media other than traditional monitors in future, and bad code limits the possibilities. A large code base has more bugs than a small one. Developers tend to produce a certain number of bugs per line of code. Because tables increase the code base, such structures likely contain more bugs than layouts with less code lines.

How to recover the deleted stored procedure, function, trigger, view

In this article, we will learn how to recover views, stored procedures, functions & triggers via SQL server log.

Step 1 :
Lets create few objects to explain the recovery process.

CREATE TABLE [dbo].[Student](       [Sno] [int] NOT NULL,       [Student ID] nvarchar(6) Not NULL ,       [Student name] [varchar](50) NOT NULL,       [Date of Birth]  datetime not null,       [Weight] [int] NULL)   GO Create View Vw_Student as Select * from [Student] GO Create Procedure SP_Student @StudentID nvarchar(6) as Select * from Student Where [Student ID] =@StudentID GO Create FUNCTION [dbo].[Fn_Student](@StudentID nvarchar(6)) RETURNS int AS Begin     Declare @Weight int     Select  @Weight = [Weight]         from Student Where [Student ID] =@StudentID     Return  @Weight End GO CREATE TRIGGER trg_Student ON Student FOR INSERT AS RAISERROR (50009, 16, 10) GO

Step 2:
Lets drop these objects.

Drop View [dbo].[Vw_Student] GO Drop Procedure [dbo].SP_Student GO Drop Function [dbo].[Fn_Student] GO Drop Trigger [dbo].[trg_Student] GO

Step 3:
Check the existence of these objects to make sure that objects are dropped properly.

Select * from [Vw_Student] GO EXEC SP_Student 1 GO Select dbo.[Fn_Student](1)

Step 4:
Create the given below stored procedure to recover the dropped objects.

-- Script Name: Recover_Dropped_Objects_Proc -- Script Type : Recovery Procedure -- Develop By: Muhammad Imran -- Date Created: 04 Dec 2012 -- Modify Date: -- Version    : 1.0   Create PROCEDURE Recover_Dropped_Objects_Proc @Database_Name NVARCHAR(MAX), @Date_From DATETIME='1900/01/01', @Date_To DATETIME ='9999/12/31' AS   DECLARE @Compatibility_Level INT SELECT @Compatibility_Level=dtb.compatibility_level FROM master.sys.databases AS dtb WHERE dtb.name=@Database_Name   IF ISNULL(@Compatibility_Level,0)<=80 BEGIN     RAISERROR('The compatibility level should be equal to or greater SQL SERVER 2005 (90)',16,1)     RETURN END   Select Convert(varchar(Max),Substring([RowLog Contents 0],33,LEN([RowLog Contents 0]))) as [Script] from fn_dblog(NULL,NULL) Where [Operation]='LOP_DELETE_ROWS' And [Context]='LCX_MARK_AS_GHOST' And [AllocUnitName]='sys.sysobjvalues.clst' AND [TRANSACTION ID] IN (SELECT DISTINCT [TRANSACTION ID] FROM    sys.fn_dblog(NULL, NULL) WHERE Context IN ('LCX_NULL') AND Operation in ('LOP_BEGIN_XACT')  And [Transaction Name]='DROPOBJ' And  CONVERT(NVARCHAR(11),[Begin Time]) BETWEEN @Date_From AND @Date_To) And Substring([RowLog Contents 0],33,LEN([RowLog Contents 0]))<>0 GO   --Execute the procedure like --EXEC Recover_Dropped_Data_Proc 'Database Name'   ----EXAMPLE #1 : FOR ALL Dropped Objects EXEC Recover_Dropped_Objects_Proc 'test' --GO ------EXAMPLE #2 : FOR ANY SPECIFIC DATE RANGE EXEC Recover_Dropped_Objects_Proc 'test','2011/12/01','2013/01/30' --RESULT