Lennon Day-Reynolds writes:
> wouldn't be terribly difficult to assign some attribute to those instances
> of the <br> tag that were added automatically, so that they could be removed
> before a file was saved to disk.
We already have a mechanism for adding such attributes, and then
removing any tag with the attribute when the document is saved.
Joe Francis writes:
> We thought about that. We could still do it. But it opens us up to
> more runtime difficulty. The user may make use of the breaks in a way
> that becomes relavent (such as adding another break right after it, to
> get a blank line). Then stripping them out would be wrong. It would be
How often do we expect that will happen, in practice?
> a headache to figure out per each editting operation which breaks needed
> to be un-attributed.
Isn't the rule just this?
If the table cell would end up blank after an operation,
then put a moz br there, otherwise we don't need the attribute.
Maybe it's more complicated than that (I know Joe has struggled with
the rules code for doing things like this, and I haven't).
If that would complicate the rules code too much, I suppose we could
move the logic to the output system (I hate putting editor-specific
hacks in the output system, but sometimes we have no alternative):
On serialization, if you see a moz br and it's the only
child of its parent, don't output it.
> Leaving them in annoys some folks, but otherwise has no severe effects.
> The document renders the same. It doesn't bloat typical documents
Yes, but it breaks the rule we've tried very hard to follow in
other parts of the editor: Don't change the user's document any
more than necessary. There are lots of reasons users don't want
their source rewritten: CVS, use of other editors, how the document
looks when they edit the source in a plaintext editor.
> If you want to turn the heat up on someone, go to the layout group and
> tell them to generate frames for us in these circumstances. Then we
> won't need this hack.
Certainly that would be best. We shouldn't need the br tags there
at all, and it's a big performance hit putting them in when we read
the document in in the first place. I'd like to see this fixed.
But until it's fixed (if ever), wouldn't it be better to remove
the br's at save time?
Our selection problems are an implementation detail that we have to
work around. It's a bummer that we have to resort to hacks like
this at all, but we shouldn't inflict implementation details on
users if we can possibly avoid it.
...Akkana
