Is a Login Form "Tabular Data"

[Sanders Kaufman]

I'm converting my table-based layouts to css-positioned divs - but the
ONLY reason I'm doing it is because it's *considered* a best practice.

I don't really see where anything goes hinky when tables are used - but
I'm doing it anyway because the HTML and CSS specs says to reserve
tables for tabular data.

So as I convert my login widgit to a css thing, I'm saying to myself -
hey, this form is most certainly "tabular data" - even if it is
interactive. It has a logical caption, columnar data types, a footer -
the whole package.

So it seems like this is, and of right ought to be, an HTML table. So
my question is - is there anything in the real world that says otherwise?

But wait, it gets better.

It seems like, in a well structured page, you have the same situation.
A page is naturally structured as a table, and by just following a few
logical design rules (caption, columnar data types, a footer), a page
could be considered "tabular data".

How far out in left field is this?
The specs say to not use tables for page layout, but they also say to
use tables for tabular data. Which takes precedence when a page
*happens* to be formatted as tabular data?

[rf]

"Sanders Kaufman" <bu***@kaufman.netwrote in message
news:s1*************@newssvr14.news.prodigy.net...

I'm converting my table-based layouts to css-positioned divs - but the
ONLY reason I'm doing it is because it's *considered* a best practice.

Only? Does the new format add to your viewers experience? Ah, I know, you
are "refactoring" your page :-)

How far out in left field is this?
The specs say to not use tables for page layout, but they also say to use
tables for tabular data. Which takes precedence when a page *happens* to
be formatted as tabular data?

A database is most certainly tabular data. It has columns of data fields,
and rows of collections of those fields.

A form _could_ be considered to be tabular. It has rows, one for each input
field. It has colums, 1) the input field itself and 2)the description of
that field and perhaps 3) a validation error for the data in that field.

However, can you fit a "page" into a database? Where are the rows? Where are
the columns?

--
Richard.

[Sanders Kaufman]

Jukka K. Korpela wrote:

Scripsit Sanders Kaufman:

>I don't really see where anything goes hinky when tables are used -
but I'm doing it anyway because the HTML and CSS specs says to reserve
tables for tabular data.

Do they? I've only read a couple of them a few times, and I can't
recollect where they say that. It's a good principle, though. But hardly
a reason to rewrite working code.

Unfortunately, the "if it works don't fix it" principle doesn't apply
here. Standards compliance is a selling feature.

>It seems like, in a well structured page, you have the same situation.
A page is naturally structured as a table, and by just following a few
logical design rules (caption, columnar data types, a footer), a page
could be considered "tabular data".

Caption? Footer? In the absence of a URL, I judge that your page as a
whole is not tabular data but you wish to think it is to justify your
use of a table for layout.

That's an interesting analysis of code you have not seen. How do you do
that?

[Rob Waaijenberg]

Sanders Kaufman schreef:

Jukka K. Korpela wrote:

>Scripsit Sanders Kaufman:

>>I don't really see where anything goes hinky when tables are used -
but I'm doing it anyway because the HTML and CSS specs says to reserve
tables for tabular data.

Do they? I've only read a couple of them a few times, and I can't
recollect where they say that. It's a good principle, though. But
hardly a reason to rewrite working code.

Unfortunately, the "if it works don't fix it" principle doesn't apply
here. Standards compliance is a selling feature.

That's nonsense. In your first post you said:
"...but the ONLY reason I'm doing it is because it's *considered* a best
practice.
I don't really see where anything goes hinky when tables are used..."

Now you say it's a selling feature. Are you saying that your clients
know about web standards and why they are a good thing,
and that you (the specialist) don't know that?

>

>>It seems like, in a well structured page, you have the same situation.
A page is naturally structured as a table, and by just following a few
logical design rules (caption, columnar data types, a footer), a page
could be considered "tabular data".

Caption? Footer? In the absence of a URL, I judge that your page as a
whole is not tabular data but you wish to think it is to justify your
use of a table for layout.

That's an interesting analysis of code you have not seen. How do you do
that?

