Patrick Griffiths weighs in on the CSS vs table layout debate in his blog
entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php . A
quite good article.

Neal <neal413@yahoo.com> wrote:
[color=blue]
>Patrick Griffiths weighs in on the CSS vs table layout debate in his blog
>entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php . A
>quite good article.[/color]

I disagree. A flimsy article, no mention of certain issues that make
table based layouts so author friendly:

Intuitive grid type visualization.
Shrink to fit and expand when needed behaviour/options.
Intuitive hor/ver centering of *all* elements (block/inline).
No mention of the fact that css itself contains a method to replace html
tables used for layout (css tables), but that they are not supported by
IE.

Note that I'm no apologist for table layouts (I plonked B. Pearson
months ago), I never advise their use for layout purposes, and I've
mastered the skill to use css exclusively for layout years ago. But the
fact remains that using css for layout in practice throws up mayor
obstacles for the average author.

Also, first thing I had to do to be able to read the article was to
disable his stylesheets (micro fonts).

--
Spartanicus

Spartanicus wrote:
[color=blue]
> Neal <neal413@yahoo.com> wrote:
>
>[color=green]
>>Patrick Griffiths weighs in on the CSS vs table layout debate in his blog
>>entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php . A
>>quite good article.[/color]
>
>
> I disagree. A flimsy article, no mention of certain issues that make
> table based layouts so author friendly:
>
> Intuitive grid type visualization.
> Shrink to fit and expand when needed behaviour/options.
> Intuitive hor/ver centering of *all* elements (block/inline).
> No mention of the fact that css itself contains a method to replace html
> tables used for layout (css tables), but that they are not supported by
> IE.[/color]

That shows in my opinion how underdeveloped IE is, and overtaked by
other browsers. The sad thing is that because most people still use
this "stone age" browser, Microsoft is now responsible for preventing
the development of WWW.
[color=blue]
> Note that I'm no apologist for table layouts (I plonked B. Pearson
> months ago), I never advise their use for layout purposes, and I've
> mastered the skill to use css exclusively for layout years ago. But the
> fact remains that using css for layout in practice throws up mayor
> obstacles for the average author.
>
> Also, first thing I had to do to be able to read the article was to
> disable his stylesheets (micro fonts).[/color]

The layout is just his suggestion, as you have yours on your sites.
But why disable it, if the font-size is the only problem? At least he
use percent for font-size, easy to resize even in IE :-)

--
/Arne

"Spartanicus" <me@privacy.net> wrote in message
news:f2dja05aapgq6jau01bs2f5gcrfjven1hj@news.spart anicus.utvinternet.ie...
: Neal <neal413@yahoo.com> wrote:
:
: >Patrick Griffiths weighs in on the CSS vs table layout debate in his blog
: >entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php . A
: >quite good article.
:
: I disagree. A flimsy article, no mention of certain issues that make
: table based layouts so author friendly:
:
: Intuitive grid type visualization.
: Shrink to fit and expand when needed behaviour/options.
: Intuitive hor/ver centering of *all* elements (block/inline).
: No mention of the fact that css itself contains a method to replace html
: tables used for layout (css tables), but that they are not supported by
: IE.
:
These are good points and my advice would be to use tables sparingly, where
CSS fails to deliver.

--
Long
www.webcharm.ca - Integrated content management web hosting

Spartanicus wrote:
[color=blue]
> Neal <neal413@yahoo.com> wrote:
>
>[color=green]
>>Patrick Griffiths weighs in on the CSS vs table layout debate in his blog
>>entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php . A
>>quite good article.[/color]
>
>
> I disagree. A flimsy article, no mention of certain issues that make
> table based layouts so author friendly:
>
> Intuitive grid type visualization.[/color]

If you need to visualize elements as you're building your page, then it
means you're mostly building a site in a WYSIWYG interaction mode which
is not best for design to begin with.
[color=blue]
> Shrink to fit and expand when needed behaviour/options.[/color]

This suggests your layout is not scalable when not using table for
laying out your content. There are ways to make a site entirely scalable
and independent of the available workarea dimensions of the ua.
Obviously, there are other ways to shrink to fit and expand when needed
besides wrapping content with a
<table width="100%" ...>.
This need to table to make the content "fluid" is also at the source
of nested tables too.

[color=blue]
> Intuitive hor/ver centering of *all* elements (block/inline).[/color]

Don't know what you're talking about here. Are you saying that centering
a table within its parent element should also center its content? Are
you referring to
<table align="center" ...>
[color=blue]
> No mention of the fact that css itself contains a method to replace html
> tables used for layout (css tables), but that they are not supported by
> IE.
>[/color]

I don't understand what you're talking about here.
[color=blue]
> Note that I'm no apologist for table layouts (I plonked B. Pearson
> months ago), I never advise their use for layout purposes, and I've
> mastered the skill to use css exclusively for layout years ago. But the
> fact remains that using css for layout in practice throws up mayor
> obstacles for the average author.
>[/color]

But this is a different issue (ease of implementation versus best
practice for the avg author).
IMO, using table layout for rendering non-tabular data is wrong, bad,
nightmare to upgrade, makes parsing, rendering longer, make files
bigger, etc...

[color=blue]
> Also, first thing I had to do to be able to read the article was to
> disable his stylesheets (micro fonts).
>[/color]

One disadvantage of using nested table in table design which is never
mentioned is that all DOM node fetching and manipulation (insert,
delete, replace, remove,etc) are more complex, longer since the dom tree
of nodes is deep. E.g. trying to print a selection in a nested table
will usually fail and make the application crash on most browsers.

DU

