Subject: pruning "redundant" properties while editing
From: Paul Rohr (paul@abisource.com)
Date: Fri Mar 09 2001 - 20:21:23 CST
Consider the following document fragment:
<p>Is the explicit property on <c props="font-weight:normal">this</c>
word redundant? Should it be eliminated?</p>
Off the cuff, most people would say yes. However, we need to dig a bit
further:
<p><c props="font-weight:bold">What if the entire sentence except for
</c><c props="font-weight:normal">this</c><c props="font-weight:bold">
word was bold?</c></p>
In case you're wondering, that's how our document format currently looks if
you make the sentence bold and then select the word "this" and toggle the
bold button off. Or consider the following document fragment:
<styles>
<s name="Strong" type="c" props="font-weight:bold">
<s name="Emphatic" type="c" props="font-weight:bold; font-size:48pt">
<s name="Weak" type="c" props="font-weight:normal">
</styles>
<section>
<p>All words after this <c style="Strong">will be bold, but is the
explicit property on </c><c style="Strong" props="font-weight:bold">this</c>
<c style="Strong"> word redundant?</c></p>
</section>
Essentially, the issue is whether and how to handle collisions between an
explicitly set property and the underlying style or default. We currently
maintain the two separately, at the cost of some occasional verboseness.
If we want to implement a consistent pruning strategy at edit time, then I
expect that we'd need a "last one wins" rule. For example:
1a. When applying an explicit property that matches the underlying default,
prune it. The default already took care of it.
1b. When applying a style, prune any matching explicit properties inside
the span. The new style takes care of it.
NOTE: This does mean that you may get different behaviors if you undo such
a change (the prior explicit properties come back) rather than toggling it
again (say, via another style with different properties).
To compare the effects of this proposed pruning strategy (call it PRUNE)
with our current behavior (NOW), assume that you have the Strong and Weak
styles as defined above. Some potential screw cases to think about:
A. a Normal sentence, so it defaults to non-bold
-------------------------------------------------
- you select the whole sentence and make it bold
- you select a word and make it non-bold
- Q: should that word have an explicit property or not?
- NOW: yes
- PRUNE: no
- now apply the Strong style to the whole sentence
- Q: should that word be bold or not?
- NOW: yes
- PRUNE: yes
B. a Normal sentence, so it defaults to non-bold
-------------------------------------------------
- you select a word and make it bold
- now apply the Strong style to make the whole sentence bold
- now apply the Weak style to the whole sentence
- Q: that word should be bold now, right?
- NOW: yes
- PRUNE: no
C. a Normal sentence, so it defaults to non-bold
-------------------------------------------------
- you select a word and make it bold
- now apply the Strong style to make the whole sentence bold
- undo once to remove that style
- Q: that word should be bold now, right?
- NOW: yes
- PRUNE: yes
D. a Normal sentence, so it defaults to non-bold
-------------------------------------------------
- you select a word and make it bold
- now apply the Weak style to make the whole sentence non-bold
- Q: that word should be bold now, right?
- NOW: yes
- PRUNE: no
- now apply the Strong style to the whole sentence
- now apply the Weak style again
- Q: that word should still be bold, right?
- NOW: yes
- PRUNE: no
E. a sentence is affected by the Strong style
----------------------------------------------
- you select a word and make that not bold
- Q: should that word have an explicit property?
- NOW: yes
- PRUNE: yes
- you select that same word and make it bold
- Q: should that word have an explicit property?
- NOW: yes
- PRUNE: no
Presumably, either strategy could be implemented consistently, but they have
different effects, so it'd be worth playing around with the competition to
see which behavior people expect.
New logic to deal with this would be welcome, but should be *throughly*
tested. For obvious reasons, some degree of paranoia is warranted.
Paul
This archive was generated by hypermail 2b25 : Fri Mar 09 2001 - 21:17:43 CST