I'm with Jukka. To maintain that a page as a whole is tabular data is
also nonsense. You don't have to see the code of any page, to know this.

The example you gave before is wrong. You can keep content in a database
and later display it in a page,
but the page itself *does not* start with <tableand end with </table>.

--
Rob

[Sanders Kaufman]

Rob Waaijenberg wrote:

Sanders Kaufman schreef:

>Unfortunately, the "if it works don't fix it" principle doesn't apply
here. Standards compliance is a selling feature.

That's nonsense. In your first post you said:
"...but the ONLY reason I'm doing it is because it's *considered* a best
practice.
I don't really see where anything goes hinky when tables are used..."

Now you say it's a selling feature. Are you saying that your clients
know about web standards and why they are a good thing,
and that you (the specialist) don't know that?

Yes. This is a tool for use by other developers. Non-developers won't
have much use for it.

And yes - I honestly don't know WHY the standards specifically don't
want us to use tables as page layouts. Personally, I think it was a
philosophical decision, rather than a technical one.

What prompted me to make this change was when I overheard a potential
customer mention the tremendous disrespect he has for developers who use
tables for page layout.

Personally, I think he was just being antagonistic, as so many
developers tend to be, but if that's what he wants, and that's what
he'll pay for - that's what I'll build... cause that's what I do.

>>Caption? Footer? In the absence of a URL, I judge that your page as a
whole is not tabular data but you wish to think it is to justify your
use of a table for layout.

That's an interesting analysis of code you have not seen. How do you
do that?

I'm with Jukka. To maintain that a page as a whole is tabular data is
also nonsense. You don't have to see the code of any page, to know this.

That's that antagonism I was talking about.

[Jukka K. Korpela]

Scripsit Sanders Kaufman:

And yes - I honestly don't know WHY the standards specifically don't
want us to use tables as page layouts.

That explains a lot. Have you considered actually reading the standards or
"standards", or asking someone who has read them, instead of just presenting
strong opinions about them and asking pseudoquestions with no URL?

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Rob Waaijenberg]

Sanders Kaufman schreef:

Rob Waaijenberg wrote:

>Sanders Kaufman schreef:

[snipped]

Yes.
This is a tool for use by other developers. Non-developers won't
have much use for it.

I suppose you are regarding web-standards as a tool used by designers or
bulders to sell their work or sell their services,
but that would imply that customers would recognize why standards are
important, otherwise it's useless.

If you feel that standards are useless, why don't you tell your clients
so. They should feel grateful, you're gonna make them save money
judging by this next quote of yours:

Personally, I think he was just being antagonistic, as so many
developers tend to be, but if that's what he wants, and that's what
he'll pay for - that's what I'll build... cause that's what I do.

--
Rob

[dorayme]

In article <6w*****************@newssvr19.news.prodigy.net> ,
Sanders Kaufman <bu***@kaufman.netwrote:

And yes - I honestly don't know WHY the standards specifically don't
want us to use tables as page layouts. Personally, I think it was a
philosophical decision, rather than a technical one.

What prompted me to make this change was when I overheard a potential
customer mention the tremendous disrespect he has for developers who use
tables for page layout.

If your customers share this idea, then don't use tables for
layout. Then the question becomes how to settle what is and what
is not tables for layout.

But be a little careful, this potential customer might be an
unrepresentative wanker. This is an Australian term to describe
someone who picks up ill understood fag ends from possibly more
coherent conversations and runs with it as "a strongly held
opinion".

The risk for you is like the danger/boredom that a friend of mine
kept imposing on himself and passengers in his car a while back
after he was caught running a red light via camera. He became so
jumpy that he would slowdown at green lights! He is now dead,
mercifully. I pushed him violently out of the vehicle on the way
to a restaurant and took over with my own brand of robust
driving. I was hungry. (I became even more hungry, depleted by
the frustration, stimulated by the violence).

--
dorayme

[Sanders Kaufman]

Jukka K. Korpela wrote:

Scripsit Sanders Kaufman:

>And yes - I honestly don't know WHY the standards specifically don't
want us to use tables as page layouts.