DU wrote:
[color=blue]
> Spartanicus wrote:
>[color=green]
>> no mention of certain issues that make table based layouts so
>> author friendly:
>>
>> Intuitive grid type visualization.[/color]
>
> If you need to visualize elements as you're building your page, then
> it means you're mostly building a site in a WYSIWYG interaction mode
> which is not best for design to begin with.[/color]

There's no reason why someone can't code proper html (4/strict, using
elements as they are intended). Then layout the presentation using a
grid. If you ask me, this is the best way forward for the layperson html
author. But it cannot go in this direction because MSIE/Win does not
support css table-like presentation.
[color=blue]
> Obviously, there are other ways to shrink to fit and expand when
> needed besides wrapping content with a <table width="100%" ...>.[/color]

Of course:

display: table; width: 100%; /* etc */

That's sort of the point, I think.
[color=blue][color=green]
>> Intuitive hor/ver centering of *all* elements (block/inline).[/color]
>
> Don't know what you're talking about here. Are you saying that
> centering a table within its parent element should also center its
> content?[/color]

It's a trivial matter, using table cells, to center things horizontally
and vertically. The vertical thing is especially desirable, as a glance
through the archives shows. If css tables were implemented -- really, if
they were implemented some time ago -- it would be an alternative to
what we see today. I imagine that it would be *easier* to program a
wysiwyg application to code real content, put all blocks in display:
table-cell, and let the user push blocks around to their hearts' content.
[color=blue]
> But this is a different issue (ease of implementation versus best
> practice for the avg author).[/color]

I think you missed Spartanicus' point: that css as currently implemented
is hard. I'd have to agree. Floats are tricky stuff. I used to use them
only occasionally, to flow text around a <p> text. Now I use them for
nav bars, div elements, all kinds of stuff. Browsers are buggy with
floats, it can unintended consequences, etc.
[color=blue]
> IMO, using table layout for rendering non-tabular data is wrong, bad,
> nightmare to upgrade, makes parsing, rendering longer, make files
> bigger, etc...[/color]

Who are you arguing with here? Spartanicus specifically stated that he
was opposed to table for layout.
[color=blue]
> One disadvantage of using nested table in table design which is never
> mentioned is that all DOM node fetching and manipulation (insert,
> delete, replace, remove,etc) are more complex, longer since the dom
> tree of nodes is deep.[/color]

Indeed. Now suppose web authors -- not just (would be?) professionals
here, but your aunt who posts her favorite recipes on her site -- used
simple html, and used css tables to lay it out as they do now with real
tables? They get the layout they want, html file sizes shrink, surfers
have more flexibility. The more I think about it, the more I realize
that css tables could be quite a nice solution. Shame that MSIE/Win
doesn't support them.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Neal wrote:[color=blue]
> Patrick Griffiths weighs in on the CSS vs table layout debate in his
> blog entry "Tables my ass" -
> http://www.htmldog.com/ptg/archives/000049.php . A quite good article.[/color]

It is useful for exploring the matter, but misses a few points.

1. It ignores the fact that use of layout tables can be compliant. It says,
for example: "Despite the fact that pioneers have been talking about web
standards for a long time, the majority of web sites are still developed using
tables and non standards compliant code. Because of this, user agents will be
forced to handle table based layouts for many years to come. This effectively
negates one of the biggest selling points for web standards. That of forward
compatibility. It's highly unlikely that in the near future, any of the big
browser manufacturers (um, that'll be Microsoft then) will release a browser
that renders the majority of sites unusable".

It is possible to use layout tables in *valid* HTML 4.01 Strict, XHTML 1.0
Strict, and XHTML 1.1. According to current proposals, they will also be valid
in XHTML 2.0. How can it be otherwise? *Tables* have to be supported. And
there is no robust way of distinguishing between layout tables & other sorts.
They will be valid (in the W3C sense) for decades to come.

Use of layout tables is *not* about compliance or non-compliance. It is *not*
about HTML 3.2 or later. It is *not* about DTP-like design or other types of
design. It is *easy* to provide counter-examples! Search elsewhere for
arguments that will stand up to scrutiny.

2. It misses the point when it talks about browser-support, although it gets
close. "When the browser manufacturers finally get their act together,
developing sites using CSS will get a lot easier. Still, I think most people
would agree that CSS development has a much higher barrier to entry than table
based design. In an odd way, I think this is one reason why CSS based design
is becoming so "popular" amongst web professionals. It allows them to
differentiate themselves from the amateur "FrontPage Cowboys" and take back
the web for themselves. Perhaps this is why many people see web standards as
"Ivory Tower" and why many web standards advocates come across as having a
sense of superiority and a zealous attitude towards web design."

It isn't about browsers, it is about authoring tools! *That* is the key issue.
When authoring tools enable people to develop tableless-layouts that are
robust cross-browser, people will use them, and that will be the future. Until
then, it won't be. Authors will do what works, (which layout-tables
*certainly* do), within the project constraints of cost, risk, and time. I use
Dreamweaver MX2004. It is so good with CSS2 that I am able to make sensible
choices according requirements, skills, target-audience, etc. (I even suspect
that it would be possible to use it to develop a rather poor tableless-layout
*easier* than a good table-layout).

3. *Obviously*, this is not about tables versus CSS! Every experienced user of
layout-tables *also* uses CSS! It would be stupid not to. Indeed, many
experienced authors use a whole range of layout-techniques, (absolute
positioning, floats, tables, normal flow, others). They all play their part,
either separately or in combination.

But the article gets this right: "We need to be honest and up-front about the
benefits as well as the cost. Developing CSS sites can be hard and it can time
consuming. In certain circumstances using tables for layout can make much more
sense than CSS".

4. That is really the point. *Why* should an author use one method or another
for the next page? Hopefully, not just because someone a newsgroup said
"table-layout is bad". Only a gullible idiot would fall for that one! Proper
decisions need better analysis.

