Re: Concerns about HTML+ complexity
fox@pt0204.pto.ford.com (Ken Fox)
Errors-To: listmaster@www0.cern.ch
Date: Thu, 16 Jun 1994 23:13:18 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406162107.AA19859@pt0204.pto.ford.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: fox@pt0204.pto.ford.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: fox@pt0204.pto.ford.com (Ken Fox)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Concerns about HTML+ complexity
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text
Content-Type: text
X-Mailer: ELM [version 2.4 PL23]
X-Mailer: ELM [version 2.4 PL23]
> >I want to preserve the current Web model of lot's of people developing tools
> >in all sorts of places with loose coupling between them.
>
> So do I. I think we agree more than we disagree.
Just a show of hands for those who don't agree with this? ;-)
> >Chimera is ahead of the game then --- I believe that the emacs browser does
> >something similar. But this is still browser dependent (I can't write one
> >external rendering agent and expect it to work against a whole class of
> >browsers)
>
> Yet. There is an interface specification in the works, it has been referred to
> occasionally over the last couple of months.
I'd really like to see this interface. Any idea when it might be
available? If something like this becomes insanely popular, it might be too
late or too hard to standardize the interface "the right way." Not to take
anything away from the Chimera developers --- but I would like to see if
their concept can do the things I need to do with a browser.
> >> OK then, I will agree with you. But the last thing we want is a monolithic
> >> browser, so that ceases to be a problem.
>
> >Let's not have a monolithic HTML+ standard then...
>
> That is not the same thing at all. It does not follow from what went earlier.
> Please show how going to a distributed model of implementation requires that the
> HTML 3.0 specification be subdivided.
If it's in the spec that browsers have to be able to start up external
rendering agents and allow for new types and renditions that weren't around
when the browser was created, then we've *guaranteed* that anything called a
Web browser can handle the distributed model. I want it to be hard and
unproductive to implement *only* a monolithic browser. That gives small,
helpful, responsive, nimble, creative, energetic, etc. players the advantage
in the commercial (and non-commercial) Web tool market. If we can specify
things like embedded interactive drawing programs (e.g. the scribble input
field) or embedded word processors (a logical extension of the text field)
then we can just about guarantee that the architecture itself prohibits
monolithic design.
> I think that is what I said, too. Yet you seemed to be arguing that only Frame
> or Microsoft should develop Web software. Perhaps this was a straw argument and
> I missed it?
Yes! The concept of *only* Frame and Microsoft developing Web tools goes
against everything I believe in. I think there should be a level playing
field --- and we should be making the rules right now. And I want the rules
to favor companies who produce standard, easily customized, modular software.
> >>Do you see
> >> some huge corporation coming out with statements like that? No.
>
> >No, but I do see some corporation modifying their desktop-publishing tools so
> >that they "do" HTML+.
>
> So what? If Frame can output HTML 3.0 I am happy (I use Frame 4.0 a lot, BTW).
> So it can output HTML better than WebMaker? Fine, if the price is right I buy
> it. I don't see that being able to convert WP to HTML has any effect on, say,
> someone developping an applet for news posting or whatever.
Then I would be happy too. But if 50% of the market starts using Frame
tools because they are so happy with it, Frame could pretty much dictate
what HTML 3.1 would look like. It might not happen all at once, but it would
happen.
Press Release: Frame announces Frame 5.0! HTML 3.0 fully
supported! Edit all of your old HTML documents. Add value with our
high technology super impressive whizzy proprietary extra features!
Now people start using Frame and those extra features. Who is really going
to know what's HTML 3.0 and what's not? Frame "hides" all that from the
user.
I'm starting to feel like Mr. Gloom and Doom here. However, I don't feel
off base. Several people have written me with comments like "Mosaic doesn't
define HTML, I'm glad everybody knows that now." I don't think everybody
knows that yet! Look at the "Mosaic and WWW Conference" coming up. Just
more reinforcement that Mosaic == WWW. (Not to slam the conference --- I'm
going and I feel lousy about missing the CERN conference.)
> >Then those become popular, the applet market goes away
> >and the Web becomes a boring place to live (for a programmer... :-)
>
> Not so. LaTeX2HTML is popular. Did that prevent Fish search appearing? Did it
> stop Chimera coming out? I fail to follow your argument; these issues seem
> nigh-on orthogonal.
LaTeX2HTML is *not* an applet in the sense we are talking about. It's an
example of a productive authoring tool. Fish search is a set of diffs for
Mosaic --- so it's not really an applet either. Chimera is a whole new
browser --- thankfully it is still realistic to build one. What I'm talking
about is the Frame example above. Browser X becomes so popular that HTML
becomes equivalent with what Browser X reads. HTML thus becomes so
complicated that browsers are very difficult to construct.
Now if Browser X is owned by an agressive commercial company, then applets
might not be desirable and the applet market dries up. Maybe the market
place won't let this happen. OLE does seem to be picking up steam ---
although I don't know enough about Windows products to know if vendors are
encouraged to use it, or whether it has stimulated an applet market.
> >what a lead-in! This is exactly one of the things I want to see allowed ---
> >you just defined a new tag (on the fly I suppose.) Why not allow the tag to
> >be formally defined in the document header
>
> a) and you were concerned about document complexity (according to the subject).
> Oh well.
Nope. I was never concerned with document complexity --- I admitted
straight away that it's going to be hard to add fancy new features without
complicating documents. However, what you just did wasn't complicated! It
might make a browser complicated --- but only if it wasn't designed into the
architecture to begin with. Lot's of programs do macro expansion --- this
is no more complicated than that.
> Anyway it seems we are pretty much in agreement. We just differ on how likely it
> is that a browser can be built as a flock of applets and that applets could
> conform to an interface specification and be portable across browsers. To which
> I would say, when Steve Putz hacked out the Xerox map browser I bet he never
> dreamed that CGI would let the same script work on CERN, NCSA and any other
> compatible server. Proof by related example (grin, ducks)
I think so too. It *is* amazing how much is standard in the Web. I think
this is partly mostly due to the organizations that are sponsoring a lot of
the work. I also think we were pretty lucky to end up with those
organizations too!
Anyways, there's been a lot of argument about the big mean company taking
over HTML. Not much discussion at all on my other points. At this point I
wish that I had never even put in that *one line*! Maybe I'll repost with
the point removed... :-)
- Ken
--
Ken Fox, fox@pt0204.pto.ford.com, (313)59-44794
-------------------------------------------------------------------------
Ford Motor Company, Powertrain | "Is this some sort of trick question
CAD/CAM/CAE Process Integration | or what?" -- Calvin
AP Environment Section |