Re: Standardizing new HTML features... WE'RE INTERESTED!

Dave_Raggett <dsr@hplb.hpl.hp.com>
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-id: <9304281250.AA20117@manuel.hpl.hp.com>
Subject: Re: Standardizing new HTML features... WE'RE INTERESTED!
To: raisch@ora.com
Date: Wed, 28 Apr 93 13:50:22 BST
Cc: www-talk@nxoc01.cern.ch, mcrae@lib.ucsf.edu, dale@ora.com
Mailer: Elm [revision: 66.36.1.1]

Rob Raisch writes:

> Dave,
>        O'Reilly and Associates is *extremely* interested in helping you with
> this effort.  We have a number of products in development which use HTML as
> their technology base.  We see the future development of HTML to be of great
> importance to our efforts.

Thank you, any help would be greatfully appreciated.

> I would suggest that lists and text flow are really exclusively
> rendering issues.  When I want to make a nested list, I may wish to write it

...

> But since there is no rendering information in HTML, and by definition there
> cannot be, how the terms appear on the screen is left up to the renderer.

The current HTML standard as defined by the DTD forbids nested lists. It is
therefore no surprise that the line mode browser doesn't support them. Other
browsers have made extensions to the standard. It is certainly true, that the
SGML DTD doesn't specify how such lists should be rendered, however, the
accompanying description should provide sufficient guidelines, that authors
will have an adequate idea of how each construct will appear. The current
document says for example:

   "The representation of a list is not defined here, but a bulleted list for
    unordered lists and a sequence of numbered paragraphs for an ordered list
    would be quite appropriate. Other possibilities for interactive displays
    include  embedded scrollable browse panels."

The current spec needs extension to define what kinds of nesting of list tags
are permitted together with some comments on rendering issues.

> A form or table cannot be specified in HTML without breaking one of
> HTML's first principles since forms and tables are descriptions of the
> appearance of information in relationship to other elements and not the
> description of information in terms of type and content.

I think you are mistaken here. Forms can be defined in terms of a collection
of fields with specified types and allowed values. My proposal does indeed
do this - leaving it up to the browser to decided how to render the form. One
may also want to make it possible for authors to pass hints to browsers, but
this is a separate issue. Tables too, can be specified without getting mixed
up in the details of rendering, although some layout hints are useful.

Regards,

Dave Raggett