[UPHPU] Validation

Brandon Stout hplsbyufan at imapmail.org
Tue Jun 6 08:05:37 MDT 2006


Mac Newbold wrote:
> 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/

I go for table-less layout when it seems simple enough, but there's
another reason for table-based layout.  I use a table for my resume:

http://res.mscis.org

I do this even though I got it to look the same in a table-less design
across all major browsers, including "browser x" :) .  Why?  Some people
do not want a web resume - they insist on proprietary formatted .doc or
.pdf files.  In these cases, the table layout preserves my formatting
better when I do either of these with OpenOffice.org:

 open http://res.mscis.org directly
 copy/paste it

OOo is not a browser, and therefore doesn't support CSS like a browser
ought to.

While I'm on the topic, http://res.mscis.org is also the beginning of a
project I own:  phpMyResume on SF.net.  If anyone would like to help
with this project let me know, but probably reply to me, not the list.

Brandon Stout
http://mscis.org


More information about the UPHPU mailing list