Re: What's allowed in table cells? (fwd)

MegaZone (megazone@livingston.com)
Tue, 24 Sep 1996 23:11:05 -0700 (PDT)


Message-Id: <199609250611.XAA29526@server.livingston.com>
Subject: Re: What's allowed in table cells? (fwd)
To: www-html@w3.org
Date: Tue, 24 Sep 1996 23:11:05 -0700 (PDT)
From: MegaZone <megazone@livingston.com>

Once upon a time Carl Morris shaped the electrons to say...
>my mistakes...  and further more 100% validated code doesn't display
>worth crap on MSIE... I constantly have to doctor the code between MSIE
>and netscape due to their such different rendering ideas ... that alone

Then I question your designs.  I have 100% validated code and I have
received nothing but compliments on it from NS and MSIE users.  A number
of people here use MSIE and the rest are mostly NS.  I've also submitted
our site for review to several critiquing groups - not one bad review.
That comes from NS users, MSIE users, Lynx users, Mosaic users...

100% validated under HTML 3.2.

>No, their pages don't validate ... not to me...  they're explicitly

"Not to you" what the hell does that mean?  They validate under common
DTDs.  Your opinion does not equate to validation.

>using <BR>   thats non-portable...  for one browser their lines may
>partially wrap before the <BR> kicks, on another browser and video

What? Your sentence doesn't make sense.  And look at the line length, if
their window is thin enough to wrap those lines, they have it down to like
100 pixels.  It collapses to a list, which is how data was organized prior
to tables.  So I don't see how you could complain about it - if tables
didn't exist, the next logical structure is a list.  In fact, that is
how the pages were before I used tables - lists.

>mode, there may be 50% wasted screen.... bad example ...  I am already
>disapointed in their coding techniques...

I've never seen it break on any browser on any platform - providing the
browser itself is not buggy.  Like XMosaic 2.6 - it mis-implements tables,
that is a bug.

And if you want the lines to extend across the screen, I've done that too.

>scalable work of HTML coding ...  but thinking that a validator must be
>used to do such work is insane!  It can be done, and probably proves
>that the person is not lazy, due to the ammount of work it takes...

Using a validator is the *ONLY* way to have *ANY* confidence in the code.
Do you check your code in NS?  ALL VERSIONS?  ALL PLATFORMS?  AND MSIE?
AND LYNX? AND NCSA MOSAIC? AND HotJava?  AND SPRY MOSAIC? AND...

Do you get the picture?  If the code validates then it should work in
any browser that has followed the standard.  And if it is well designed
valid code it should degrade gracefully to browsers that supported an
older standard.

The moment you deviate and start trusting your own design decisions you
immediately lose any reasonable faith that it will do so.  The moment you
mix tags to 'make it look better on lynx' you may have well screwed up the
entire page on some other browser because it is trying to follow the 
standard and you have violated it.

You're no better than the folks who design and test only in NS - and never
know that it doesn't display in Mosaic because the codeis broken.  If you
are going to be stupid enough to make changes that knowingly violate the
DTD, then you are willingly sacrificing any confidence in your design.  I
just hope you never sell services to someone else, you'd be cheating them.

Again, you display a remarkable naiviety about user interface design and
code portability.  You must not have a programming or UI design background.

>Try taking a look at
>http://www.htcnet.com/~msftrncs/msftrncs/files/index.html, an
>experiment, with lynx... I can't swear to the current code being
>validated, but it was at one time ...  and that alone does't mean it
>looks any good in lynx... when I started working on lynx compatibility,
>the validators barfed...

Well, it looks terrible in NS - dark grey text in a black background.  
What a great idea...  Oh, and DARK red text on black.  Can you say
*unreadable* boys and girls?  I have 20/15 vision and I'm looking at this
on an SGI workstation - and I can't read it without staring at it from a
couple of inches away.  And you set the table width wider that the default
width for NS and MSIE...  I'm growing more convinced about lack of effort
on design.

It is ok on Lynx.  Funny that you've managed to make a page that is
actually more readable on Lynx - because it is two colors and the text
isn't masked into the background.

Let's see - oh, used names of colors, which is known to cause problems.
Should use hex codes for true portability.  Yes both are valid, but the
real world sometimes favors one valid system over another.

sgmls: SGML error at index.html, line 28 at "%":
       Incorrect character in markup; markup terminated
sgmls: SGML error at index.html, line 28 at "0":
       Length of name, number, or token exceeded NAMELEN or LITLEN limit