I believe anti-table arguments are futile. The web appears to be 99% dominated
by table-layout, so there is no obviously no credibility in a position that
they don't work! And, of course, you can't even use more esoteric arguments
such as "separate content from presentation". Because using tables still
allows massive presentational variations using CSS as well. (I can switch left
& right columns of a table-layout, just using CSS). Tables simply set the
default layout in the absence of CSS. But so does all other mark-up!

Arguments should instead say why tableless-layout is good. What are the
specific advantages, that will stand up to scrutiny? The "anti-layout-table"
argument is discredited. What is needed is a credible "pro-tableless-layout"
argument.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Spartanicus wrote:[color=blue]
> Neal <neal413@yahoo.com> wrote:
>[color=green]
>>Patrick Griffiths weighs in on the CSS vs table layout debate in his
>>blog entry "Tables my ass" -
>>http://www.htmldog.com/ptg/archives/000049.php . A quite good article.[/color]
>
> I disagree. A flimsy article, no mention of certain issues that make
> table based layouts so author friendly:
>
> Intuitive grid type visualization.
> Shrink to fit and expand when needed behaviour/options.
> Intuitive hor/ver centering of *all* elements (block/inline).
> No mention of the fact that css itself contains a method to replace
> html tables used for layout (css tables), but that they are not
> supported by IE.[/color]

IE doesn't really allow you to start with non-tables and turn them into
something like tables. But it does allow you to start with tables and turn
then into non-tables. Here are some examples of use of valid CSS2, supported
by IE 5 & 6, to transform table-layouts by using CSS. They all use exactly the
same simple layout table.

http://www.barry.pearson.name/articl.../exhibit04.htm
http://www.barry.pearson.name/articl.../exhibit05.htm
http://www.barry.pearson.name/articl.../exhibit07.htm
[color=blue]
> Note that I'm no apologist for table layouts (I plonked B. Pearson
> months ago),[/color]

Chuckle! I don't believe that for a second. I believe you are reading this,
but now you can't respond! (Your problem, not mine).
[color=blue]
> I never advise their use for layout purposes, and I've
> mastered the skill to use css exclusively for layout years ago. But
> the fact remains that using css for layout in practice throws up mayor
> obstacles for the average author.[/color]
[snip]

They throw up obstacles for lots of experienced, professional, authors. It
often comes down to "what is the most effective way of developing my next
page?" If you do this for a living, you can't afford to ignore practical
issues in favour of pedantic purist policies that don't matter to the target
audience.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Barry Pearson wrote:
[color=blue]
> Spartanicus wrote:
>[color=green]
>>Neal <neal413@yahoo.com> wrote:
>>
>>[color=darkred]
>>>Patrick Griffiths weighs in on the CSS vs table layout debate in his
>>>blog entry "Tables my ass" -
>>>http://www.htmldog.com/ptg/archives/000049.php . A quite good article.[/color]
>>
>>I disagree. A flimsy article, no mention of certain issues that make
>>table based layouts so author friendly:
>>
>>Intuitive grid type visualization.
>>Shrink to fit and expand when needed behaviour/options.
>>Intuitive hor/ver centering of *all* elements (block/inline).
>>No mention of the fact that css itself contains a method to replace
>>html tables used for layout (css tables), but that they are not
>>supported by IE.[/color]
>
>
> IE doesn't really allow you to start with non-tables and turn them into
> something like tables. But it does allow you to start with tables and turn
> then into non-tables. Here are some examples of use of valid CSS2, supported
> by IE 5 & 6, to transform table-layouts by using CSS. They all use exactly the
> same simple layout table.
>
> http://www.barry.pearson.name/articl.../exhibit04.htm
> http://www.barry.pearson.name/articl.../exhibit05.htm
> http://www.barry.pearson.name/articl.../exhibit07.htm
>
>[color=green]
>>Note that I'm no apologist for table layouts (I plonked B. Pearson
>>months ago),[/color]
>
>
> Chuckle! I don't believe that for a second. I believe you are reading this,
> but now you can't respond! (Your problem, not mine).[/color]

I just thought I'd reply here, now he can ;-) (only if he
wants to of course)
[color=blue][color=green]
>>I never advise their use for layout purposes, and I've
>>mastered the skill to use css exclusively for layout years ago. But
>>the fact remains that using css for layout in practice throws up mayor
>>obstacles for the average author.[/color]
>
> [snip]
>
> They throw up obstacles for lots of experienced, professional, authors. It
> often comes down to "what is the most effective way of developing my next
> page?" If you do this for a living, you can't afford to ignore practical
> issues in favour of pedantic purist policies that don't matter to the target
> audience.[/color]

Nah, I'll stay out of this thread now.

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

Barry Pearson wrote:
[color=blue]
> IE doesn't really allow you to start with non-tables and turn them into
> something like tables. But it does allow you to start with tables and turn
> then into non-tables.[/color]

Exactly the opposite of what is desired, in this case, and it's hard to
imagine a practical use.
[color=blue]
> If you do this for a living, you can't afford to ignore practical
> issues in favour of pedantic purist policies that don't matter[/color]

Anxious anchors alliterate when placed in powerful posts.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Barry Pearson wrote:
[color=blue]
> It is possible to use layout tables in *valid* HTML 4.01 Strict,
> XHTML 1.0 Strict, and XHTML 1.1.[/color]

You do know the meaning of "valid" in terms of HTML, right?
[color=blue]
> Use of layout tables is *not* about compliance or non-compliance.[/color]

And you know that a valid document may still violate the standard, right?

http://www.cs.tut.fi/~jkorpela/html/...tion.html#good
[color=blue]
> Search elsewhere for arguments that will stand up to scrutiny.[/color]

About table layouts, there are plenty that don't stand up to scrutiny.
Just seach Google Groups for "Barry Pearson table layout." You might
optionally want to include "inter alia" or "let the courts and
marketplace decide."

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

