Internet Standards

home *** CD-ROM | disk | FTP | other *** search

/ Internet Standards / CD1.mdf / INET / IETF / HTML / 95APR.MIN < prev

Wrap

Text File | 1995-06-26 | 13.6 KB | 375 lines

CURRENT_MEETING_REPORT_ Reported by Eric Sink/Spyglass, Inc. Minutes of the HyperText Markup Language Working Group (HTML) [All references to a specific page number in Dave Raggett's HTML 3.0 proposal are in fact references to the version dated March 28, 1995.] It was agreed that Dan Connolly would chair the week's meetings of the HTML Working Group. Navigational Aids for HTML 3.0 Dave Raggett presented an overview of navigational aids for HTML 3.0, to extend an HTML user agent by adding active icons to the toolbar. (See HTML 3.0, page 19.) The proposal is to continue to use the <LINK> element in combination with a registered set of REL and REV attribute names. It would be left up to the user agent or a style sheet to determine how/if to present or render these navigational aids. Issues: o The REL and REV attribute semantics are not intuitive. A clearer description of the meaning of a relationships in either direction must be set out in the proposal. This description must coincide with current practice and not break backward compatibility. o The list of name tokens in the proposal conflicts with current usage, reference should be made to existing implementations to avoid backward incompatibility. [Specifically, SCO uses ``next,'' ``previous,'' ``contents,'' ``index,'' ``navigate.'' Note that these are all lower-case names. The semantics of REL are ``what the target document is in relation to the current document.'' In SCO's document, ``contents'' means ``table of contents.''] o Name tokens should not be mixed case. In general, lower case name tokens are preferred. A Proposed <BANNER> Element Dave Raggett presented an overview of a proposed <BANNER> element, which would occur at the top of the body element, contain body text, and would typically remain persistent at the top of a user agent's window. o Should <BANNER> be in <HEAD> or <BODY>? Arguments were presented for both views. o Should banner be specified via the <LINK> mechanism with REL=``banner''? o Should <BANNER> have position attributes to provide for persistent banners at left, right, top, and bottom of a user agent window? File Upload Proposal There were no comments on the file upload proposal from Larry Masinter. Multi-Part Forms There was some discussion of ``Multi-part forms.'' One issue is that MIME type is not registered. Someone commented that it is ``stable, don't break it.'' Another comment was that it is ``dangerous to do backward incompatible.'' Client Side Image Maps Client side image maps were mentioned but there were no comments from the floor. Scripting Scripting, according to Dan, is out of scope for HTML. The group did not uniformly agree. Dan asserts that scripting on the WWW is ``early and experimental.'' Others disagreed -- Dan recants. Dan explains a bit about HotJava and promises to post the following URL to the list: http://java.sun.com/ The HTML 3.0 Proposal for Tables Dave Raggett reviewed the HTML 3.0 proposal for tables. o Table consists of rows which contain cells. Captions may be positioned with attributes. o There are two types of cells: head and data (TH and TD). Cells should not overlap, but if they do, the result is implementation-defined. o Dave explained how TH is used to identify cells which are heading cells, and that the CLASS attribute could also be used to identify a complete row as a heading row. o Jon or Terry pointed out a potential need for persistent left or right stub-head columns. o Dave explained that the table model meets the need for addressability of data in a table. o Murray asserted need for table head and foot, and closer compatibility with CALS model. Head and foot could be presented in persistent areas on screen or by having scrollable table. o Dave demurred. Jon pointed out that the burden of proof is on the unproven HTML 3.0 table model. o Yuri asserted that the existing model could meet everybody's needs with minor adjustments. The biggest issue seemed to be: colspec attribute vs. <COLSPEC> elements adding <THEAD> <TBODY> and <TFOOT> elements nested tables allowed in HTML 3.0 proposal Dan and Tim suggest the need for a break out meeting to discuss and resolve this issue and report back to the meeting on the following day. A brief report of that breakout meeting is included later in these minutes. Math Fragment Dave presented an overview of the math fragment of the HTML 3.0 proposal. Issues: o Math fonts. Dave proposes a 98% solution which requires the specification of a 256-character set of math symbols. A mechanism for downloading fonts over the net may solve the remaining 2%. o A liaison with the American Mathematical Society is called for. Proposal for Style Sheets Dave presented an overview of the HTML 3.0 proposal for style sheets. Insists on clean separation between style and structure. <STYLE> element in the <HEAD> of a document can contain the proposed DSSSL-Lite style information, or the <LINK REL=style HREF=...> approach could be used. Assuming DSSSL-Lite as a style specification mechanism, control over such features as drop caps, indentation, custom bullets, backgrounds, etc., is possible. A publisher (information provider) could override general style information -- for a paragraph or list type -- by ID or by sub-CLASS. o Lou mentioned that Netscape does not ignore the content of a <HEAD> element and that code is appearing at the top of documents. Tim Berners-Lee replied that the HTML 2.0 specification clearly states that content in a <HEAD> is to be ignored. o Lou and Murray both assert that the use of style sheets and DSSSL-Lite on one hand, and style attributes on the other, need not be mutually exclusive. Tim Berners-Lee says that the two world views need to be reconciled into a workable compromise. Table Meeting Approximately 18 people met in the Buckingham room to discuss table issues on the evening of Wednesday, 5 April. Yuri Rubinsky acted as chair of meeting. The meeting started out with a brainstorming session to enumerate objectives and issues. The uppermost objective was to resolve the issue in a timely manner -- i.e., get it done at this meeting. Support for ICADD and legacy (CALS) tables were also listed. The pros and cons of the CALS and HTML 3.0 proposal's models were then discussed. It became clear that there were several minor issues related to attributes and their permissible values, and that there were major issues related to the use of the colspec attribute vs. the <COLSPEC> element, and the introduction of <THEAD>, <TBODY> and <TFOOT> elements. Eventually, the participants arrived at a consensus that the <COLSPEC> element was preferable to the colspec attribute. Dave resisted this for a while, but finally agreed. There is no point in going into the entire discussion. One major point of contention was Murray's assertion that the HTML Working Group had decided that the HTML DTD was not intended for manual keying and need not be optimized for that purpose. Dave does not agree with that principle, and it will be useful to review this issue in the context of the working group at large. Murray requested that the DTD reflect <ROW> as an equivalent for <TR>, and <ENTRY> as an equivalent for <TH> and <TD>. Dave indicated that he prefered not to do this, and Jon and Yuri pointed out that since some conversion would still be required to transform CALS table to HTML table this could be accomplished in the transformation. Murray withdrew the request for this change. In order to achieve quick consensus on the remaining issue, It was proposed that the content model for table might be approximately as follows: <!ELEMENT table - - (caption?, colspec*, thead?, tbody, tfoot?)> <!ELEMENT thead - - (colspec, tr+ )> <!ELEMENT tbody o o (tr+ )> <!ELEMENT tfoot - - (colspec, tr+ )> <!ELEMENT (th|td) - o %body.content > This model is compatible with the HTML 3.0 proposal, except for the <COLSPEC> element, inasmuch as the <THEAD> and <TFOOT> elements are not required and the existing classing mechanism can continue to be used. Because the <TBODY> element requires neither start nor end tags, its use may be inferred. Thus, aside from the introduction of the <COLSPEC> element -- providing the minimum required for CALS and ICADD -- the pre-existing HTML 3.0 table model remains largely intact. However, the new model allows for the explicit use of the <THEAD> and <TFOOT> elements. The participants felt that this was a workable compromise between the HTML 3.0 proposal as it stood and the working group proposals that a partial or full subset of CALS was required. HTML Working Group Meeting -- Day Two Move for closure on HTML 2.0 Dan moveds for closure on HTML 2.0. There was a lone dissenter. David Morris (Barili Systems) presented a list of issues. Discussion ensued. Issues: o There was an objection to the rush. There were major changes to the structure and content of the draft specification days before the working group meeting at IETF. Nobody had time to review the resulting document properly. o Point of order -- all official documents should be posted to the IETF mailing list. The html-wg list is necessary but not sufficient. o Character set issues remain. The group was not convinced that this is a closed issue yet. There were disagreements over terminology. It was insisted that HTML 2.0 language be extensible to support character sets beyond ASCII and 8859-1. This was a lengthy discussion. There was consensus that HTML 2.0 is not quite ready yet. Aside from potentially minor edits to address some of the concerns raised by David Morris, the language surrounding character sets and encodings, and extensibility for the future must be addressed to the satisfaction of the working group. Proposal for Movement from HTML 2.0 to 3.0 Dan presented a proposal that movement from HTML 2.0 to 3.0 must be achieved through the introduction of little specifications which provide incrementally increased functionality. An RFC on tables could be ratified more quickly than a thorough review of another HTML specification. Similarly, Larry Masiner's file upload proposal. Dave Raggett expressed some concern that this approach will result in more work for him in developing a unified HTML 3.0 specification. Tim Berners-Lee agrees that efforts should be made to reduce the amount of rework required on Dave's part. There were seemingly more folks in favor of this approach. Expert groups can focus on smaller problem spaces. Successive releases of HTML 2.* can incorporate whatever is ready -- ``train leaves the station'' model. The general consensus reached was that HTML 2.? should contain tables and perhaps whatever other improvements are ready. Guidelines for determining what should go into an incremental release of HTML 2.* specifications are: o Timeline o When controversy over proposed inclusions dies down o How desperately the addition is needed o How quickly it is implementable Murray asserted, and Dan agreed, that all HTML 2.* specifications must derive from a ratified HTML 2.0 specification. This would have the least affect on the HTML 3.0 work and would require the least re-review of sections of specification which have not changed. Browser Developers -- File Upload Larry Masinter wants to know what are the intentions of the browser developers with respect to file upload. Lou from Netscape says that it will be implemented as soon as they can. How to Differentiate Browser Capabilities There was discussion of how to differentiate browser capabilities. Should we continue to rely on Version and Level values, or add a Features parameter? The group eventually agreed to work with Version and Level parameters. Results of the Tables Meeting Dave Raggett reported on the results of the tables meeting. The agreed table model is a better fit with CALS tables, and provides better control via style sheet mechanisms. The notion of scrolling tables is accepted, leading to the acceptance of head, body and foot elements for tables. Dave says that a draft of the revised proposal will be ready for release at the next IETF meeting (Stockholm, July 1995). Dave also states that he intends to seek further input at the upcoming WWW Conference (Darmstadt, April 1995). Murray agrees with Dave's comments and adds that this is a workable compromise which allows the pre-existing model to continue to be used (delta colspec changes) while allowing CALS tables to migrate more readily. File Upload Proposal On the subject of the file upload proposal, Larry Masinter pointed out that a simple implementation exists at: ftp.eit.com/pub/fileup Tim Berners-Lee polled the floor to determine whether there is consensus on the proposal moving forward. Based on feedback, Tim indicated that the proposal may not have been reviewed sufficiently. Further review and feedback is required to proceed. Liaison Activities There was discussion of liaison activities and how HTML 2.* specifications should be developed. Glenn Adams (Unicode) expressed his hope that the Unicode Consortium members will become more involved. Ed Levinson, chair of the MIMESGML Working Group invited participation and pointed out that there is already cross-pollination. Glen Rippel (Bitstream) indicated that there is a need for further discussion of fonts for European and non-European languages. Jon Bosak and Dave Peterson pointed out that SGML is subject to change and voting membership in the ANSI committee costs only $900.