Re: <PAGE> proposal

BearHeart / Bill Weinman (BearHeart@bearnet.com)
Sat, 23 Dec 1995 16:12:16 -0600


Date: Sat, 23 Dec 1995 16:12:16 -0600
Message-Id: <199512232212.QAA13880@primus.paranoia.com>
To: www-html@w3.org
From: BearHeart / Bill Weinman <BearHeart@bearnet.com>
Subject: Re: <PAGE> proposal


At 04:44 pm 12/23/95 -0500, Wilfredo Sanchez Jr. wrote:
>It seems to me that (at the moment) a "page" correspond to an HTML
>"document", so there is only one page per document.  What you want is
>a single document with multiple pages, which is the same as mutiple
>documents.  

   I think this is where you get lost. A single document with multiple 
pages is different than multiple documents. 

   A phone book is a single document with multiple pages. 

   A library is multiple documents. 

   One thing you are right about is that the current HTML specification 
does not make that distinction very well as there is no way to specify 
the structure of multiple pages within a single document. 

>I can understand why you feel you need to decouple this
>relationship, but perhaps it's not necessary (see below).  It's a

   I don't think "necessary" is the point, obviously none of this is
"necessary". But, as Eric said, if we don't specify something to 
handle an obvious need conveniently, it will pop up as an extension 
and that's what's been creating all the chaos in the spec. 

   Why do you think there are so many browsers out there with different 
ways of handling TABLES and CLIENT-SIDE IMAGEMAPS and FONT faces and 
colors and sizes? Because the user-base wants them and those of us 
participating in this process spend so much time arguing about whether-
or-not something is "necessary" that they get frustrated and do it 
outside of this process. 

>coincidence that when you send a URL to a server, it fetches a "file",

   It's not a coincidence. It happens that way because that is 
the convenient association with current technology and prevelant 
architecture. 

>as CGI scripts might do, and so on.  I hardly see a need to decouple
>"file" from "page", as they are really not explicitly connected by the
>HTML specification.

   And here is the confusion. I don't understand why, after Eric 
has explained it over and over, and I've reiterated it a few times, 
people keep misassigning this goal to this proposal: 

   The "decoupling" that needs to happen is not beetween "file" and 
"page" or between "file" and "URL". What needs to be decoupled is "HTML" 
and "scrollable media"--what I have called the "browser-with-screen" 
syndrome, (How much for that "browser-in-the-window?).  

   Since there is no way to define the meaning of "page" within the 
context of HTML, out of need someone will create an extension that does 
this. Eric is suggesting that we form a mechanism by which an author may 
define what "PAGE" means within the context of a document. 

   (Eric: Am I understanding your proposal correctly? It seems obvious 
to me but I could be wrong. It would be unprecedented, but it could happen.
Theoretically.)  ;^)


+----------------------------------------------------------------------+
 * BearHeart / Bill Weinman 
 * BearHeart@bearnet.com *            * http://www.bearnet.com/ *
 * Author of The CGI Book:    * http://www.bearnet.com/cgibook/ *
 * 'Tis an ill cook that cannot lick his own fingers. --Shakespeare