Date: Mon, 1 Jul 1996 12:18:33 +0200 Message-Id: <199607011018.MAA24774@www4.inria.fr> To: firstname.lastname@example.org Cc: Thomas Reardon <email@example.com>, Subject: Re: Introducing NetscapeML In-Reply-To: <31D72041.46B3@netscape.com> <31D72041.46B3@netscape.com> From: Hakon Lie <firstname.lastname@example.org> Alex Edelstein <email@example.com> writes: > There is indeed copious "market demand" for the simple yet powerful > extensions. We completed them earlier than we expected and are eager to > get them into a beta product and try them out. We continue to work on > implementing CSS and other HTML 3.2 features. I'm glad to hear you are implementing CSS. The functionality you propose to add throught the SPACER and MULTICOL elements is in demand. That's why CSS has been developed. I think the discusson over your altenative markup will benefit from a technical angle. I include a little comparision of the fuctionality in CSS and NSML. Short summary: - if you have implemented NSML, you have done a significant part of CSS - the lack of units other than pixles (please correct me if this is not the case) is limiting for device-independent authoring Regards, -h&kon Hakon W Lie, W3C/INRIA, Sophia-Antipolis, France http://www.w3.org/people/howcome firstname.lastname@example.org SPACER Using the SPACER element, three different effects can be achieved depending on the TYPE attribute. 1) With TYPE=horizontal, the effect is equivalent to the 'word-spacing' property of CSS1 NSML: <SPACER TYPE=horizontal SIZE=10> CSS1: <DIV STYLE="word-spacing: 10px"> Note that the SIZE attribute only accepts pixel units; typically this property should be specified relative to the font size (e.g. in 'em' units): CSS1: <H1 STYLE="word-spacing: 2em"> 2) With TYPE=vertical one can set extra (also negative?) space between lines of text. In CSS, one would use the 'line-height' property for this. NSML: <SPACER TYPE=vertical SIZE=10> CSS1: <DIV STYLE="line-height: 10px"> Note that the CSS1 property describes the height of the line including the font size, while the NSML size refers to extra spacing between lines. Either method will to the work. As with word spacing, horizontal spacing is most often specified in relation to the font size: CSS1: <H1 STYLE="line-height: 120%"> Also, CSS1 supports a common typographic shorthand notation: CSS1: <H1 STYLE="font: 12pt/14pt helvetica"> In the example above, the line height is set to 14pt. 3) With TYPE=block, the SPACER element behaves quite differently from the other two types. According to the values of the WIDTH and HEIGHT attributes, a box is created and the content of the SPACER element is flowed into the box. The box is positioned according to the value of the ALIGN attribute. NSML: <SPACER TYPE=block WIDTH=100 HEIGHT=200 ALIGN=LEFT> CSS1: <DIV STYLE="width: 100px; height: 200px; float: left"> The comparison of the two methods is not as simple as the example above indicates. E.g., In CSS1 the 'float' property only indicates on what side of the box content will flow. The positioning of the box is left to the margin properties which allows more detailed control. Again, the lack of units other than pixels will limit the functionality of the SPACER element. MULTICOL The MULTICOL element is proposed as method for achieving multi-column layouts with text flow from one column to the other. In order to keep the initial implementation threshold low, there is no similar functionality in CSS1. Given the proposed MULTICOL element, browser vendors now seem ready for this. A proposal for adding multi-column support in CSS can be found in .  http://www.w3.org/pub/WWW/Style/css/multi-column.html As always, this proposal is up for discussion before going into a specification. Still, it is interesting to compare the proposed functionality with the MULTICOL element. There are two main differences: 1) MULTICOL has a required attribute, COLS, which determine the number of columns. I.e., the number of columns will always be constant. In the CSS proposal, if the column width is set to a length unit (e.g. 20em), the number of columns will increase as the browser window is enlarged. The latter model seems better for device-independent authoring. 2) In CSS, the column width value is only used to determine the number of columns. When that number is found, all available is evenly divided among each column. This policy values screen real-estate over author control. (By setting the 'width' value on a surrounding DIV element, a certain width can also be set in CSS, but this is cumbersome) It's trivial to change either specification to reflect another policy -- which one do we want? Also, there is an issue of how columns should scroll: as a stick or as a snake?