[UPHPU] Validation

[Mac Newbold]

Today at 1:33pm, Tyler Gee said:

>> I disagree, of course, someone has to.  I can do a tableless site very
>> quickly and the code is cleaner, more easy to understand, and much easier
>> to modify and works well in all the browsers I test (which of course only
>> the most popular).  However, I do not think tables are evil, like many
>> people do.  Tables were made for tabular data and work very well for that.
>> In fact, if I had to choose tableless over tables for tabular data, I
>> usualy choose tables.  That is what they were made for.
>> 
>> Jonathan
>
> I would agree with the disagreement. :)  Tables are great for tabular
> data but definitely not for layout.  Working with div's is way easier
> and allows way more control.

I have yet to see something you can do with a div that you can't do with a 
table, so I would argue that there is at least as much control with a 
table as there is with a div. (Contrived examples excluded. And no, I'm 
not advocating using single-cell tables instead of divs when divs are 
appropriate.)

My biggest problem with people who want to eliminate tables from their 
code, except for "tabular data", is that there still are things you can't 
do with divs on current browsers that you can do with tables. In fact, I 
don't even think it is a browser issue, but a shortcoming in the standards 
themselves if they are advocating the deprecation of tables entirely.

A frequent component in designs that I am asked to implement for web sites 
are what I'll call a "tabular layout" or a "fluid tabular layout" (FTL for 
short). This would be where there's somewhat of a grid built into the 
page, where things line up with each other. Take a web page, and draw the 
major lines that divide the content areas... often it breaks down into a 
2, 3, 4, 6, 9, etc. -celled table along those guidelines. Now you can 
build that just fine with divs. But what you cannot accomplish without 
tables is allowing the size of those areas to be fluid, growing to fit the 
content as needed, while still making sure that all the cells in the same 
row stay the same height, and all the cells in the same column stay the 
same width, without fixing them to a pre-determined static width. Tables 
do this so painfully simply that it could be called effortless. I supply 
some "best guess" widths and heights in the form of numbers, percentages, 
or whatever, and it handles the maintenance of the actual dimensions of 
each cell, maintaining all the consistency for me. That is what I call a 
"fluid tabular layout", and so far nobody has been able to show me a good 
one that is done without using tables. I don't restrict my definition of 
"data" too much, so to me "tabular data" is what a fluid tabular layout 
is, though others would say data can't be graphical, or must be textual, 
or can't be this or that, but to me it is all data, and I don't feel bad 
at all using a table for it, especially since there's not another good way 
to meet all those requirements without using tables.

One thing I've started to see more and more are atrociously huge CSS files 
that are bloated, disorganized, hard to follow, and just plain too big. It 
is a lot harder to add easy-to-follow structure into your CSS file, 
because you can't nest definitions like you can nest HTML tags. You can't 
break CSS into functional units like you can with PHP code. The most you 
can do is break things into separate files, but then chasing through all 
the files to keep track of the cascading and inheritance that is going on 
becomes a huge headache. The HTML is there for a reason, and if we use 
HTML appropriately, it doesn't take a CSS file that is longer than your 
HTML page to make it look nice.

Back on the main subject of this thread, validation, I think it is good to 
pressure browser makers to produce compliant engines that implement the 
standard correctly and consistently. When everyone implements the same 
standard, our world will get a lot simpler and we'll be able to stop 
wasting time checking pages in every browser. I yearn for the day when a 
standards-compliant page that looks horrible in Browser X (I won't name 
names) is the fault of Browser X and SuperCorp Y that makes Browser X, not 
the fault of the site or its creator. I long for a time when pages coded 
to broken standards that have been "embraced and extended" and therefore 
look terrible on compliant browsers, are the fault of their creators, not 
shortcomings of the compliant browsers that refuse to cave in to the 
rediculous "features" that Browser X advocates. When users take that 
attitude, and choose the browsers that do best with their pages, I will 
truly rejoice, and the web will be a much more beautiful and fun place.

Until then, I make my code comply to a standard as much as possible, with 
an eye to the future, and another on practicality. In a job where time is 
money, and saving money for my clients helps my business, I will do things 
in the best, quickest, most efficient, way I can, and until coding in 
XHTML strict meets those criteria for me and my coworkers, we'll use XHTML 
transitional, or HTML transitional, or whatever it is that gives us the 
best results in the least amount of time with the fewest headaches.

On a side note, it's nice that we're able to carry off conversations like 
this on such charged topics without degenerating into flame wars. And 
nobody has mentioned top or bottom posting or even trimming once. So that 
is one reason why UPHPU is better than so many other lists. The friendly 
environment really does make a huge difference and I think helps us all to 
get more out of our associations with each other. So thanks to everyone!

Thanks,
Mac

--
Mac Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/