On Tue, 18 May 2004 08:26:45 +0100, Spartanicus <me@privacy.net> wrote:
[color=blue]
> Neal <neal413@yahoo.com> wrote:
>[color=green]
>> Patrick Griffiths weighs in on the CSS vs table layout debate in his
>> blog
>> entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php
>> . A
>> quite good article.[/color]
>
> I disagree. A flimsy article, no mention of certain issues that make
> table based layouts so author friendly:[/color]

Well, it's the other side of the coin, and he has linked to his opponent's
arguments. I don't expect
anyone to spend a lot of time defending what they think isn't right.

By "quite good", look at the discussion it has raised. Indeed, that's the
sign of a good article.

Neal wrote:
[color=blue]
> By "quite good", look at the discussion it has raised. Indeed, that's
> the sign of a good article.[/color]

George W. Bush's argument for invading Iraq has raised quite a lot of
discussion, but even elite opinion does not regard it as a "good
argument." ;-)

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

On Tue, 18 May 2004 16:35:30 -0400, Brian
<usenet3@julietremblay.com.invalid> wrote:
[color=blue]
> Neal wrote:
>[color=green]
>> By "quite good", look at the discussion it has raised. Indeed, that's
>> the sign of a good article.[/color]
>
> George W. Bush's argument for invading Iraq has raised quite a lot of
> discussion, but even elite opinion does not regard it as a "good
> argument." ;-)[/color]

But it would have made a great article! Would've been less deadly too.

Arne wrote:
[color=blue]
> Spartanicus wrote:[color=green]
>>
>> Also, first thing I had to do to be able to read the article was to
>> disable his stylesheets (micro fonts).[/color]
>
> But why disable it, if the font-size is the only problem? At least he
> use percent for font-size, easy to resize even in IE :-)[/color]

Um, did you actually change the text size? If you did, you would have
noticed that the side columns widened proportionately, leaving less and
less room for the content. For me, by the time the text size was
readable, there was only one word per line in the content column. :-(

Disabling stylesheets is indeed the best alternative at a site like this.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

kchayka wrote:
[color=blue]
> Arne wrote:
>
>[color=green]
>>Spartanicus wrote:
>>[color=darkred]
>>>Also, first thing I had to do to be able to read the article was to
>>>disable his stylesheets (micro fonts).[/color]
>>
>>But why disable it, if the font-size is the only problem? At least he
>>use percent for font-size, easy to resize even in IE :-)[/color]
>
>
> Um, did you actually change the text size? If you did, you would have
> noticed that the side columns widened proportionately, leaving less and
> less room for the content. For me, by the time the text size was
> readable, there was only one word per line in the content column. :-(
>
> Disabling stylesheets is indeed the best alternative at a site like this.[/color]

Well, if you have that big problem to read that text, I do understand
that disabling stylesheets is an alternative. The text is'nt big,
similar to 12px as original (100%) I guess? But I have no problem with
that on my 17 inch screen and 1024x768 resolution.

I resized the text to 200 percent, and certanly the columns widened.
But there was still more than one word per line! :-)

Since there is a very large number of sites out there with that text
size (and even smaller!) for content, you must have really big
problems when surfing?

--
/Arne

URL: http://www.pajala.tk
------------------------------------------
Get your personal ad free domain and email
account for free at http://www.dot.tk
------------------------------------------

On Tue, 18 May 2004 16:24:50 -0500, kchayka <usenet@c-net.us> wrote:
[color=blue]
> Um, did you actually change the text size? If you did, you would have
> noticed that the side columns widened proportionately, leaving less and
> less room for the content. For me, by the time the text size was
> readable, there was only one word per line in the content column. :-(
>
> Disabling stylesheets is indeed the best alternative at a site like this.
>[/color]

He apparently uses font-size: 77% which I think is absolutely stupid.
Well, I'm not touting this CSS as ideal, and it's a shame as he's rather
committed to standards otherwise.

Spartanicus wrote:
[color=blue]
> Note that I'm no apologist for table layouts (I plonked B. Pearson
> months ago), I never advise their use for layout purposes, and I've
> mastered the skill to use css exclusively for layout years ago. But the
> fact remains that using css for layout in practice throws up mayor
> obstacles for the average author.[/color]

Maybe the average author that hasn't been keeping up to date and still views
each tag as a "command" the way browsers of years past have. Anyone who
doesn't know CSS by now and isn't learning it, should stick to just HTML
and have someone else handle CSS. That, I suspect, by the definition of
"designer" in CSS level 1, may well be what the members of the W3C who made
that standard had in mind to begin with.
[color=blue]
> Also, first thing I had to do to be able to read the article was to
> disable his stylesheets (micro fonts).[/color]

Agreed, micro fonts suck. (I'm about to go back to making my minimum and
medium font sizes the same just to make sure the bulk of text on Web sites
is readable, but this plays havoc with testing my own content.)

--
Shawn K. Quinn

Barry Pearson wrote:
[color=blue]
> They throw up obstacles for lots of experienced, professional, authors. It
> often comes down to "what is the most effective way of developing my next
> page?" If you do this for a living, you can't afford to ignore practical
> issues in favour of pedantic purist policies that don't matter to the
> target audience.[/color]

The only practical issue I see, is that structural markup with a clear
separation of presentation and content is how to make documents for the Web
with an eye on the future. Layout is, and always was, part of presentation,
not content, and as such belongs in CSS, not HTML.

If you really *need* pixel perfect layout, you should be using PDF, not HTML
and CSS. You can't expect <table> and similar elements to be a "layout box
command" forever, any more than you can realistically expect <blockquote>
to be an "indent command".

--
Shawn K. Quinn

