> I don't understand what the fuss is about. View <BR> as a postfix
> operator if you like. The semantics are clear enough.
How "tightly" should it bind?
Does it apply to the "current line" (assuming the h&j
algorithm works a line at a time), or the current paragraph
(assuming it works a paragraph at a time like in TeX)?
If the former, paragraph-at-a-time line breaking algorithms
will have difficulty implementing it (try to do this with TeX,
for instance), and vice versa (a simple word wrapping algorithm
won't work anymore).
(I personally don't like the idea of a postfix operator in SGML to
begin with -- elements should only affect their children and
linked elements.)
> Can you explain
> how it would "wreak havoc with DSSSL-Lite based implementations"?
DSSSL works by mapping elements onto "flow object sequences"
and specifying the characteristics of each new f-o-s when it's created.
Full DSSSL queries are powerful enough to "look ahead" to
see if there's a <BR> element coming up that might change the
alignment characteristic, but DSSSL-Light queries are *not*.
D-Lite only has access to ancestor (and in some cases, predecessor)
elements when it creates a new f-o-s. Text alignment is a
characteristic of the "paragraph" f-o-s, so this must be determinable
from the <P> element or its ancestors.
> The alternative is to use the TAB element to specify alignment of subsequent
> text as centered (on the tab) or right aligned.
This sounds cleaner to me.
--Joe