sgmls: SGML error at index.html, line 28 at "%":
       Incorrect character in markup; markup terminated
sgmls: SGML error at index.html, line 28 at ">":
       TR start-tag implied by data; not minimizable
sgmls: SGML error at index.html, line 28 at ">":
       Start-tag omitted from TR with empty content
sgmls: SGML error at index.html, line 28 at ">":
       TABLE end-tag implied by data; not minimizable
sgmls: SGML error at index.html, line 29 at ">":
       Out-of-context TR start-tag ended HTML document element (and parse)

This is going to cause problems on browsers that are strict about SGML
compliance - like Panorama PRO and HotJava.  I'd fix them.

>are any physical rules to follow, (HTML 3.2 itself leaves itself too
>open, SGML is the only thing that physically limits coding practises,
>and until a browser/all browsers use SGML to decode HTML there is no
>need to stop experimenting with what works and what doesn't...

HTML *IS AN APPLICATION OF SGML*  What part of that do you not understand?
There are browsers that use SGML parsing - Panorama PRO and HotJava come
to mind.

HTML is also NOT meant to be a presentational language, it is a logical
markup language.  Presentation is SUPPOSED to be up to the client.  How
in the hell have you missed such a fundamental point?  That is what CSS1
is all about.  HTML is meant to provide only very limited presentational
control, when related to the content.  External mechanisms, like style
sheets, are meant to provide fine tuning of that presentation.

>No, you designed your table for compatibility with LYNX ... I am try to
>make existing tables look good on Lynx, and unchanged on all others...
>have you done that?  I'll give you some to try! (just start browsing

It doesn't make any noticable changes to the table structure when viewed
in NS and MSIE.

And you missed the point *again* - design is more than taking an existing
table and shoe-horning it into place.  It may mean rethinking the entire
presentational structure.  It may actually mean *effort* on the part of
the designer.

And I am fairly confident that if you go outside the DTD and mess with
markup to make your tables work on browser X, that I could find browser Y
where is messes them up.  There are tens of browsers out there, and most
of them have differences at the parser level - some very major.  And
with the web drifting towards full SGML compliance, your pages are a
dead end street if they violate any rules of SGML.

>the sources that stated a TR can contain markup other than <TD><TH>
>will be contacted... but it will be a while before their sources are
>updated...

Don't trust things like NS's pages.  I have seen statements there that
are out of date.  Things on their pages that were true in 1.x or 2.x may
not work in 3.x.  The commercial pages are not good reference material.
I've also seen suggestions at the MS and NS sites to do things that will
break other browsers.  Unless you can test in all browsers on all platforms.

>No, you have yet to tell me who thought up tables... was it Marc
>Anderson? or was it tim berner-lee (sp?)  I doubt it was the latter... 

They were brought up at a WWW discussion group back in 1993 and then
refined, publically, on WWW-TALK.  They were incorporated into the HTML+
discussion and eventually made it into the HTML+ discussion document.

Netscape took those proposals and implemented them.  The Mosaic teams also
did an implementation of tables.  These implementations, in conjunction
with HTML+, lead to the table specs in the HTML 3.0 proposal.  As use
spread it was refined and an IETF working group was formed to develop an
RFC for HTML tables.  They drew upon work done for HTML+, HTML 3.0, and
the public discusssions, as well as the practical experienced gained with
NS and Mosaic.  This resulted in RFC 1942.

>pile of history...  I can tell you that if the current tables were
>completely scrapped and new specs designed ... they would have a lot of
>things in difference...

Hah!  Wrong.  Look at the coming standard for TABLES RFC 1942 - see, there
are existing table structures outside of HTML, and even SGML, it is the
COLS spec.  HTML tables were designed from an early point to have 
commonality, and RFC 1942 refines that to compatibility to make transitioning
easy.  While there may have been one or two changes due to hindsight, they
would be fundamentally the same.

You seem to have a completely irrational hatred of NS.  On top of that,
all of this information is publically available, mostly on the W3C site.

Again, don't point fingers when you admit you don't have the facts.  It
reduced your credibility.

-MZ
--
Livingston Enterprises - Chair, Department of Interstitial Affairs
Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com
For support requests: support@livingston.com  <http://www.livingston.com/> 
Snail mail: 6920 Koll Center Parkway  #220, Pleasanton, CA 94566
See me in person: Internet Expo, Boston, MA, October 16-17, Booth 422 ;-)