On Tue, 18 May 2004 23:41:50 -0500, Shawn K. Quinn
<skquinn@xevious.kicks-ass.net> wrote:
[color=blue]
> You can't expect <table> and similar elements to be a "layout box
> command" forever, any more than you can realistically expect <blockquote>
> to be an "indent command".
>[/color]

We might include <p> as a "blank space" command.

Well put. Damn well put. But there's one catch. All graphic browsers will
allow us to emulate the double-spacing of <p> and the indentation of
<blockquote> using CSS. But the most popular browser has no support for
CSS's inherent replacements for <table>.

Still, for me it comes down to the screwdriver analogy Patrick used in the
article. HTML as a presentational device is like using a hand screwdriver.
Sure, the electric screwdriver we have to work with right now cannot fully
replace the hand screwdriver, but it's not a fault of the tool, but of the
material we have to work with. Sooner than later, and mark my words, most
web users will be using a browser which supports CSS fully, and the idea
of using table for layout will be as queer as using your sleeve for wiping
your nose.

Neal wrote:[color=blue]
> Sooner than later,
> and mark my words, most web users will be using a browser which supports
> CSS fully, and the idea of using table for layout will be as queer as
> using your sleeve for wiping your nose.[/color]

lol
You know how many actually do that? ;-)

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

On Wed, 19 May 2004 16:38:20 +0200, Els <els.aNOSPAM@tiscali.nl> wrote:
[color=blue]
> Neal wrote:[color=green]
>> Sooner than later, and mark my words, most web users will be using a
>> browser which supports CSS fully, and the idea of using table for
>> layout will be as queer as using your sleeve for wiping your nose.[/color]
>
> lol
> You know how many actually do that? ;-)
>[/color]

*snif* Pardon?

Neal wrote:
[color=blue]
> the most popular browser has no support for CSS's inherent
> replacements for <table>.[/color]

That's the key. We needed css table presentation, in an easily usable
form, but we didn't get it.
[color=blue]
> Sooner than later, and mark my words, most web users will be using a
> browser which supports CSS fully,[/color]

I don't see any reason to write off MS. They settled the lawsuit brought
by the U.S. government, on rather good terms for MS. They were not able
to settle the case in Europe, but I doubt that will be a significant
hindrance. Unless Linux/Unix starts making inroads into the home pc
market, we'll be stuck with Windows, which necessarily includes that OS
component that doesn't even pretend to be a web browser.
[color=blue]
> and the idea of using table for layout will be as queer as using your
> sleeve for wiping your nose.[/color]

I understand the desire, but I don't think that's a realistic
prediction. We won't see a new version of MSIE until "Longhorn,"
promised in 2007. That means perhaps 2008, with users gradually moving
to the new version in 2010 or later. You'd do well to realize that there
will be no practical use for css table presenation until then at the
earliest.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

On Wed, 19 May 2004 11:33:53 -0400, Brian
<usenet3@julietremblay.com.invalid> wrote:
[color=blue]
> I don't see any reason to write off MS. They settled the lawsuit brought
> by the U.S. government, on rather good terms for MS. They were not able
> to settle the case in Europe, but I doubt that will be a significant
> hindrance. Unless Linux/Unix starts making inroads into the home pc
> market, we'll be stuck with Windows, which necessarily includes that OS
> component that doesn't even pretend to be a web browser.[/color]

My gut instinct tells me that MS will lose its hold on the browser market
within 5 years. This will happen through word-of-mouth and organized
campaigns informing the public of better options available, coupled with
further delays in the readiness of Longhorn - I suspect it's closer to 10
years away. The way things are going, people are slowly trickling away
from IE toward alternative browsers. If each of us gets 3 people a year to
use Mozilla or Opera, and each of them does as well, hold on to your hat,
because that trickle will become a torrent.

IE will be the Netscape 4 of the WWW in 10 years, and Longhorn will have
to provide complete support for W3C standards to be at all competitive.

Neal wrote:
[color=blue]
> My gut instinct tells me that MS will lose its hold on the browser
> market within 5 years.[/color]

Well, I'm no business analyst. But when I listen to or read business
analysts, none seem to indicate that MS is in trouble. Maybe you know
something they don't, but just aren't sharing it with us.
[color=blue]
> This will happen through word-of-mouth and organized campaigns
> informing the public of better options available,[/color]

Note that this is not how Netscape lost their dominance. It was through
illegal business practices committed by MS.
[color=blue]
> The way things are going, people are slowly trickling away from IE
> toward alternative browsers.[/color]

I can only imagine this happening on alternative browsing devices, and
only because MS doesn't have anything for those devices. But that's not
to say that they won't announce some vaporware, or buy out a competitor,
or who knows what else?
[color=blue]
> If each of us gets 3 people a year to use Mozilla or Opera, and each
> of them does as well, hold on to your hat, because that trickle will
> become a torrent.[/color]

lol Neal, what are you smoking down there in Springfield? How many of
"us" do you think there are?

I've installed Mozilla or Firefox for several family members. They all
liked it at first, but each of them has gone back to MSIE 6/Win because
more sites work with it. You underestimate MSIE's hold on the market.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

On Wed, 19 May 2004 16:24:06 -0400, Brian
<usenet3@julietremblay.com.invalid> wrote:

[color=blue]
> lol Neal, what are you smoking down there in Springfield?[/color]

At the moment, a nice Dominican cigar. Yeah, maybe I overestimate the
possibilities for change and progress - I was so sure the Cuban embargo
would collapse too. Oh well. Dominicans are nice too.
[color=blue]
> I've installed Mozilla or Firefox for several family members. They all
> liked it at first, but each of them has gone back to MSIE 6/Win because
> more sites work with it. You underestimate MSIE's hold on the market.[/color]