That explains a lot. Have you considered actually reading the standards
or "standards", or asking someone who has read them, instead of just
presenting strong opinions about them and asking pseudoquestions with no
URL?

Life's too short to deal with belligerent little trolls such as yourself.

-PLONK_

[Sanders Kaufman]

Rob Waaijenberg wrote:

Sanders Kaufman schreef:

This is a tool for use by other developers. Non-developers won't
have much use for it.

I suppose you are regarding web-standards as a tool used by designers or
bulders to sell their work or sell their services,
but that would imply that customers would recognize why standards are
important, otherwise it's useless.

I wholly agree that the standard of not using tables to layout pages is
useless - since so many folks (like me) don't understand why it should
be done that way.

But I was dealing with a real-world scenario, in which a potential
customer expressed this as a major factor in his decision-making process.

If he wants it layed out with Tables, I'll do that. If he wants divs, I
can do that too. And if he wants it all in XHTML with XSL stylesheets -
so be it.

I once had a customer, a feminist, who said she didn't like HTML web
forms because she didn't like being told to "submit", so I changed them
to "send".

Whatever the customer wants, right?

If you feel that standards are useless, why don't you tell your clients
so.

Because I'm a contractor, not a consultant.
I NEVER want to do consulting again.
Some people get all into that - but not me.

[Bergamot]

Sanders Kaufman wrote:

>
Whatever the customer wants, right?

Contrary to popular belief, the customer isn't always right.

--
Berg

[dorayme]

In article <hP***************@nlpi061.nbdc.sbc.com>,
Sanders Kaufman <bu***@kaufman.netwrote:

I once had a customer, a feminist, who said she didn't like HTML web
forms because she didn't like being told to "submit", so I changed them
to "send".

Whatever the customer wants, right?

You make a good case! <g>

--
dorayme

[Sanders Kaufman]

Bergamot wrote:

Sanders Kaufman wrote:

>Whatever the customer wants, right?

Contrary to popular belief, the customer isn't always right.

That's not what I said; and that's not what I meant.

Sure, I could *argue* with the potential customer, telling him that he
doesn't want what he wants, but rather what I want him to have.

But that would leave me too much free time to swim, watch TV, spend time
with family and reminisce about the career I once had.

[Bergamot]

Sanders Kaufman wrote:

Bergamot wrote:

>>
Contrary to popular belief, the customer isn't always right.

Sure, I could *argue* with the potential customer, telling him that he
doesn't want what he wants, but rather what I want him to have.

2 things wrong with that statement:

1. There is no need to be confrontational about it. Be respectful when
you tell them they want bad things. Chances are they'll listen.

2. It's not about what *you* want them to have, but what is best for
*their* (potential) customers, which is ultimately best for them. At the
very least, let them make an informed decision instead of you kowtowing
to every foolish whim.

--
Berg

[Sanders Kaufman]

Bergamot wrote:

Sanders Kaufman wrote:

>Bergamot wrote:

>>Contrary to popular belief, the customer isn't always right.

Sure, I could *argue* with the potential customer, telling him that he
doesn't want what he wants, but rather what I want him to have.

2 things wrong with that statement:

1. There is no need to be confrontational about it. Be respectful when
you tell them they want bad things. Chances are they'll listen.

But they don't want a bad thing. They just want the application to
conform to the written standards - standards created by an international
think-tank of the greatest minds, and most successful captains, of the
industry.

When you're an engineering type, that's not just a good thing - that's
downright *holy*.

2. It's not about what *you* want them to have, but what is best for
*their* (potential) customers, which is ultimately best for them. At the
very least, let them make an informed decision instead of you kowtowing
to every foolish whim.

I never really thought as standards compliance as a "foolish whim".

[lyallex]

dorayme wrote:

In article <6w*****************@newssvr19.news.prodigy.net> ,
Sanders Kaufman <bu***@kaufman.netwrote:

>What prompted me to make this change was when I overheard a potential
customer mention the tremendous disrespect he has for developers who use
tables for page layout.

