Re: Introducing NetscapeML
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
- the lack of units other than pixles (please correct me if this is
not the case) is limiting for device-independent authoring
Hakon W Lie, W3C/INRIA, Sophia-Antipolis, France
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'
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
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.
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 .
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
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
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