That's just it. What will change the balance is more websites which work
BETTER in a conforming browser. If word gets out that sites are more
usable in alternative browsers, it can happen.

And, to reassure, no I do not have extra info. This is, as I said, just a
gut instinct and has no basis on anything but the possibilities I think
are down the road. As accessibility becomes more important, as security
becomes an even greater concern, and as website design development must
turn to areas of CSS that MS cannot handle properly, I can't imagine that
IE6 will maintain the status it currently holds among users and designers.
At least, not easily. But Gates is one savvy businessman, I wouldn't put
anything past him.

Neal wrote:
[color=blue]
> Patrick Griffiths weighs in on the CSS vs table layout debate
> in his blog entry[/color]

I just read the articles that prompted Griffiths' response. They might
have made a good point about the difficulties of css for those who just
aren't interested in computers as anything other than utilitarian. But
the authors of those pro-table layout articles decided to include points
that just don't bare the weight. One starts out by comparing those who
advocate web standards with "Communist radicals...[who] wanted to take
over the world and brainwash everybody." I'm not joking.

http://www.apcmag.com/apc/v3.nsf/0/a...256e5f001a59c5

I guess that's the blog version of a shock jock, and clearly doesn't
warrant being taken seriously.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

"Brian" <usenet3@julietremblay.com.invalid> wrote in message
news:10antmu4s1bs659@corp.supernews.com...[color=blue]
> Neal wrote:
>[color=green]
> > Patrick Griffiths weighs in on the CSS vs table layout debate
> > in his blog entry[/color]
>
> I just read the articles that prompted Griffiths' response. They might
> have made a good point about the difficulties of css for those who just
> aren't interested in computers as anything other than utilitarian. But
> the authors of those pro-table layout articles decided to include points
> that just don't bare the weight. One starts out by comparing those who
> advocate web standards with "Communist radicals...[who] wanted to take
> over the world and brainwash everybody." I'm not joking.[/color]

Yeah, just like those crazies who think that each phone company should use
its own telephony protocol.

Shawn K. Quinn wrote:[color=blue]
> Barry Pearson wrote:
>[color=green]
>> They throw up obstacles for lots of experienced, professional,
>> authors. It often comes down to "what is the most effective way of
>> developing my next page?" If you do this for a living, you can't
>> afford to ignore practical issues in favour of pedantic purist
>> policies that don't matter to the target audience.[/color]
>
> The only practical issue I see, is that structural markup with a clear
> separation of presentation and content is how to make documents for
> the Web with an eye on the future. Layout is, and always was, part of
> presentation, not content, and as such belongs in CSS, not HTML.[/color]

No it wasn't! Layout became within the scope of CSS (jointly with HTML),
rather than specifically HTML, in 1997/8. (Specifically, with HTML 4 in
December 1997, and CSS2 in May 1998). Up to that point, pretty well all the
key documents, published by the major players, starting in 1989, placed layout
within the scope of HTML. (The exceptions were some proposals to put "columns"
into stylesheets for layout purposes). I would be interested to see evidence
to the contrary, using documents published *before* April 1997. I haven't
managed to track any such evidence down for my page:
"A brief history of tables"
http://www.barry.pearson.name/articl...es/history.htm

Besides, who says that tables don't permit separation of presentation &
content? Here is a page that uses a simple layout table. I'm talking here
about the outer-level 1-row 2-column table, which puts the site navigation on
the right. I wanted "industrial strength", and a no-CSS default of 2 columns.
http://www.childsupportanalysis.co.uk/

Here is essentially the same page, certainly an identical <body>, but with 2
extra CSS rules. They put the site navigation (2nd table column) on the
left. I've embedded them for demonstration purposes, but they simply override
2 existing rules in the CSS, and I could have modified the external CSS
instead.
http://www.childsupportanalysis.co.uk/reversed.htm

Table mark-up sets the default layout in the absence of contrary CSS. But the
same is true of non-table mark-up. Then you can apply CSS to change things
considerably, for tables and non-tables.
[color=blue]
> If you really *need* pixel perfect layout, you should be using PDF,
> not HTML and CSS. You can't expect <table> and similar elements to be
> a "layout box command" forever, any more than you can realistically
> expect <blockquote> to be an "indent command".[/color]

If you want pixel perfect layout, CSS is the way to go! It gets better at
pixel-perfection with each generation.

Tables have *never* been good at pixel perfection. They were & are intended to
adapt to the users' viewing conditions, such as text size & viewport width,
and optimise for that. In that sense, they conform to the "adapt to the user"
ethos of the web. Create a simple table with no attributes, put stuff in, and
view it under a large range of conditions, and what happens? The cells will
expand & contract according to the content & text size, and attempt to use as
much of the viewport as is useful to reduce vertical scrolling, while also
trying to avoid horizontal scrolling. Wonderful.

Experienced authors of tables all know this, and don't try to use them as a
"layout box command". They just use them to place complex material in rows &
columns. In fact, typically, such authors use very few, if any, controls on
the widths & heights of tables & cells, either via attributes or CSS. The only
remotely reliable way to control the sizes of table cells is to control the
*contents*, not the table elements themselves. Spacer-GIFs were the
last-century way of controlling the content. Now, if that degee of control of
the minimum width is needed, spacer-divs might be used. But, to achieve
maximum width, you had better wrap up the contents of table cells in (say)
<div>s, then use CSS to control the size of those <div>s. The table will adapt
to that:

<td>
<div class="width1">
Content goes here
</div>
</td>

div.width1 {
width: 300px;
overflow: auto;
}

As the CSS1 recomendation said: "We expect to see extensions of CSS in several
directions:
.....
fonts: more precise font specification systems are expected to complement
existing CSS1 font properties.
values, properties: we expect vendors to propose extensions to the CSS1 set of
values and properties. Extending in this direction is trivial for the
specification, but interoperability between different UAs is a concern.
layout language: support for two-dimensional layout in the tradition of
desktop publishing packages."