If your customers share this idea, then don't use tables for
layout. Then the question becomes how to settle what is and what
is not tables for layout.

But be a little careful, this potential customer might be an
unrepresentative wanker. This is an Australian term to describe
someone who picks up ill understood fag ends from possibly more
coherent conversations and runs with it as "a strongly held
opinion".

Ah yes, sometimes they call themselves 'managers'. It's not just
potential customers who demonstrate this behaviour, they also lurk
within your own organisation.
Before anyone gets upset I know there are good managers out there, I've
worked with one or two, but many I have met seem to base their
management techniques on using words and phrases that they have
overheard. Understanding doesn't seem to be high up on their list of
priorities.

I always understood that standards are there to be adhered to ... you
don't have to adhere to them but then you are not standards compliant.
All I can say is that if CSS2 helps to stop all this browser
compatibility nonsense then compliance by browser vendors can't come
soon enough for me.

If an organisation slavishly adheres to standards because they are
considered to be generally 'a good thing' then you are on a hiding to
nothing trying to get them to ignore a particular standard.
The chances are that they don't have a deep understanding of the
standard and don't really care, they just want to be able to say they
comply because it's 'good for business'.

I've spent most of my working life writing server side components. Now
I'm out on my own and I have to figure out this CSS2 stuff, all I can
say so far is thank god for the box model, no more hidden images to
space components and no more struggling with cellpadding and cellspacing.

All this is just my opinion of course

Rgds
Duncan

[Andy Dingley]

On 25 Aug, 04:07, Sanders Kaufman <[e-mail]:

I'm converting my table-based layouts to css-positioned divs - but the
ONLY reason I'm doing it is because it's *considered* a best practice.

So as I convert my login widgit to a css thing, I'm saying to myself -
hey, this form is most certainly "tabular data"

It's possibly tabular, but it's not generally regarded as "data".

There are other reasons to use <tabletoo, possibly more relevant
here. If your over-riding wish is that the layout retains a two-
dimensional "grid" structure, even if this starts to require scrolling
or cropping, then it's OK to use <tabletoo.

If you really have a structure of paired elements (caption label and
text control) in a list (username, password, domain, other things,
submit buttons) then this is really a more linear and less grid-like
set. A better markup would be as some sort of list, probably just a
sequence of <divrather than <uland using CSS float to position
labels and controls alongside each other. The advantage of this is
that it linearises more obviously and sensibly, which gives better
behaviour in the limiting case of small-screen devices such as mobile
phones.

[Andy Dingley]

On 27 Aug, 18:14, Sanders Kaufman <[e-mail]:

Jukka K. Korpela wrote:

Life's too short to deal with belligerent little trolls such as yourself.

Life is however too complicated to ignore people who are so usefully
right, even if their style is so abrasive. Don't plonk Jukka, it'll be
your loss rather than his.

[Bergamot]

Sanders Kaufman wrote:

Bergamot wrote:

>let them make an informed decision instead of you kowtowing
to every foolish whim.

I never really thought as standards compliance as a "foolish whim".

Standards compliance wasn't the issue. You said:

If he wants it layed out with Tables, I'll do that. If he wants divs, I
can do that too.

A client specifically requesting such things doesn't seem likely in the
first place, but asking for table layouts sounds like a whim to me.

--
Berg

[Sanders Kaufman]

Bergamot wrote:

Sanders Kaufman wrote:

Standards compliance wasn't the issue. You said:

>If he wants it layed out with Tables, I'll do that. If he wants divs, I
can do that too.

A client specifically requesting such things doesn't seem likely in the
first place, but asking for table layouts sounds like a whim to me.

You should have read the whole thread, to get the context.
That was a what-if scenario, in response to a point in a response.

In the OP, the situation was this:

I have a potential client whom(gr?) I overheard saying that he had
tremendous disrespect for developers who use tables instead of CSS for
page layout. His reason for this harsh judgement was that it
*specifically* says in the HTML spec to NOT use tables for page layouts.

And he's right. Tables are a lazy-man's way of doing page layouts - and
they violate the spec.

