LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives

HTML-WG Archives

HTML-WG Archives


Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font


Join or Leave HTML-WG
Reply | Post New Message
Search Archives

Subject: Re: PROPOSAL: HTML Evolution Considered Harmful - And a Path Out
From: Brian Behlendorf <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Wed, 4 Oct 95 02:18:42 EDT

text/plain (90 lines)

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
> omission.  

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 
this constantly.

> 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

<EMBED SRC="foo-table">

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/

Back to: Top of Message | Previous Page | Main HTML-WG Page



CataList Email List Search Powered by the LISTSERV Email List Manager