Tables are inherently flexible in size, and can only be controlled unreliably
& with difficulty. CSS offers "px" values for just about everything, and if
the user has CSS enabled, these rules typically work.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Neal wrote:
[snip][color=blue]
> We might include <p> as a "blank space" command.[/color]
[snip]

Quite. And that is how key documents from all the major players wrote about
<p> right up to February 1997.

Tim Berners-Lee, Daniel Connolly, Dave Raggett, & probably others, all wrote
in those terms from 1993, (if not earlier), until February 1997. Paragraph
mark-up was intended to be used to achieve the typical rendering of a new
line. "Paragraph break" was pretty well synonymous with "line break" until
February 1997. You got a "paragraph break" between block-level elements up to
that time - even between (say) an <h1> and an <h2>.

The first significant published document, that I know of, to counter this, was
the HTML 4 recommendation in December 1997. That recommendation introduced
semantic mark-up rather than presentational mark-up, and used "line break"
instead of "paragraph break" between block-level elements. If there were key
published documents before this that did the same, I haven't found them. I
would welcome references.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Brian wrote:[color=blue]
> Barry Pearson wrote:
>[color=green]
>> It is possible to use layout tables in *valid* HTML 4.01 Strict,
>> XHTML 1.0 Strict, and XHTML 1.1.[/color]
>
> You do know the meaning of "valid" in terms of HTML, right?[/color]

I go by what W3C says. I've made pages using simple layout tables, put various
DOCTYPES in, made tactical adjustments such as " />" closures, and they
validate at W3C. Including XHTML1.1. (And why not? Why shouldn't table-layout
pages validate? They use bog-standard (X)HTML!)
[color=blue][color=green]
>> Use of layout tables is *not* about compliance or non-compliance.[/color]
>
> And you know that a valid document may still violate the standard,
> right?
>
> http://www.cs.tut.fi/~jkorpela/html/...tion.html#good[/color]
[snip]

I've read that. I don't believe it applies here. Simple layout tables use a
subset of data-table mark-up. The differences are mainly in the minds of
humans, not something that technology can distinguish.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

On Thu, 20 May 2004, Barry Pearson wrote:
[color=blue][color=green]
> > We might include <p> as a "blank space" command.[/color]
>
> Quite. And that is how key documents from all the major players
> wrote about <p> right up to February 1997.[/color]

Hmmm? <p> , what had originally been a paragraph break - analogous to
<br> as a line break - was SGML-ified as a paragraph container in the
run-up to drafting the first formal specification of HTML as an
application of SGML, and that was finalised (as RFC1866) by November
1995. So the change in the specification can be traced to some time
before that.

Some of us already had documents marked-up according to the old style,
and didn't bother to change them, since they weren't actually invalid
according to RFC1866.
[color=blue]
> Tim Berners-Lee, Daniel Connolly, Dave Raggett, & probably others,
> all wrote in those terms from 1993, (if not earlier), until February
> 1997.[/color]

We'll need a citation if you're to stand any chance of defending that.
[color=blue]
> Paragraph mark-up was intended to be used to achieve the typical
> rendering of a new line.[/color]

No, of a new *paragraph* (not surprisingly).
[color=blue]
> "Paragraph break" was pretty well synonymous with "line break" until
> February 1997.[/color]

No. It was typically rendered as a paragraph break, not surprisingly.
[color=blue]
> You got a "paragraph break" between block-level elements up to
> that time - even between (say) an <h1> and an <h2>.[/color]

I disagree. There was, and still is, a natural vertical gap between
H1 and H2 elements. You only see the rendered result. Interpret it
as you will, there was nothing more to it than a gap.
[color=blue]
> The first significant published document, that I know of, to counter[/color]
^^^^^^^^^^^[color=blue]
> this, was the HTML 4 recommendation in December 1997.[/color]

That's easily done: just apply your personal criterion of
insignificance to all the significant discussions and documents which
went before.
[color=blue]
> That recommendation introduced
> semantic mark-up rather than presentational mark-up,[/color]

No, it didn't "introduce" it; it *reinforced* the earlier plan of
logical/structural markup. Which pre-dated the - finally unsuccessful
- attempt by the "big two" graphical browsers to turn HTML into a
WYSIWYG presentation language.

The Hypertext Markup Language (HTML) is a simple markup language used
to create hypertext documents that are platform independent. HTML
documents are SGML documents with generic semantics that are
appropriate for representing information from a wide range of
domains. HTML markup can represent hypertext news, mail,
documentation, and hypermedia; menus of options; database query
results; simple structured documents with in-lined graphics; and
hypertext views of existing bodies of information.

That's RFC1866 from 1995. Which goes on to several times mention the
use of style sheets to influence the details of the presentation.

If, as you claim, HTML had been meant to specify the presentation, at
that point in history, why would they have been talking about style
sheets, riddle me that?

Barry Pearson wrote:
[color=blue]
> No it wasn't![/color]

It was only a matter of time before you chimed in with your exclamatory
remarks. ("No it wasn't!" "Gosh!" "Chuckle!" etc.)
[color=blue]
> I would be interested to see evidence to the contrary[/color]

You've been give the links, over and over and over again. I'm sure you
know that most of the regulars have given up on you.
[color=blue]
> I haven't managed to track any such evidence down for my page:
> "A brief history of tables"[/color]