If I ever finish this project, and try to sell it to developers, I want
to be able to say that it conforms to the spec.

I don't want to have to say that "It doesn't conform to the spec... but
don't worry, I'm smarter than the team of international captains of the
industry who developed the spec."

-+-+-+-+

Still - the other part was true, too. I'll lay it out however the
customer wants - as long as the checks cash.

I did one page that I thought was *totally* insane. It was formatted
like HTML - with tags and all - but there were no real HTML tags - no
<p>, no <h1- none of it. Then, I had a style sheet that gave their
"custom" tags format.

I thought it was insane - until they changed the headers to make it an
XML page, and did some stuff with the CSS I wrote to make it XSL. THEN
it all made sense.

That's just one of many reasons why I don't get too involved in client's
business practices. If it works for them - so be it. I'm a coder, not
a consultant.

[Sanders Kaufman]

lyallex wrote:

The chances are that they don't have a deep understanding of the
standard and don't really care, they just want to be able to say they
comply because it's 'good for business'.

Actually, in this case, the challenge is that the client DOES have a
very deep understanding of the standard.

>
I've spent most of my working life writing server side components. Now
I'm out on my own and I have to figure out this CSS2 stuff, all I can
say so far is thank god for the box model, no more hidden images to
space components and no more struggling with cellpadding and cellspacing.

All this is just my opinion of course

Rgds
Duncan

[Sanders Kaufman]

Andy Dingley wrote:

On 25 Aug, 04:07, Sanders Kaufman <[e-mail]:

>I'm converting my table-based layouts to css-positioned divs - but the
ONLY reason I'm doing it is because it's *considered* a best practice.

>So as I convert my login widgit to a css thing, I'm saying to myself -
hey, this form is most certainly "tabular data"

It's possibly tabular, but it's not generally regarded as "data".

After checking a few authoritative sources, I've found that the login
form (as well as most any other HTML form) is considered "tabular data"
for the purpose of an HTML Table.

There are other reasons to use <tabletoo, possibly more relevant
here. If your over-riding wish is that the layout retains a two-
dimensional "grid" structure, even if this starts to require scrolling
or cropping, then it's OK to use <tabletoo.

Actually, that is not true.

As I delve into this issue I find one overwhelming reason for using CSS
in lieu of tables to format non-tabular data.

Deaf and/or blind people who use web browsers. :)

It's true. Formatting non-tabular data into a table makes it awkward as
hell for gimps to browse the web. This is especially true for a
page/table that uses colspans and rowspans. Nothing comes out right in
the aural or braille translator when done like that.

If you really have a structure of paired elements (caption label and
text control) in a list (username, password, domain, other things,
submit buttons) then this is really a more linear and less grid-like
set. A better markup would be as some sort of list, probably just a
sequence of <divrather than <uland using CSS float to position
labels and controls alongside each other. The advantage of this is
that it linearises more obviously and sensibly, which gives better
behaviour in the limiting case of small-screen devices such as mobile
phones.

[Jukka K. Korpela]

Scripsit Sanders Kaufman:

After checking a few authoritative sources, I've found that the login
form (as well as most any other HTML form) is considered "tabular
data" for the purpose of an HTML Table.

Of course, there is no authoritative source for that. You are just making
things up as you type. No wonder you don't _cite_ any source.

Authoritative sources don't take a position on such details.

As I delve into this issue I find one overwhelming reason for using
CSS in lieu of tables to format non-tabular data.

Deaf and/or blind people who use web browsers. :)

It's true. Formatting non-tabular data into a table makes it awkward
as hell for gimps to browse the web.

Did you actually test this, or ask a blind person about it?

This is especially true for a
page/table that uses colspans and rowspans.

Now there's some truth in your statement, probably by accident.

ObCSS: You can make pages a mess and inaccessible to the blind by using CSS
layout, too. It's actually rather easy. Just learn bad coding habits by
example, copying other people's code, and never bothering to try to
understand the basics.

Nothing comes out right
in the aural or braille translator when done like that.

