Re: spacing rules

>6. The proposal treats relational signs such as "=" and "<" as
>operators...

yes...

>(presumably with truth values as range).

no ... that's semantic information which this proposal makes no
attempt to specify. We know nothing about the domain or range
of the operation represented by any operator (nor indeed,
whether it really specifies an operation at all) -- we only
know that it is syntactically an operator, and that the expression
headed by it is a term (or an embellished operator).

>I am assuming
>that the standard visual rendering which places more whitespace
>around these symbols than, say, binary operators such as "+" and
>"*" would be achieved on the basis of precedence values.  Is this
>true? The lower the precedence the wider the space?  Done on a
>continuity basis (this might make things harder to read)?  Is
>this for infix operators only?

The group has not yet decided, I think, whether the standard will specify
any spacing rules at all. This is a controversial issue.

One possible position (the "cleanest" one) is:

1.

This is entirely up to the renderer, not part of HTML-Math per se.
We're not specifying the rendering itself, for various reasons
(as I understand it):

- even if we did, this would only apply to the 2-D graphical media,
  but this proposal supports all media (in principle);

- it's technically infeasible to specify this fully very soon;

- if we did, this would preclude different vendors of renderers
  from competing on the quality of the rendering (maybe you
  would think preventing this would be a good thing?);

- this would bias the proposal towards some existing renderers and
  away from others;

- this would go "against the spirit of HTML".

A specific renderer is free to choose spacing rules either based
on precedence values, or on a table of specific operators, or in any
other way.

A specific renderer-vendor is of course free to specify the spacing
behavior of its own renderer, and/or to allow this to be customized
via style sheets.

This situation makes it impossible for authors to "tweak" their
expressions (e.g. by adding thin spaces) and get consistent results.


Another possible position is:

2.

The same as (1) for most aspects of spacing rules,
but the standard will specify the spacing rules for
the "mrow" layout schema (i.e. for horizontal sequences
of operators and terms) since it so important for the
correct visual perception of precedence, and in order
to make consistent author-"tweaking" possible.

The fact that this violates the spirit of HTML
and biases the standard towards 2-D graphical media
are unfortunate concessions to practicality.

The fact that this prevents renderer vendors from
improving rendering quality while remaining compliant
is either another unfortunate concession to practicality,
mitigated to some small degree by at least saying that
this level of compliance is only "strongly suggested",
or is circumvented by having these vendors implement their
nonstandard spacing rules by supplying suggested style sheets
for viewers to use, rather than by changing the default behavior
of their renderer.


Policy choice (2) has at least a few subalternatives:

2a. Spacing is specified "absolutely" (except relative to font size).

2b. All that we specify is how inter-symbol spaces should compare --
that is, when they should be the same, greater, or less than other
such spaces.

2c. Like (2b), but even this is only partially specified,
e.g. within individual non-parenthesized sequences of terms
and operators.


I've been proceeding on the assumption that any of these
policies may become the finally accepted one. Fortunately
it is possible, if horizontal spacing rules are eventually
specified, to do this at the last minute, after everything
else has been done, with no harm except that at that point
some existing code might become noncompliant by decree.


People who favor view (2) should propose specific spacing rules,
or properties they should have, or which subview of view (2)
they favor and why.