Any excuse to plug that thing, eh?

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Barry Pearson wrote:
[color=blue]
> I've made pages using simple layout tables, put various DOCTYPES in,
> made tactical adjustments such as " />" closures, and they validate
> at W3C. Including XHTML1.1. (And why not? Why shouldn't table-layout
> pages validate?[/color]

There's no "should" about it. They *must* validate if they do not
violate the syntax of the language. (You apparently do not understand
what "valid" means in this context.)
[color=blue]
> Simple layout tables use a subset of data-table mark-up. The
> differences are mainly in the minds of humans, not something that
> technology can distinguish.[/color]

Exactly the point. Since a validator can only check the syntax of a
document, you can only guarantee that a valid document is correct in its
syntax. Whether the document is correct in any other sense cannot be
judged by validating it. So the fact that you've successfully validated
table layout documents says exactly nothing about the appropriateness of
tables used for layout.

Several other examples of incorrect html are on this page, which is
valid html 4.01/strict.

http://www.julietremblay.com/test/valid

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Alan J. Flavell wrote:[color=blue]
> On Thu, 20 May 2004, Barry Pearson wrote:
>[color=green][color=darkred]
>> > We might include <p> as a "blank space" command.[/color]
>>
>> Quite. And that is how key documents from all the major players
>> wrote about <p> right up to February 1997.[/color]
>
> Hmmm? <p> , what had originally been a paragraph break - analogous to
> <br> as a line break - was SGML-ified as a paragraph container in the
> run-up to drafting the first formal specification of HTML as an
> application of SGML, and that was finalised (as RFC1866) by November
> 1995. So the change in the specification can be traced to some time
> before that.[/color]

The last publication I can identify was HTML 3.2, in January 1997:
http://www.w3.org/TR/REC-html32#level
"Most elements that can appear in the document body fall into one of two
groups: block level elements which cause paragraph breaks, and text level
elements which don't. Common block level elements include H1 to H6 (headers),
P (paragraphs) LI (list items), and HR (horizontal rules)."

Pretty explicit! I'm not saying that things weren't changing before that. But
HTML 3.2 was a key publication by a major player, which is what I said. An
author can validate against HTML 3.2 - but can an author validate against
RFC1866? (Actually, I have seen pages with an HTML 2.0 DOCTYPE, so perhaps
they could. But that surely became irrelevant with HTML 3.2). My reading is
that all the major players were already thinking of the next stage of the web,
and CSS1 & HTML 3.2 were intended to draw a line under this "first era" so
that they could concentrate on the "second era".
[color=blue]
> Some of us already had documents marked-up according to the old style,
> and didn't bother to change them, since they weren't actually invalid
> according to RFC1866.[/color]

I suspect that although that document pointed directions to the future, it
wasn't as influential in the immediate development of the web (authors,
authoring tools, browsers, validation, etc) as the later HTML 3.2. And even
that document used terms such as "formatted paragraph style" when talking
about definition lists. This was a document that was laying a basis for later
influential recommendations. But how many people cite that document, rather
than (say) HTML 4, which is the recommendation that explicitly introduced
semantic mark-up to HTML? Do people write "SMGL applications", or "HTML"?
[color=blue][color=green]
>> Tim Berners-Lee, Daniel Connolly, Dave Raggett, & probably others,
>> all wrote in those terms from 1993, (if not earlier), until February
>> 1997.[/color]
>
> We'll need a citation if you're to stand any chance of defending that.[/color]

These are all, of course, in my page:
"A brief history of tables"
http://www.barry.pearson.name/articl...es/history.htm

Here are some examples. (That pages has dozens of references, including dozens
to documents held at W3C). First, some quotes that illustrate the thinking of
the time:
1993: Tim Berners-Lee, Daniel Connolly, "A Representation of Textual
Information and MetaInformation for Retrieval and Interchange" ( version 1.2)
http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt

"Typical rendering is described for many elements. This is not a mandatory
part of the standard but is given as guidance for designers and to help
explain the uses for which the elements were intended". (Hence- presentational
mark-up).

"The elements within the BODY element are in the order in which they should be
presented to the reader". (Hence - layout primarily determined by HTML).

"When writing documents, you should assume that whatever is done it is
designed to have the same sort of effect as the styles above".
[color=blue][color=green]
>> Paragraph mark-up was intended to be used to achieve the typical
>> rendering of a new line.[/color]
>
> No, of a new *paragraph* (not surprisingly).[/color]

Whether you use Berner-Lee (1993), or Raggett (1997), "paragraph break" was
pretty well synomymous with "line break".
[color=blue][color=green]
>> "Paragraph break" was pretty well synonymous with "line break" until
>> February 1997.[/color]
>
> No. It was typically rendered as a paragraph break, not surprisingly.
>[color=green]
>> You got a "paragraph break" between block-level elements up to
>> that time - even between (say) an <h1> and an <h2>.[/color]
>
> I disagree. There was, and still is, a natural vertical gap between
> H1 and H2 elements. You only see the rendered result. Interpret it
> as you will, there was nothing more to it than a gap.[/color]

HTML 3.2, January 1997, (Raggett):
http://www.w3.org/TR/REC-html32#level
"Most elements that can appear in the document body fall into one of two
groups: block level elements which cause paragraph breaks, and text level
elements which don't. Common block level elements include H1 to H6 (headers),
P (paragraphs) LI (list items), and HR (horizontal rules)."

I can't see how that can be interpreted other than to have "paragraph breaks"
between <h1> and <h2>, as I said. Which means "line breaks".
[color=blue][color=green]
>> The first significant published document, that I know of, to counter[/color]
> ^^^^^^^^^^^[color=green]
>> this, was the HTML 4 recommendation in December 1997.[/color]
>
> That's easily done: just apply your personal criterion of
> insignificance to all the significant discussions and documents which
> went before.[/color]

And how would you judge HTML 3.2? See above. I am trying to reveal history,
not rewrite it.

RFC1866 is already in my history, as, HTML 2.0. But I thought that it was
superceded by HTML 3.2. This is common with the web. For example, we