I bet you never even touched a Braille device.

The bottom line is that for accessibility, as for many other considerations,
tables vs. CSS layout means _much_ less than the way you use the tools
(table markup or some method of doing layout with CSS). And I mean _much_.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Sanders Kaufman]

Jukka K. Korpela wrote:

Scripsit Sanders Kaufman:

>After checking a few authoritative sources, I've found that the login
form (as well as most any other HTML form) is considered "tabular
data" for the purpose of an HTML Table.

Of course, there is no authoritative source for that. You are just
making things up as you type. No wonder you don't _cite_ any source.

Authoritative sources don't take a position on such details.

Well - one of those authoritative sources was the CSS specification.
So, there thphthphthpth!

>Nothing comes out right
in the aural or braille translator when done like that.

I bet you never even touched a Braille device.

You're really a belligerent little troll, aintcha?

It was suggested that I not filter out your posts, because you can be
helpful... but that ain't workin' out so good.

-PLONK-

[Andy Dingley]

On Tue, 28 Aug 2007 14:46:56 -0500, Sanders Kaufman <bu***@kaufman.net>
wrote:

>There are other reasons to use <tabletoo, possibly more relevant
here. If your over-riding wish is that the layout retains a two-
dimensional "grid" structure, even if this starts to require scrolling
or cropping, then it's OK to use <tabletoo.

Actually, that is not true.

OK Mr Genius, how else are you going to do it?

[Jukka K. Korpela]

Scripsit Sanders Kaufman:

>>After checking a few authoritative sources, I've found that the
login form (as well as most any other HTML form) is considered "tabular
data" for the purpose of an HTML Table.

- -

Well - one of those authoritative sources was the CSS specification.

