Dear Michael,
Comments on LINK and mailTo:
---------------------------
> first, i mentioned that we are planning to use something like:
> <link rev=made href="mailto:...whatever..." >
> to allow info providers to provide a path for readers (through their
> clients) to contact them with comments. note that this is a (static) "link"
> rather than an (executable link, or) anchor, whereas your MSG tag is an
> "executable" link. lynx will support a command that will search out
> the static info and open a mail screen for the user with the address already
> in place.
What do you mean by static link? Do you mean a browser menu option that lets
users mail comments back to authors? Sounds like a good idea. How do you
specify values for the subject and other header fields? I guess you could
use the TITLE attribute for the subject, but that seems pushing the notation
too far from its original concept.
{\begin aside}
While I think about it, the attribute "REV" and Tim's suggested values aren't
particularly transparent. Perhaps HTML+ should use "REL" for relationship
rather than "REV" (why "REV"?). Also "author" might be better than "made".
What is the METHODS attribute intended for? Does anyone use it?
What are your views on the attributes for LINK?
{\end aside}
My latest version of the HTML+ DTD includes a FORM tag in place of MSG.
<!ELEMENT FORM - - (MH*, (%main;|INPUT|SELECT)*)>
<!ATTLIST FORM
id ID #IMPLIED
action %URL; #IMPLIED>
<!ELEMENT MH - - CDATA -- RFC 822 header fields -->
The idea is that you could have multiple forms in each document. The FORM
tag acts as a wrapper for each form and defines the action to be take when
the user presses the "commit" key.
By specifying a mailTo URL the form would be mailed to the designated
person. The MH tag allows you to specify the mail headers is a more
general way that would be possible with attributes to the FORM tag itself.
<FORM action="mailTo:grobe@ukanaix.cc.ukans.edu">
<MH> Subject: comments on proposal
<INPUT id="f1">Your Comments</INPUT>
</FORM>
The presence of "mailTo:" in an LINK or A element would imply the need to
pop-up an editor for the message with the appropriate header fields already
filled in. The FORM element on the other hand creates the message itself.
If the action starts "http:...", the form would be sent as a query for
this URL. The encoding of the forms contents would depend on the METHODS
attribute and default to an id:value listing following a "?" suffix.
I still need to do some more work on the actual details of the encoding format,
e.g. escaping white space and dealing with multiple values. In practice, it
seems much nicer to define a new HTTP method for forms data, than to try and
force it into the URL syntax.
Comments on Tables
------------------
I am getting uncomfortable about the detailed column specification format,
e.g. it defines how wide the fields are without taking into account the width
of the headers.
A better approach would be to let the browser work this out for itself.
This fits in well with your suggestion for adding a placement attribute to
specify center, left, or right justification. In the following I have
used a separate tag for tables rather than overloading DL:
<!ELEMENT TBL - - (TT?, TH*, TD*)>
<!ATTLIST TBL
id ID #IMPLIED
cols CDATA #REQUIRED -- number of columns --
compact (compact) #IMPLIED -- if present use compact style --
border (border) #IMPLIED -- if present draw borders -->
<!ELEMENT TT - O (%text;)+ -- table title -->
<!ELEMENT TH - O (%text;)+ -- column heading -->
<!ATTLIST TH
S NUMBER 1 -- columns spanned --
L (L) #IMPLIED -- left aligned --
C (C) #IMPLIED -- center aligned --
R (R) #IMPLIED -- right aligned --
D (D) #IMPLIED -- decimal aligned -->
<!ELEMENT TD - O (P|UL|OL|%text;)+ -- field data -->
<!ATTLIST TD
S NUMBER 1 -- columns spanned --
L (L) #IMPLIED -- left aligned --
C (C) #IMPLIED -- center aligned --
R (R) #IMPLIED -- right aligned --
D (D) #IMPLIED -- decimal aligned -->
The above approach allows you to state <TD L> which is perhaps nicer
than <TD A=Left>. The drawback is I don't know how in SGML to define several
attributes as being mutually exclusive. *** What do you think? ***
An Example of a Table
___________________________________________________
| | average | other |
| | height | weight | category |
|_________________________________________________|
| males | 1.9 | .003 | yyy |
|_________________________________________________|
| females | 1.7 | .002 | xxx |
___________________________________________________
<tbl cols="4" border>
<tt> An Example of a Table
<th> <th s="2"> average <th l> other
<th> <th> height <th> weight <th l> category
<td> males <td> 1.9 <td> .003 <td l> yyy
<td> females <td> 1.7 <td> .002 <td r> xxx
</tbl>
The browser works through the table to determine the types and widths of
each field and how much room to allocate for each column. Using a fixed font
for tables would speed things up a bit. By default headers are centred while
text fields are left aligned. Numbers are vertically aligned on the units,
making them harder to deal with.
How does that sound?
Dave Raggett