> Because HTML is relatively simple, writing a browser is also simple
(compared
> ...
> What it feared is that HTML will get more complex - and some of the
> suggestions posted here recently (arbitrary SGML code, etc) threaten to make
> it an order of magnitude more complex. Yes, there is going to be a tradeoff
> between adding features and keeping it simple - the tables, in my mind, are
a
> good example of a complexity that adds significant ability.
Well said.
> Hopefully there's a solution to this worry - enhancing and maintaining
libwww
> might be the best way, as it would hopefully take care of common complex
> lower-level functions, and putting as much effort into high-level tools as
> possible (a product integrating a browser, editor, *and* server would be
> nice) would help too.
I think that this will take significantly more effort than hoping. :-) The
approach you outline is similar to my "sample" implementation proposal. I
agree that this is extremely useful --- it's worked out *extremely* well for
X.
I believe the real solution is to segment HTML into separately implementable
pieces and then provide the glue to hold those pieces together. My first
article touches on this. If there's continued interest, I'll post a more
technical article detailing my approach to the problem. Who else is working
on this issue?
> Here's to the future.
>
> Brian
- Ken
-- Ken Fox, [email protected], (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 |