Which one, and which clause there? Don't hesitate to quote the relevant
sentence or two. (I know you can't.)

So, there thphthphthpth!

Do you feel better now? When I was in the kindergarten, I met some kids who
acted like that, and I wondered why they did that.

-PLONK-

You already promised that, but I didn't really believe it that time either.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Michael Fesser]

..oO(Sanders Kaufman)

>Jukka K. Korpela wrote:

>Scripsit Sanders Kaufman:

Of course, there is no authoritative source for that. You are just
making things up as you type. No wonder you don't _cite_ any source.

Authoritative sources don't take a position on such details.

Well - one of those authoritative sources was the CSS specification.

Post a link. BTW: In your other post you said it was the HTML spec. And
maybe you want to check the WAI guidelines as well?

>-PLONK-

The first one didn't work?

Micha

[Sanders Kaufman]

Michael Fesser wrote:

That's a _recommendation_, nothing more. The important words here are
"SHOULD NOT" - it's not a "MUST NOT". That's a big difference.

Actually, it's a teeny tiny itsy bitsy difference, but I get the point.

The point is: You can write meaningful, perfectly usable and accessible
sites with tables, and you can produce the most unusable div-soup with
CSS-only. Both are just tools, you always have to know how to use them
properly.

As I go through this, I actually found another reason for using css
instead of tables.

I checked out the page using tables on my cell phone, and trying to
scrunch three columns onto that itty bitty screen left me with one word
per column per line. Baaaaad.

But by using divs the cell phone displayed the sections vertically.

I don't need my app to be kick-ass on a cell phone, but it would be very
cool if it didn't display as mush - so CSS divs instead of table page
layouts is now what I'll always do - unless the data is tabular as all
get-out.

>And he's right. Tables are a lazy-man's way of doing page layouts

Yes, in most cases.

>- and
they violate the spec.

Definitely wrong.
It may be bad practice, but it _doesn't_ violate any spec.

That depends on how your definition of "violate the spec".

[Sanders Kaufman]

Michael Fesser wrote:

.oO(Sanders Kaufman)

>Jukka K. Korpela wrote:

>>Scripsit Sanders Kaufman:

Of course, there is no authoritative source for that. You are just
making things up as you type. No wonder you don't _cite_ any source.

Authoritative sources don't take a position on such details.

Well - one of those authoritative sources was the CSS specification.

Post a link. BTW: In your other post you said it was the HTML spec. And
maybe you want to check the WAI guidelines as well?

>-PLONK-

The first one didn't work?

Actually - the second one didn't either.
I'm still waaaaay too new to Thunderbird/Firefox and haven't gotten the
twit-filters figgered out yet.

[Sanders Kaufman]

Andy Dingley wrote:

On Tue, 28 Aug 2007 14:46:56 -0500, Sanders Kaufman <bu***@kaufman.net>
wrote:

>>There are other reasons to use <tabletoo, possibly more relevant
here. If your over-riding wish is that the layout retains a two-
dimensional "grid" structure, even if this starts to require scrolling
or cropping, then it's OK to use <tabletoo.

Actually, that is not true.

OK Mr Genius, how else are you going to do it?

Well, this is a stylesheet discussion group about CSS. And the specs
say to use css stylesheets, rather than tables, to layout such things.

So I'll go with the obvious choice.
It is obvious, isn't it?

[Pavel Lepin]

Sanders Kaufman <bu***@kaufman.netwrote in
<_%***************@newssvr19.news.prodigy.net>:

Michael Fesser wrote:

>That's a _recommendation_, nothing more. The important
words here are "SHOULD NOT" - it's not a "MUST NOT".
That's a big difference.

Actually, it's a teeny tiny itsy bitsy difference, but I
get the point.

Actually, it's a *precisely* defined difference. RFC 2119.
Note that RFC 2119 is in Normative references section of
HTML 4.01 spec:

http://www.w3.org/TR/html401/references.html#h-1.1

The Conformance section of the spec explicitly refers to it:

http://www.w3.org/TR/html401/conform.html

>>- and
they violate the spec.

Definitely wrong.
It may be bad practice, but it _doesn't_ violate any
spec.

That depends on how your definition of "violate the spec".

Violation of the spec is *precisely* defined in Conformance
section of it. Get a clue already.

--
This chickenus crossed the roadus while yodelingus.

[Andy Dingley]

On 29 Aug, 05:59, Sanders Kaufman <[e-mail]:

Well, this is a stylesheet discussion group about CSS.

So how are you going to implement a grid-like layout in CSS, without
using <table? There's a way, but it doesn't work. It's not even
_supposed_ to work, as it's unnecessary. Use the <tableinstead.

And the specs
say to use css stylesheets, rather than tables, to layout such things.

You don't have enough experience to correctly interpret what the
recommendations say.

In particular, an advisory note pointing out a decade of bad practice
in using tables to set margins isn't the same as a blanket ban on
using tables for those things that require them.

[Sanders Kaufman]

Andy Dingley wrote:

On 29 Aug, 05:59, Sanders Kaufman <[e-mail]:

>Well, this is a stylesheet discussion group about CSS.

So how are you going to implement a grid-like layout in CSS, without
using <table? There's a way, but it doesn't work. It's not even
_supposed_ to work, as it's unnecessary. Use the <tableinstead.

There's a way - but it doesn't work?
That's cute.

But to answer the question, I'm looking at divs with absolute
positioning. It seems to work GREAT so far - even with a few extra
capabilities that tables don't have.

> And the specs
say to use css stylesheets, rather than tables, to layout such things.

You don't have enough experience to correctly interpret what the
recommendations say.

I've been programming computers since the 1970's; I'm an MCSD; I
developed the web's first fax-over-IP protocol; I wrote the book, "Teach
Yourself ActiveX Programming in 21 Days" for MacMillan; and I've written
DOZENS of programming articles for C|NET.

I may not have the knowledge, but I most *certainly* have the experience.

In particular, an advisory note pointing out a decade of bad practice
in using tables to set margins isn't the same as a blanket ban on
using tables for those things that require them.

Yeah - but the customer wants what the customer wants.

[Andy Dingley]

On Wed, 29 Aug 2007 18:12:12 GMT, Sanders Kaufman <bu***@kaufman.net>
wrote:

>I'm looking at divs with absolute
positioning. It seems to work GREAT so far - even with a few extra
capabilities that tables don't have.

>You don't have enough experience to correctly interpret what the
recommendations say.

>I'm an MCSD;

OK, _now_ I'm convinced.

Strangely all three of these statements fit together strangely well.

[Sanders Kaufman]

Andy Dingley wrote:

On Wed, 29 Aug 2007 18:12:12 GMT, Sanders Kaufman <bu***@kaufman.net>

>>You don't have enough experience to correctly interpret what the
recommendations say.

>I'm an MCSD;

OK, _now_ I'm convinced.
Strangely all three of these statements fit together strangely well.

And then the green-eyed jealousy monster reared its ugly head.

[Andy Dingley]

On 30 Aug, 05:39, Sanders Kaufman <[e-mail]:

I'm an MCSD;

And then the green-eyed jealousy monster reared its ugly head.

Jealous? No Sanders, I'm _laughing_ _at_ you. I'm just a bad person
that way, sorry.

You popped up and did a non-uncommon newbie thing:

Post #1 - "I'm just starting out, please help"

Post #2 - "You guys all suck"

Post #3 - "I know more than you guys anyway"

You didn't listen when you were told politely that your proposition
was wrong. Then you compounded the error by discovering that absolute
positioning is the solution to everything (It isn't. If we thought
you'd listen, we'd tell you this and explain why - read the "Achieving
same results in all browsers" thread).

Now you've told us you're an MCSD. This means three things: You _have_
an MCSD. Not a fatal error, but pretty glaring. You think that M$oft
have any connection to good practice in web design or that their lead
is worth following. Most of all though, it means thhat you think an
MCSD is in _any_ way impressive or an indication of competence. Show
us a portfolio, show us some chunk of sourceforge that you built, but
hiding behind an MCSD is minimum-wage teenager stuff.

[Sanders Kaufman]

Andy Dingley wrote:

On 30 Aug, 05:39, Sanders Kaufman <[e-mail]:

>>>I'm an MCSD;

>And then the green-eyed jealousy monster reared its ugly head.

Jealous? No Sanders, I'm _laughing_ _at_ you. I'm just a bad person
that way, sorry.

You popped up and did a non-uncommon newbie thing:

Post #1 - "I'm just starting out, please help"
Post #2 - "You guys all suck"
Post #3 - "I know more than you guys anyway"

I never said that stuff, you little troll.

Now you've told us you're an MCSD. This means three things: You _have_
an MCSD. Not a fatal error, but pretty glaring. You think that M$oft
have any connection to good practice in web design or that their lead
is worth following.

I hear that a lot from uncertified, ineducable, internet trolls.
I don't know why.

[Ben C]

On 2007-08-30, Sanders Kaufman <bu***@kaufman.netwrote:

Andy Dingley wrote:

[...]

>Now you've told us you're an MCSD. This means three things: You _have_
an MCSD. Not a fatal error, but pretty glaring. You think that M$oft
have any connection to good practice in web design or that their lead
is worth following.

I hear that a lot from uncertified, ineducable, internet trolls.
I don't know why.

What exactly did they teach you on the M$oft course? I am quite
interested to know, although not enough to actually go on one.

[Brendan Gillatt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sanders Kaufman wrote:

Actually - the second one didn't either.
I'm still waaaaay too new to Thunderbird/Firefox and haven't gotten the
twit-filters figgered out yet.

Too new to those for kill filters? It takes 5 minutes to read the help
file for that; it takes weeks or months to find the rendering quirks in
a particular browser. I sure hope _none_ of your potential developer end
users have selected an alternative browser to IE ;)

- --
Brendan Gillatt
brendan {at} brendangillatt {dot} co {dot} uk
http://www.brendangillatt.co.uk
PGP Key: http://pgp.mit.edu:11371/pks/lookup?...rch=0xBACD7433
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFG7a1UkA9dCbrNdDMRAu5rAJ0YRcBdydXy0qULAbNRYT 77xz8hwwCfRzVS
drd0juhZivkYdfoNYJ68J+0=
=H826
-----END PGP SIGNATURE-----