On Tue, 3 Oct 1995, Scott E. Preece wrote:
> From: "Daniel W. Connolly" <[log in to unmask]>
> | In message <[log in to unmask]>, Brian Behlendorf writes:
> | >
> | >
> | > HTML Evolution Considered Harmful - And a Path Out
> | > Version: 1.0
> | Er... in case folks should get the wrong idea from the lack of
> | responses, I like this proposal very much, and I'm doing what
> | I can to make it happen.
> My reaction to the proposal is "Well, maybe...". It depends a lot on
> how well the embedding mechanism comes out and how widely and
> consistently it is provided, and how hard it is to write renderers for
> the common browsers.
Yup - the NCAPI is something people could use right now, but I think the
Java route is much more promising. "I don't understand this data type"
"Okay, here's the (cross-platform) code to render it". it's still not clear
whether Netscape's 2.0 browser will support java to this level, or just the
inlined-game-and-animations that everyone's seen so far. If someone from
Netscape or Sun could speak here.....
> I don't see how this is a time-saver, though.
> The spec for tables, for instance, would have to include just about all
> of the HTML spec. And, worse, every time the HTML spec is revised, the
> dependent specs will need to either be cloned for the new one or revised
> to match it. This seems like lots more opportunities for error or
Private email has suggested that tables are mature enough to make it into
the core-HTML cut, so I withdraw this suggestion for plucking tables
out of the HTML effort (and will revise my proposal appropriately towards
the end of this week). You are right, some sizeable subset of the HTML
spec would have to be put into the tables data type if it were separated,
but not everything, since you could transclude HTML documents inside the
tables document. You would want to get enough so people weren't doing
> And I don't see how you've avoided Brian's issue ("you must
> be using this browser to view this page") - you still must have access
> to something that will render the extension in a way compatible with a
> browser you have access to.
No. If say tables were made their own data type, and I linked from an
HTML document to a table like this
then I can content-negotiate on "foo-table". If the browser doesn't
support "text/html-tables", but does support "text/html" or "text/plain",
I can provide some reasonable alternative.
> I completely agree with the desirability of the EMBED element, but it
> seems like a painfully heavy way to represent things that are
> essentially text-like (like equations and tables), as well as adding to
> the author's burden by (am I missing something?) forcing the tables,
> equations, etc., out of the document and into separate resources.
Depends on the authoring tool. Think of when you import that Excel
spreadsheet graph into a Word document... it potentially increases the
number of different files on a server that represent a "document", but
whether this is a problem or not depends on the authoring process.
Frankly transclusion is a *huge* boon to content with oft-repeating
elements - if you have the same table or image in 5 different places it
makes sense to have it transcluded rather than static.
> Frankly, whether this group steps up to maintain a consensus HTML
> standard or not, there will be one. I think we're better off with a de
> jure standard than we would be with a de facto one, but this proposal
> leads directly to the latter.
Ack! I was hoping the point I was getting across would be: let's get
HTML to some stable point and *freeze* it, and shuffle attempts to add
functionality towards alternate embeddable data types. I more than
anyone else decry the defactoization of the design of HTML.
More as it develops...
[log in to unmask] [log in to unmask] http://www.[hyperreal,organic].com/