<percentage-from-free-space>

> Not fuzzy at all.  width:auto is equivalent to what you call
> width:100%%. (assuming that there are no other %%'s
> bedeviling it.)
This shows that the concept is easy to understand as this statement,
which repeats Andrew's own example, comes from Ernest who hasn't
(as he admitted in his previous message) followed the thread.

> But it is only used where <length> is used, but not in every
> place that <length>is used.  That is why I called it a
> specialized <length>
To my best knowledge so is <percentage>.
Then it qualifies as specialized <length> as well.
Such wordings only make confusion.

I'm starting to appreciate this idea (and even its orthogonality to calc).
Much progress has been done by Andrew in expressing his ideas clearly.
I think the effort of the list's participants has been worth it.

to Andrew:
1. If you write down a specification of a new CSS value type
<percentage-from-free-space> along with the set of properties
to which it's applicable (preferably by listing exceptions from
<length> to focus discussion) and an algorithm, I'm willing
to review it for wordings which are poor English (unless you
find someone at a higher level than my CAE Grade A,
which you probably can being a major CSS expert in Russia),
misleading or contradict well established CSS concepts
(preliminarily, as it will then go to this list and be exposed to
the expertise of CSS WG members).
2. You implemented an algorithm for * units. Answer specific
questions in terms of what this algorithm does in specific cases.
You can even quote code fragments in the programming language
you used (your renderer has got a source code, I presume).
Or some pseudocode. Others do sometimes. Provide
renderings of snippets other make up to express their doubts
along with explanations. If you feel renderings or algorithms
other than yours may be investigated, state it separately.
3. When your specification proposals and algorithms are
high quality, you'll be entitled to expect the same from others.
It's playing by the rules - set them high.

I hope others will agree with my suggestions for Andrew.

> If you want over-constrained equations to be a possible
> result from using %%, Then using 100%% as the "sum"
> all of the time is more efficient and allows you to generate
> any layout that your method does.
I can't see why it would be possible to reproduce effects
of assigning *s which sum up to more than 100* or less with
leaving some space unused. It may seem the more case could
be scaled by the author byt don't forget the property assignments
with * units in a given box may come from many different sources.
I don't actually understang what "using 100%% as the "sum"
all of the time" was intended to mean.

I think we shouldn't doubt Andrew did read the whole spec.
He implemented it. Besides, nothing in what he wrote makes me
suspect his skimming only of the text. So I don't understand the
personally critical responses he gets, especially from Anne.
I suppose you folks just aren't used to his style of making
arguments, thus find it annoying. Is it specific to Slovians?

As for the auto value:
<percentage-from-free-space> ::= <numeric-value>"*" | 0 | auto
<percentage-from-free-space> doesn't apply to any properties
to which the auto keyword does. Therefore auto can always be
parsed unambiguously as a keyword or a <percentage-from-free-space>
value. In the latter case it means: divide the remaining free space
equally among all the properties with auto value competing for it.
"all" in the previous sentence seems to actually contradict many
sentences like "If 'width' is set to 'auto', any other 'auto' values
become '0' and 'width' follows from the resulting equality." (if I haven't
confused the levels at which competition for free space with *
occurs, which may (should?) be different from
http://www.w3.org/TR/CSS21/visudet.html#blockwidth).
Replace it with "all at the highest priority level at which there is
at least one property with auto value, setting all competing
properties with auto value at lower levels to 0" and define
width and height to have the highest priority?

Krzysztof Maczyński

Received on Friday, 21 May 2004 21:05:57 UTC