Ticket 357 (initial newline in tiddler content lost after save-and-reload)

[Saq Imtiaz]

Hey guys,

I have done some research on this and am presenting my findings:

1) Internet Explorer 6.0 is discarding all empty new lines at the end of a tiddler text. To duplicate, save a tiddler in Firefox with empty lines at the end. Viewing said tiddler in IE. The empty lines are gone.

2) The problem is that browsers do not consistently handle newlines before and after <pre> tags.

SGML (see [ISO8879], section 7.6.1) specifies that a line break immediately following a start tag must be ignored, as must a line break immediately before an end tag. This applies to all HTML elements without exception.

http://www.w3.org/TR/html401/appendix/notes.html#notes-line-breaks

It turns out, that IE 6 respects the newline before a pre tag, but Firefox does not.
Therefore, if we add a new line before the tiddler text in each pre, we get consistent management of leading lines in the tiddler text.

Currently the text is saved as <pre> text here</pre>.
It should be saved, according to the above recommendation, as
<pre>
text here
</pre>

This requires the following change in externalizeTiddler:
usePre ? "\n<pre>\n" + tiddler.text.htmlEncode() + "</pre>\n" : tiddler.text.escapeLineBreaks().htmlEncode()
The extra line break is in red.
This solves the problem of leading new lines.

3) However, the problem with trailing new lines is different. If we add another line break before the end of the pre tag, Firefox will add an extra line each time. Conversely, IE seems determined to ignore all trailing new lines. It looks as if we might need to do some browser detection.... I am hoping someone has a cleaner solution.

I hope I have not jumped to any incorrect conclusions in all of this. I would like to hear any thoughts on these findings.
Cheers,
Saq


--
TiddlyThemes.com ( http://tiddlythemes.com ) : a gallery of TiddlyWiki themes.
TiddlySnip ( http://tiddlysnip.com ) : a firefox extension that turns TiddlyWiki into a scrapbook!
LewcidTW ( http://tw.lewcid.org ) : a repository of extensions for TiddlyWiki

[Jeremy Ruston]

That's terrific, Saq, thank you, and seems entirely plausible.

Do you want to have a go at a patch for the third part? Rather than
doing browser detection per se, I wondered if we could have a
'sniffer' function that reads back the contents of a fixed <PRE> tag
and checks for the presence or absence of the critical new lines.

Cheers

Jeremy

--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com

[Eric Shulman]

> I have done some research on this and am presenting my findings:

...
excellent research! well done!

> 3) However, the problem with trailing new lines is different. If we add
> another line break before the end of the pre tag, Firefox will add an extra
> line each time. Conversely, IE seems determined to ignore all trailing new
> lines. It looks as if we might need to do some browser detection.... I am
> hoping someone has a cleaner solution.

consider:

In TW2.1.x and earlier (i.e, before using <pre>...</pre> formatting to
store tiddlers), ALL newlines were encoded as "\n". But, that made it
harder to read and search the document source in a text editor, and
impossible to use with external tools that work with line-based
comparisons such as diff/merge, external JS debuggers, "lint"
checkers, etc.

But the current problem isn't with ALL newlines... but rather just
with the very FIRST leading newline and very LAST trailing newline in
the tiddler, when they are present at all...

One way to avoid the browser differences in handling these two
problematic characters would be to actually encode ONLY those newlines
(using "<pre>\n" and "\n</pre>"), but leave all the other newlines as
is (unencoded) for all the reasons cited above. Of course, the two
encoded newlines (when present) would have to be decoded when the
tiddler is loaded into the store by the internalize() function, but
that should be a relatively simple and isolated change to make.

-e

[Saq Imtiaz]

On 6/22/07, Eric Shulman <elsd...@gmail.com> wrote:

But the current problem isn't with ALL newlines... but rather just
with the very FIRST leading newline and very LAST trailing newline in
the tiddler, when they are present at all...

Eric I would like to clarify the situation with trailing new lines for you:
1) IE6 drops all trailing new lines. Create a tiddler with 6 trailing new lines in FF. View it in IE. There will be no trailing new lines
2)Firefox does preserve trailing new lines
3) Adding an extra \n after the opening <pre> tag results in consistent handling of leading new lines across browsers.

That said, your suggestion to escape and unescape and leading and trailing new lines might still prove feasible. I am headed out soon... I'll give this some more thought tomorrow.

Once we get an elegant solution in place, I will submit a patch.

Cheers,
Saq

[Eric Shulman]

> Eric I would like to clarify the situation with trailing new lines for you:
> 1) IE6 drops all trailing new lines. Create a tiddler with 6 trailing new
> lines in FF. View it in IE. There will be no trailing new lines
> 2)Firefox does preserve trailing new lines
> 3) Adding an extra \n after the opening <pre> tag results in consistent
> handling of leading new lines across browsers.

OK. For *leading* newlines, all we have to do is add one extra
newline, just after the opening <pre> tag, so that the browser can
happily eat it.

However, as you've noted, IE6 drops multiple trailing newlines
immediately preceding the </pre> tag. To prevent this, all IE6 needs
is one non-newline character at the very end of the content, just
before the </pre> tag.

For example, if the tiddler ends with:
newline newline newline </pre>
we could encode just the last newline, resulting in:
newline newline backslash n </pre>
which would then no longer have *any* trailing newlines, completely
avoiding the need for a browser "sniff" test, since neither browser
will touch the newlines that are embedded *within* the content. All
that remains is to decode the trailing "backslash n" back into a real
newline when the tiddler is loaded into the store.

-e

[Saq Imtiaz]

On 6/23/07, Eric Shulman <elsd...@gmail.com> wrote:

OK.  For *leading* newlines, all we have to do is add one extra
newline, just after the opening <pre> tag, so that the browser can
happily eat it.

However, as you've noted, IE6 drops multiple trailing newlines
immediately preceding the </pre> tag.  To prevent this, all IE6 needs
is one non-newline character at the very end of the content, just
before the </pre> tag.

For example, if the tiddler ends with:
   newline newline newline </pre>
we could encode just the last newline, resulting in:
   newline newline backslash n </pre>
which would then no longer have *any* trailing newlines, completely
avoiding the need for a browser "sniff" test, since neither browser
will touch the newlines that are embedded *within* the content.  All
that remains is to decode the trailing "backslash n" back into a real
newline when the tiddler is loaded into the store.

I like it. This might seem a bit heavy handed.... what if we add a "\n" to the beginning and end of all tiddlers. Regardless of whether they have trailing and leading new lines, or not. This way, we do not need to detect for the presence of the new lines and we avoid possible quirks on other browsers (Opera?). It is heavy handed, but it should be more robust. When loading the tiddlers, it would be, as simple as removing the first two characters and the last two.

<pre>\n text \n</pre>

What do you think?
Cheers,
Saq
 

-e

[Saq Imtiaz]

I have submitted an initial patch:
http://www.tiddlywiki.org/attachment/ticket/357/Ticket357.patch

The patch has been tested in FF2 and IE6 and solves this problem. The approach is to escape the first and last line break in the tiddler text, if present, when saving. Similarly, when loading the tiddler text, the same line breaks are unescaped if present. This seems to be the most robust solution as it is backwards compatible, and gets around the different browser handling of leading and trailing new lines. (should be future compatible, if a browser quirk changes).

Testing on IE7 and Safari is welcomed.

Also find attached a copy of TW with the patch, for testing purposes.
The easiest way to test is to load the TW, edit the Test tiddler, save and reload. Count the number of new lines and see if it has changed.

Cheers,
Saq

[Eric Shulman]

> Testing on IE7 and Safari is welcomed.

IE7 tested.... patch works... no apparent problems.

-e

[Bob McElrath]

Could one use a &nbsp; or &#13; or something, rather than re-introducing
the \n escaping?

I like having the tiddler text in an un-encoded, un-messed with format
for reading with external tools, text mode browsers, etc. I thought
that was part of the <pre> idea in the first place.

--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]

"All wars come to an end, at least temporarily. But the authority acquired by
the state hangs on; political power never abdicates." -- Frank Chodorov

[Saq Imtiaz]

On 6/25/07, Bob McElrath <bob.mc...@gmail.com> wrote:

Could one use a &nbsp; or &#13; or something, rather than re-introducing
the \n escaping?

We could always add some extra arbitrary  character.  The idea with the \n was to  use the equivalent of the new lines.  The only new lines encoded, are the first and last empty new lines, if they exist. That should not hamper readability all that much.

That said  am not against using some other arbitrary character. We just need to reach some concensus. It would be nice, to get this patched soon. In some situations this could be a rather severe bug.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGf/rNjwioWRGe9K0RAr1PAKCOf1BFwqXWHyJYTkaSSO+H+mw3jQCeLS1N
HwOJ2iHaWracjD3K5+xIDzo=
=uam4
-----END PGP SIGNATURE-----

[Bob McElrath]

Saq Imtiaz [lew...@gmail.com] wrote:
> On 6/25/07, Bob McElrath <bob.mc...@gmail.com> wrote:
> >
> > Could one use a &nbsp; or &#13; or something, rather than re-introducing
> > the \n escaping?
>
> We could always add some extra arbitrary character. The idea with the \n
> was to use the equivalent of the new lines. The only new lines encoded,
> are the first and last empty new lines, if they exist. That should not
> hamper readability all that much.
>
> That said am not against using some other arbitrary character. We just need
> to reach some concensus. It would be nice, to get this patched soon. In some
> situations this could be a rather severe bug.

Does Internet Exploder preserve &#13; at the end of a tiddler? (maybe
it's &#0d;) or any combination of characters encoded in such a way?

\n requires javascript TW magic to understand. If tools/browsers follow
standards, the numeric entities &#0d; do not...

[Martin Budden]

I agree with Bob here, we should try and avoid the \n. In terms of the initial newline I prefer Eric's suggestion, namely that we add a real newline at the beginning of the tiddler for the browser to eat. In terms of the final newline there is an argument that we do not need to do anything - stripping trailing newlines off the end of a tiddler seems totally harmless, indeed you could put forward an argument that we should strip all trailing whitespace from a tiddler on saving. On the other hand, I can see, that from a purist point of view, it might be desirable to keep trailing newlines on a tiddler. What's the general viewpoint?

Martin

[Saq Imtiaz]

On 6/25/07, Martin Budden <mjbu...@gmail.com> wrote:

I agree with Bob here, we should try and avoid the \n. In terms of the initial newline I prefer Eric's suggestion, namely that we add a real newline at the beginning of the tiddler for the browser to eat. In terms of the final newline there is an argument that we do not need to do anything - stripping trailing newlines off the end of a tiddler seems totally harmless, indeed you could put forward an argument that we should strip all trailing whitespace from a tiddler on saving. On the other hand, I can see, that from a purist point of view, it might be desirable to keep trailing newlines on a tiddler. What's the general viewpoint?

It was my suggestion to add a real new line to the beginning of each tiddler. I abandoned it for two reasons:
1) we needed to encode the trailing new lines anyway, so why not do both
2) while Firefox and IE 6 both eat the first new line, there is no uniform implementation of this in browsers. What of Opera, Safari etc?

As for the trailing new lines, I would be strongly against stripping the new lines!! A lot of users will add new lines to the end of a tiddler just to space it out.......separate it from the next tiddler. Not to mention preserving backwards compatibility. Most importantly... firefox preserves all trailing new lines, IE preserves none. So we would have no consistency.

If we wish to go about this differently and avoid using \n then so be it. However, we should make sure that all whitespace is consistently saved.
Cheers,
Saq

[Eric Shulman]

> stripping trailing newlines off the end of a tiddler seems totally harmless,
> indeed you could put forward an argument that we should strip all trailing
> whitespace from a tiddler on saving. On the other hand, I can see, that from

While whitespace in HTML is generally ignored (or reduced to a single
space), newlines in wiki syntax are real content!!! Even trailing
ones...

Also, even if it's not the CSS-purist way, newlines are commonly used
to insert a little extra space between specific pieces of content.
"But," you might say, "those newlines wouldn't be affected because
they are *between* content, not at the end of the tiddler" Ah ah, I
say!... If you use the <<tiddler>> macro to include content from
several other tiddlers, those tiddlers could contain leading and/or
trailing whitespace which would appear in between content in the final
rendered display.

Don't eat the newlines!!!!

-e

[Eric Shulman]

> If we wish to go about this differently and avoid using \n then so be it.
> However, we should make sure that all whitespace is consistently saved.

hmmm.... since these 'sentinel' characters are arbitrary, it would
save some space to use a single character, such as:

<pre>.content.</pre>

While this isn't a great deal of savings (2 bytes per tiddler), why
not do it?

-e

[Saq Imtiaz]

I see nothing wrong with that.  We jut need to reach a concensus. It really is unfortunate that there is no work around that does not involve adding extra characters. I would also be interested to see what JR had to say about this.

-e

[Saq Imtiaz]

On 6/25/07, Eric Shulman <elsd...@gmail.com> wrote:

> Testing on IE7 and Safari is welcomed.

IE7 tested.... patch works... no apparent problems.

Great! As long as we use  an arbitrary character, the same/similar approach will apply. Thank you Eric!

-e

[Daniel Baird]

Perhaps it's too late to sway any opinions, but I reckon it should be
TW's default behaviour to strip tiddlers of their leading and trailing
whitespace. We should encourage people to style their headings etc
properly if they want spacing.

If you really, really want blank lines, you can start your tiddler
with an empty comment or something like that.

;Daniel

--
Daniel Baird
http://tiddlyspot.com (free, effortless TiddlyWiki hosting)
http://danielbaird.com (TiddlyW;nks! :: Whiteboard Koala :: Blog ::
Things That Suck)

[Bob McElrath]

Daniel Baird [danie...@gmail.com] wrote:
>
> Perhaps it's too late to sway any opinions, but I reckon it should be
> TW's default behaviour to strip tiddlers of their leading and trailing
> whitespace. We should encourage people to style their headings etc
> properly if they want spacing.
>
> If you really, really want blank lines, you can start your tiddler
> with an empty comment or something like that.

I agree with this opinion.

In the example given previously of including tiddlers in other tiddlers,
one can insert &nbsp; to achieve the desired effect. (or use CSS)

[Jeremy Ruston]

> Does Internet Exploder preserve &#13; at the end of a tiddler? (maybe
> it's &#0d;) or any combination of characters encoded in such a way?
>
> \n requires javascript TW magic to understand. If tools/browsers follow
> standards, the numeric entities &#0d; do not...

Did anyone manage to test this? I'm with Bob and Martin as far as
needing to try to keep life straightforward for external tools.

In terms of the suggestions about the desirability of stripping
whitespace, I can see the argument, and think that it's a reasonable
option to have via a plugin or option, but not something that we
should have imposed as a unintended side-effect of our storage format.

Having said all of that, I actually wonder whether this isn't a bug
that we shouldn't just live with - if I understand correctly that it
only affects IE6, and not IE7, that is. Conventional wisdom being that
people who care have upgraded by now. I was surprised at these figures
for browser share in May 2007:

IE7 19.2%, IE6 38.1%, IE5 1.5%, Firefox 33.7%, Mozilla 1.3%, Safari
1.5%, Opera 1.6%

http://www.w3schools.com/browsers/browsers_stats.asp

This is a great discussion, and thanks for all the hard work
researching and patching,

Cheers

Jeremy

>
> --
> Cheers,
> Bob McElrath [Univ. of California at Davis, Department of Physics]
>
> "All wars come to an end, at least temporarily. But the authority acquired by
> the state hangs on; political power never abdicates." -- Frank Chodorov
>

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>

> iD8DBQFGgB1sjwioWRGe9K0RAiRRAJ4zE5jupqwQCqYbr8hQNuaLH4aRmwCgkcRe
> fb/wydaPBdIfuZiVx9HedGY=
> =ComN
> -----END PGP SIGNATURE-----

[FND]

>> it should be TW's default behaviour to strip tiddlers of their
>> leading and trailing whitespace. We should encourage people to style
>> their headings etc properly if they want spacing.
>

> I agree with this opinion.

What they said - that is, I'm with the "encourage separation of content
and layout" crowd.

Also, I sometimes accidentally insert newlines at the end (e.g. when
refactoring with copy & paste), and I'd really welcome if those were
stripped automatically.
(By the way, this also affects whitespaces at the end of a line, which
should be safe to strip in any case.)

Either way, kudos to all the people who've put thought into this and
done research on browser behavior etc.

-- F.

[Eric Shulman]

> that we shouldn't just live with - if I understand correctly that it
> only affects IE6, and not IE7, that is. Conventional wisdom being that

The problem with *leading* newlines exists on both IE *and* FireFox as
well. It is only IE that has a problem with the *trailing* newlines.

BUT....

We really should try to implement a browser-independent fix, rather
than relying on any given browser to just handle it correctly and
assume that cross-browsers differences won't matter. If we don't
eliminate these variations in newline handling between browsers, it
could create headaches for anyone writing documents for a mixed
browser audience. A document created on one browser might be viewed
from a different browser If the TW author isn't diligent enough (or
maybe they don't have the other browser to test with), differences in
newline handling could make their carefully crafted content look
horribly wrong.

One big advantage of the 'sentinel characters' approach is that it
will work the same for all browsers, regardless of how well they
followed the official HTML spec regarding treatment of leading and/or
trailing newlines.

As far as concerns about readability in external tools: keep in mind
that the sentinels can be ANY characters other than newlines... even
*other* whitespace, such as spaces. In fact, I think that using
spaces would be ideal, in that it wouldn't affect the display of the
source code and shouldn't need to be translated for use in external
debuggers and other tools, since nearly all of those tools tend to
ignore whitespace already.

So... how about this sequence for storing tiddler content:
<pre>-space-content-space-</pre>

In summary, it has these advantages:
1) works for all browsers, regardless of variations in newline
handling
2) doesn't create any *visible* differences when tiddler source is
viewed in external text editor
3) doesn't require translation or removal for use of tiddler content
in debuggers, etc.
4) adds only two bytes to each tiddler

thoughts?
-e

[Saq Imtiaz]

The biggest reason why we should not enforce stripping of new lines is user friendliness. While in an idea world, everyone would be willing and able to learn css to achieve the same effect as a trailing new line... that is not the case. Such a move will make the learning curve for using TW unnecessarily steep. It might also alienate existing TW users.

My mum uses TiddlyWiki to save her recipes... digitizing them for the next generation if you will. How do I explain to her, that she needs to learn css, just to leave an empty line at the end of a recipe? Oh I could make it easier for her, but that is besides the point. It should not be necessary. The intended move is towards easier editing (WISIWYG), not the opposite. So as semantically incorrect such use of new lines should be, the practical benefits should win.

&#13; and &#10; do not work in IE.

I will test a few other characters including a tab and a space and report back.
Cheers,
Saq

[Saq Imtiaz]

Using a space as a sentinel character works!  So instead of:

<pre> newline text newline <pre>

We know save as:

<pre>space newline text newline space>

This would be almost transparent to external editors.

Attached is an updated patch, and a file with the fix. Once again, testing in IE7 and Safari is requested (and Opera).
Cheers,
Saq

[Martin Budden]

I really don't like the initial sentinel character. Since all browsers work correctly for the leading newline, I think we should start tiddlers:

<pre>newline
text
...

I think that we've agreed that trailing whitespace should not be truncated, so I'm reasonably happy with using the space as a trailing sentinel. However I think there is a case for following this space with a newline so that the </pre> tag appears on a line on its own - this makes manually editing tiddlers easier. The newline between the space sentinel and the </pre> tag will either be removed by the browser or by the tiddlywiki loader if the browser has not removed it - thus preserving cross-browser functionality.

Martin

Welcome to TiddlyWiki created by Jeremy Ruston, Copyright © 2007 UnaMesa Association

This page requires JavaScript to function properly.

If you are using Microsoft Internet Explorer you may need to click on the yellow bar above and select 'Allow Blocked Content'. You must then click 'Yes' on the following security warning.

Background: #fff
Foreground: #000
PrimaryPale: #8cf
PrimaryLight: #18f
PrimaryMid: #04b
PrimaryDark: #014
SecondaryPale: #ffc
SecondaryLight: #fe8
SecondaryMid: #db4
SecondaryDark: #841

TertiaryPale: #eee
TertiaryLight: #ccc
TertiaryMid: #999
TertiaryDark: #666
Error: #f88

/*{{{*/
body {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}

a {color:[[ColorPalette::PrimaryMid]];}
a:hover {background-color:[[ColorPalette::PrimaryMid]]; color:[[ColorPalette::Background]];}

a img {border:0;}

h1,h2,h3,h4,h5,h6 {color:[[ColorPalette::SecondaryDark]]; background:transparent;}
h1 {border-bottom:2px solid [[ColorPalette::TertiaryLight]];}
h2,h3 {border-bottom:1px solid [[ColorPalette::TertiaryLight]];}


.button {color:[[ColorPalette::PrimaryDark]]; border:1px solid [[ColorPalette::Background]];}
.button:hover {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::SecondaryLight]]; border-color:[[ColorPalette::SecondaryMid]];}

.button:active {color:[[ColorPalette::Background]]; background:[[ColorPalette::SecondaryMid]]; border:1px solid [[ColorPalette::SecondaryDark]];}

.header {background:[[ColorPalette::PrimaryMid]];}
.headerShadow {color:[[ColorPalette::Foreground]];}

.headerShadow a {font-weight:normal; color:[[ColorPalette::Foreground]];}
.headerForeground {color:[[ColorPalette::Background]];}
.headerForeground a {font-weight:normal; color:[[ColorPalette::PrimaryPale]];}


.tabSelected{color:[[ColorPalette::PrimaryDark]];
	background:[[ColorPalette::TertiaryPale]];
	border-left:1px solid [[ColorPalette::TertiaryLight]];
	border-top:1px solid [[ColorPalette::TertiaryLight]];

	border-right:1px solid [[ColorPalette::TertiaryLight]];
}
.tabUnselected {color:[[ColorPalette::Background]]; background:[[ColorPalette::TertiaryMid]];}
.tabContents {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::TertiaryPale]]; border:1px solid [[ColorPalette::TertiaryLight]];}

.tabContents .button {border:0;}

#sidebar {}
#sidebarOptions input {border:1px solid [[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel {background:[[ColorPalette::PrimaryPale]];}
#sidebarOptions .sliderPanel a {border:none;color:[[ColorPalette::PrimaryMid]];}

#sidebarOptions .sliderPanel a:hover {color:[[ColorPalette::Background]]; background:[[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel a:active {color:[[ColorPalette::PrimaryMid]]; background:[[ColorPalette::Background]];}


.wizard {background:[[ColorPalette::PrimaryPale]]; border:1px solid [[ColorPalette::PrimaryMid]];}
.wizard h1 {color:[[ColorPalette::PrimaryDark]]; border:none;}
.wizard h2 {color:[[ColorPalette::Foreground]]; border:none;}

.wizardStep {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];
	border:1px solid [[ColorPalette::PrimaryMid]];}
.wizardStep.wizardStepDone {background::[[ColorPalette::TertiaryLight]];}

.wizardFooter {background:[[ColorPalette::PrimaryPale]];}
.wizardFooter .status {background:[[ColorPalette::PrimaryDark]]; color:[[ColorPalette::Background]];}
.wizard .button {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::SecondaryLight]]; border: 1px solid;

	border-color:[[ColorPalette::SecondaryPale]] [[ColorPalette::SecondaryDark]] [[ColorPalette::SecondaryDark]] [[ColorPalette::SecondaryPale]];}
.wizard .button:hover {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::Background]];}

.wizard .button:active {color:[[ColorPalette::Background]]; background:[[ColorPalette::Foreground]]; border: 1px solid;
	border-color:[[ColorPalette::PrimaryDark]] [[ColorPalette::PrimaryPale]] [[ColorPalette::PrimaryPale]] [[ColorPalette::PrimaryDark]];}


#messageArea {border:1px solid [[ColorPalette::SecondaryMid]]; background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]];}
#messageArea .button {color:[[ColorPalette::PrimaryMid]]; background:[[ColorPalette::SecondaryPale]]; border:none;}


.popupTiddler {background:[[ColorPalette::TertiaryPale]]; border:2px solid [[ColorPalette::TertiaryMid]];}

.popup {background:[[ColorPalette::TertiaryPale]]; color:[[ColorPalette::TertiaryDark]]; border-left:1px solid [[ColorPalette::TertiaryMid]]; border-top:1px solid [[ColorPalette::TertiaryMid]]; border-right:2px solid [[ColorPalette::TertiaryDark]]; border-bottom:2px solid [[ColorPalette::TertiaryDark]];}

.popup hr {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::PrimaryDark]]; border-bottom:1px;}
.popup li.disabled {color:[[ColorPalette::TertiaryMid]];}
.popup li a, .popup li a:visited {color:[[ColorPalette::Foreground]]; border: none;}

.popup li a:hover {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; border: none;}
.popup li a:active {background:[[ColorPalette::SecondaryPale]]; color:[[ColorPalette::Foreground]]; border: none;}

.popupHighlight {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
.listBreak div {border-bottom:1px solid [[ColorPalette::TertiaryDark]];}

.tiddler .defaultCommand {font-weight:bold;}


.shadow .title {color:[[ColorPalette::TertiaryDark]];}

.title {color:[[ColorPalette::SecondaryDark]];}
.subtitle {color:[[ColorPalette::TertiaryDark]];}

.toolbar {color:[[ColorPalette::PrimaryMid]];}

.toolbar a {color:[[ColorPalette::TertiaryLight]];}
.selected .toolbar a {color:[[ColorPalette::TertiaryMid]];}
.selected .toolbar a:hover {color:[[ColorPalette::Foreground]];}

.tagging, .tagged {border:1px solid [[ColorPalette::TertiaryPale]]; background-color:[[ColorPalette::TertiaryPale]];}

.selected .tagging, .selected .tagged {background-color:[[ColorPalette::TertiaryLight]]; border:1px solid [[ColorPalette::TertiaryMid]];}
.tagging .listTitle, .tagged .listTitle {color:[[ColorPalette::PrimaryDark]];}

.tagging .button, .tagged .button {border:none;}

.footer {color:[[ColorPalette::TertiaryLight]];}
.selected .footer {color:[[ColorPalette::TertiaryMid]];}

.sparkline {background:[[ColorPalette::PrimaryPale]]; border:0;}

.sparktick {background:[[ColorPalette::PrimaryDark]];}

.error, .errorButton {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::Error]];}
.warning {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::SecondaryPale]];}

.lowlight {background:[[ColorPalette::TertiaryLight]];}

.zoomer {background:none; color:[[ColorPalette::TertiaryMid]]; border:3px solid [[ColorPalette::TertiaryMid]];}

.imageLink, #displayArea .imageLink {background:transparent;}


.annotation {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; border:2px solid [[ColorPalette::SecondaryMid]];}

.viewer .listTitle {list-style-type:none; margin-left:-2em;}

.viewer .button {border:1px solid [[ColorPalette::SecondaryMid]];}
.viewer blockquote {border-left:3px solid [[ColorPalette::TertiaryDark]];}

.viewer table, table.twtable {border:2px solid [[ColorPalette::TertiaryDark]];}

.viewer th, .viewer thead td, .twtable th, .twtable thead td {background:[[ColorPalette::SecondaryMid]]; border:1px solid [[ColorPalette::TertiaryDark]]; color:[[ColorPalette::Background]];}
.viewer td, .viewer tr, .twtable td, .twtable tr {border:1px solid [[ColorPalette::TertiaryDark]];}


.viewer pre {border:1px solid [[ColorPalette::SecondaryLight]]; background:[[ColorPalette::SecondaryPale]];}
.viewer code {color:[[ColorPalette::SecondaryDark]];}
.viewer hr {border:0; border-top:dashed 1px [[ColorPalette::TertiaryDark]]; color:[[ColorPalette::TertiaryDark]];}


.highlight, .marked {background:[[ColorPalette::SecondaryLight]];}

.editor input {border:1px solid [[ColorPalette::PrimaryMid]];}
.editor textarea {border:1px solid [[ColorPalette::PrimaryMid]]; width:100%;}

.editorFooter {color:[[ColorPalette::TertiaryMid]];}

#backstageArea {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::TertiaryMid]];}
#backstageArea a {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::Background]]; border:none;}

#backstageArea a:hover {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; }
#backstageArea a.backstageSelTab {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}

#backstageButton a {background:none; color:[[ColorPalette::Background]]; border:none;}
#backstageButton a:hover {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::Background]]; border:none;}
#backstagePanel {background:[[ColorPalette::Background]]; border-color: [[ColorPalette::Background]] [[ColorPalette::TertiaryDark]] [[ColorPalette::TertiaryDark]] [[ColorPalette::TertiaryDark]];}

.backstagePanelFooter .button {border:none; color:[[ColorPalette::Background]];}
.backstagePanelFooter .button:hover {color:[[ColorPalette::Foreground]];}
#backstageCloak {background:[[ColorPalette::Foreground]]; opacity:
0.6; filter:'alpha(opacity:60)';}
/*}}}*/

/*{{{*/
* html .tiddler {height:1%;}

body {font-size:.75em; font-family:arial,helvetica; margin:0; padding:0;}

h1,h2,h3,h4,h5,h6 {font-weight:bold; text-decoration:none;}
h1,h2,h3 {padding-bottom:1px; margin-top:
1.2em;margin-bottom:0.3em;}
h4,h5,h6 {margin-top:1em;}
h1 {font-size:1.35em;}
h2 {font-size:1.25em;}
h3 {font-size:1.1em;}
h4 {font-size:1em;}
h5 {font-size:.9em;}

hr {height:1px;}

a {text-decoration:none;}


dt {font-weight:bold;}

ol {list-style-type:decimal;}
ol ol {list-style-type:lower-alpha;}
ol ol ol {list-style-type:lower-roman;}
ol ol ol ol {list-style-type:decimal;}
ol ol ol ol ol {list-style-type:lower-alpha;}

ol ol ol ol ol ol {list-style-type:lower-roman;}
ol ol ol ol ol ol ol {list-style-type:decimal;}

.txtOptionInput {width:11em;}

#contentWrapper .chkOptionInput {border:0;}

.externalLink {text-decoration:underline;}


.indent {margin-left:3em;}
.outdent {margin-left:3em; text-indent:-3em;}
code.escaped {white-space:nowrap;}

.tiddlyLinkExisting {font-weight:bold;}
.tiddlyLinkNonExisting {font-style:italic;}


/* the 'a' is required for IE, otherwise it renders the whole tiddler in bold */
a.tiddlyLinkNonExisting.shadow {font-weight:bold;}

#mainMenu .tiddlyLinkExisting,
	#mainMenu .tiddlyLinkNonExisting,

	#sidebarTabs .tiddlyLinkNonExisting {font-weight:normal; font-style:normal;}
#sidebarTabs .tiddlyLinkExisting {font-weight:bold; font-style:normal;}

.header {position:relative;}
.header a:hover {background:transparent;}

.headerShadow {position:relative; padding:4.5em 0em 1em 1em; left:-1px; top:-1px;}
.headerForeground {position:absolute; padding:4.5em 0em 1em 1em; left:0px; top:0px;}

.siteTitle {font-size:3em;}
.siteSubtitle {font-size:
1.2em;}

#mainMenu {position:absolute; left:0; width:10em; text-align:right; line-height:1.6em; padding:1.5em 0.5em 0.5em 0.5em; font-size:1.1em;}

#sidebar {position:absolute; right:3px; width:16em; font-size:.9em;}

#sidebarOptions {padding-top:0.3em;}
#sidebarOptions a {margin:0em 0.2em; padding:0.2em 0.3em; display:block;}
#sidebarOptions input {margin:0.4em 0.5em;}
#sidebarOptions .sliderPanel {margin-left:1em; padding:
0.5em; font-size:.85em;}
#sidebarOptions .sliderPanel a {font-weight:bold; display:inline; padding:0;}
#sidebarOptions .sliderPanel input {margin:0 0 .3em 0;}
#sidebarTabs .tabContents {width:15em; overflow:hidden;}


.wizard {padding:0.1em 1em 0em 2em;}
.wizard h1 {font-size:2em; font-weight:bold; background:none; padding:0em 0em 0em 0em; margin:0.4em 0em 0.2em 0em;}
.wizard h2 {font-size:1.2em; font-weight:bold; background:none; padding:0em 0em 0em 0em; margin:
0.4em 0em 0.2em 0em;}
.wizardStep {padding:1em 1em 1em 1em;}
.wizard .button {margin:0.5em 0em 0em 0em; font-size:1.2em;}
.wizardFooter {padding:0.8em 0.4em 0.8em 0em;}
.wizardFooter .status {padding:0em 0.4em
 0em 0.4em; margin-left:1em;}
.wizard .button {padding:0.1em 0.2em 0.1em 0.2em;}

#messageArea {position:fixed; top:2em; right:0em; margin:0.5em; padding:0.5em; z-index:2000; _position:absolute;}
.messageToolbar {display:block; text-align:right; padding:
0.2em 0.2em 0.2em 0.2em;}
#messageArea a {text-decoration:underline;}

.tiddlerPopupButton {padding:0.2em 0.2em 0.2em 0.2em;}
.popupTiddler {position: absolute; z-index:300; padding:1em 1em 1em 1em; margin:0;}


.popup {position:absolute; z-index:300; font-size:.9em; padding:0; list-style:none; margin:0;}
.popup .popupMessage {padding:0.4em;}
.popup hr {display:block; height:1px; width:auto; padding:0; margin:0.2em 0em;}

.popup li.disabled {padding:0.4em;}
.popup li a {display:block; padding:0.4em; font-weight:normal; cursor:pointer;}
.listBreak {font-size:1px; line-height:1px;}
.listBreak div {margin:2px 0;}

.tabset {padding:1em 0em 0em 
0.5em;}
.tab {margin:0em 0em 0em 0.25em; padding:2px;}
.tabContents {padding:0.5em;}
.tabContents ul, .tabContents ol {margin:0; padding:0;}
.txtMainTab .tabContents li {list-style:none;}
.tabContents li.listLink
 { margin-left:.75em;}

#contentWrapper {display:block;}
#splashScreen {display:none;}

#displayArea {margin:1em 17em 0em 14em;}

.toolbar {text-align:right; font-size:.9em;}

.tiddler {padding:1em 1em 0em 1em;}


.missing .viewer,.missing .title {font-style:italic;}

.title {font-size:1.6em; font-weight:bold;}

.missing .subtitle {display:none;}
.subtitle {font-size:1.1em;}

.tiddler .button {padding:0.2em
 0.4em;}

.tagging {margin:0.5em 0.5em 0.5em 0; float:left; display:none;}
.isTag .tagging {display:block;}
.tagged {margin:0.5em; float:right;}
.tagging, .tagged {font-size:0.9em; padding:0.25em;}
.tagging ul, .tagged ul {list-style:none; margin:
0.25em; padding:0;}
.tagClear {clear:both;}

.footer {font-size:.9em;}
.footer li {display:inline;}

.annotation {padding:0.5em; margin:0.5em;}

* html .viewer pre {width:99%; padding:0 0 1em 0;}

.viewer {line-height:1.4em; padding-top:0.5em;}
.viewer .button {margin:0em 0.25em; padding:0em 0.25em;}
.viewer blockquote {line-height:1.5em; padding-left:0.8em;margin-left:2.5em;}
.viewer ul, .viewer ol {margin-left:
0.5em; padding-left:1.5em;}

.viewer table, table.twtable {border-collapse:collapse; margin:0.8em 1.0em;}
.viewer th, .viewer td, .viewer tr,.viewer caption,.twtable th, .twtable td, .twtable tr,.twtable caption {padding:3px;}

table.listView {font-size:0.85em; margin:0.8em 1.0em;}
table.listView th, table.listView td, table.listView tr {padding:0px 3px 0px 3px;}

.viewer pre {padding:0.5em; margin-left:0.5em; font-size:1.2em; line-height:
1.4em; overflow:auto;}
.viewer code {font-size:1.2em; line-height:1.4em;}

.editor {font-size:1.1em;}
.editor input, .editor textarea {display:block; width:100%; font:inherit;}
.editorFooter {padding:0.25em
 0em; font-size:.9em;}
.editorFooter .button {padding-top:0px; padding-bottom:0px;}

.fieldsetFix {border:0; padding:0; margin:1px 0px 1px 0px;}

.sparkline {line-height:1em;}
.sparktick {outline:0;}


.zoomer {font-size:1.1em; position:absolute; overflow:hidden;}
.zoomer div {padding:1em;}

* html #backstage {width:99%;}
* html #backstageArea {width:99%;}
#backstageArea {display:none; position:relative; overflow: hidden; z-index:150; padding:
0.3em 0.5em 0.3em 0.5em;}
#backstageToolbar {position:relative;}
#backstageArea a {font-weight:bold; margin-left:0.5em; padding:0.3em 0.5em 0.3em 0.5em;}
#backstageButton {display:none; position:absolute; z-index:175; top:0em; right:0em;}

#backstageButton a {padding:0.1em 0.4em 0.1em 0.4em; margin:0.1em 0.1em 0.1em 0.1em;}
#backstage {position:relative; width:100%; z-index:50;}
#backstagePanel {display:none; z-index:100; position:absolute; margin:0em 3em 0em 3em; padding:1em 1em 1em 1em;}

.backstagePanelFooter {padding-top:0.2em; float:right;}
.backstagePanelFooter a {padding:0.2em 0.4em 0.2em 0.4em;}
#backstageCloak {display:none; z-index:20; position:absolute; width:100%; height:100px;}


.whenBackstage {display:none;}
.backstageVisible .whenBackstage {display:block;}
/*}}}*/

/***
StyleSheet for use when a translation requires any css style changes.
This StyleSheet can be used directly by languages such as Chinese, Japanese and Korean which use a logographic writing system and need larger font sizes.

***/

/*{{{*/
body {font-size:0.8em;}

#sidebarOptions {font-size:1.05em;}
#sidebarOptions a {font-style:normal;}
#sidebarOptions .sliderPanel {font-size:0.95em;}

.subtitle {font-size:0.8em
;}

.viewer table.listView {font-size:0.95em;}

.htmlarea .toolbarHA table {border:1px solid ButtonFace; margin:0em 0em;}
/*}}}*/

/*{{{*/
@media print {
#mainMenu, #sidebar, #messageArea, .toolbar, #backstageButton {display: none ! important;}
#displayArea {margin: 1em 1em 0em 1em;}
/* Fixes a feature in Firefox 
1.5.0.2 where print preview displays the noscript content */
noscript {display:none;}
}
/*}}}*/

<!--{{{-->
<div class='header' macro='gradient vert [[ColorPalette::PrimaryLight]] [[ColorPalette::PrimaryMid]]'>
<div class='headerShadow'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;

<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
<div class='headerForeground'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;

<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
</div>
<div id='mainMenu' refresh='content' tiddler='MainMenu'></div>

<div id='sidebar'>
<div id='sidebarOptions' refresh='content' tiddler='SideBarOptions'></div>
<div id='sidebarTabs' refresh='content' force='true' tiddler='SideBarTabs'></div>

</div>
<div id='displayArea'>
<div id='messageArea'></div>
<div id='tiddlerDisplay'></div>
</div>
<!--}}}-->

<!--{{{-->
<div class='toolbar' macro='toolbar closeTiddler closeOthers +editTiddler > fields syncing permalink references jump'></div>
<div class='title' macro='view title'></div>

<div class='subtitle'><span macro='view modifier link'></span>, <span macro='view modified date'></span> (<span macro='message views.wikified.createdPrompt'></span> <span macro='view created date'></span>)</div>

<div class='tagging' macro='tagging'></div>
<div class='tagged' macro='tags'></div>
<div class='viewer' macro='view text wikified'></div>

<div class='tagClear'></div>
<!--}}}-->

<!--{{{-->
<div class='toolbar' macro='toolbar +saveTiddler -cancelTiddler deleteTiddler'></div>
<div class='title' macro='view title'></div>
<div class='editor' macro='edit title'></div>

<div macro='annotations'></div>
<div class='editor' macro='edit text'></div>
<div class='editor' macro='edit tags'></div><div class='editorFooter'><span macro='message 
views.editor.tagPrompt'></span><span macro='tagChooser'></span></div>
<!--}}}-->

To get started with this blank TiddlyWiki, you'll need to modify the following tiddlers:
* SiteTitle & SiteSubtitle: The title and subtitle of the site, as shown above (after saving, they will also appear in the browser title bar)

* MainMenu: The menu (usually on the left)
* DefaultTiddlers: Contains the names of the tiddlers that you want to appear when the TiddlyWiki is opened
You'll also need to enter your username for signing your edits: <<option txtUserName>>

These InterfaceOptions for customising TiddlyWiki are saved in your browser

Your username for signing your edits. Write it as a WikiWord (eg JoeBloggs)

<<option txtUserName>>
<<option chkSaveBackups>> SaveBackups

<<option chkAutoSave>> AutoSave
<<option chkRegExpSearch>> RegExpSearch
<<option chkCaseSensitiveSearch>> CaseSensitiveSearch
<<option chkAnimate>> EnableAnimations


----
Also see AdvancedOptions

 


Saq


 

[BJ]

On Jun 25, 7:38 pm, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
> Having said all of that, I actually wonder whether this isn't a bug
> that we shouldn't just live with - if I understand correctly that it
> only affects IE6, and not IE7, that is. Conventional wisdom being that
> people who care have upgraded by now. I was surprised at these figures
> for browser share in May 2007:
>
> IE7 19.2%, IE6 38.1%, IE5 1.5%, Firefox 33.7%, Mozilla 1.3%, Safari
> 1.5%, Opera 1.6%

Those figures are skewed because of the large number of corporate
users (like my employer, with over 5K users of IE) that haven't
upgraded to IE7 due to incompatibility issues with other software
(COTS/MOTS, home-grown, or both). I have IE7 at home (although
Firefox is in the very near future), but I'm stuck with IE6 at work...
they catch you putting on Firefox or anything else and it's 40 lashes
in the courtyard.

-- BJ

[Saq Imtiaz]

On 6/26/07, Martin Budden <mjbu...@gmail.com> wrote:

I really don't like the initial sentinel character. Since all browsers work correctly for the leading newline, I think we should start tiddlers:

<pre>newline
text
...

I think that we've agreed that trailing whitespace should not be truncated, so I'm reasonably happy with using the space as a trailing sentinel. However I think there is a case for following this space with a newline so that the </pre> tag appears on a line on its own - this makes manually editing tiddlers easier. The newline between the space sentinel and the </pre> tag will either be removed by the browser or by the tiddlywiki loader if the browser has not removed it - thus preserving cross-browser functionality.

Do we have a consensus on this yet? Is everyone in agreement with Martin? I will update the patch once I know.
Cheers,
Saq

[Udo Borkowski]

Do we have a consensus on this yet? Is everyone in agreement with Martin? I will update the patch once I know.

Just one issue: I think the tiddlywiki loader must be able to detect if the storearea/shadowarea... is in "sentinal" format or in the "old" format. In the later case the loader should not delete a suffix that "looks like a sentinal" ( plus optional newline). To achieve this we probably need to "tag" the storeArea/shadowarea when writing the TW in the new "sentinal format store". E.g. we may introduce a "format" attribute:

<div id="storeArea" format="
2.2.5">

(BTW: If we are targeting XHTML compliance we may not need the attribute "format" but a standard attribute)


Udo

----------
Udo Borkowski
http://www.abego-software.de

[Saq Imtiaz]

On 7/7/07, Udo Borkowski <udo.bo...@googlemail.com> wrote:

Do we have a consensus on this yet? Is everyone in agreement with Martin? I will update the patch once I know.

Just one issue: I think the tiddlywiki loader must be able to detect if the storearea/shadowarea... is in "sentinal" format or in the "old" format. In the later case the loader should not delete a suffix that "looks like a sentinal" ( plus optional newline). To achieve this we probably need to "tag" the storeArea/shadowarea when writing the TW in the new "sentinal format store". E.g. we may introduce a "format" attribute:

<div id="storeArea" format="
2.2.5">

An interesting point Udo. However, is this really going to be that much of an issue? This will only affect  TW versions between  2.2.0 and 2.2.5. This problem is not that widespread to begin with.

It would be very easy to add, if we do want it though.
Any other comments or input anyone?
Jeremy, I am curious to hear if you have a 'final' take on this.
Cheers,
Saq

(BTW: If we are targeting XHTML compliance we may not need the attribute "format" but a standard attribute)


Udo

----------
Udo Borkowski
http://www.abego-software.de

On 7/7/07, Saq Imtiaz < lew...@gmail.com> wrote:

On 6/26/07, Martin Budden < mjbu...@gmail.com> wrote:

I really don't like the initial sentinel character. Since all browsers work correctly for the leading newline, I think we should start tiddlers:

<pre>newline
text
...

I think that we've agreed that trailing whitespace should not be truncated, so I'm reasonably happy with using the space as a trailing sentinel. However I think there is a case for following this space with a newline so that the </pre> tag appears on a line on its own - this makes manually editing tiddlers easier. The newline between the space sentinel and the </pre> tag will either be removed by the browser or by the tiddlywiki loader if the browser has not removed it - thus preserving cross-browser functionality.

Do we have a consensus on this yet? Is everyone in agreement with Martin? I will update the patch once I know.
Cheers,
Saq

[Udo Borkowski]

However, is this really going to be that much of an issue? This will only affect  TW versions between  2.2.0 and 2.2.5. This problem is not that widespread to begin with.

I personally haven't yet switched "real stuff" to 2.2, so I wouldn't need this extra check (if 2.2.5 will be released soon). I was more speaking in the role of the "100%-compatibility advocate" ;-)

[Jeremy Ruston]

Thinking about this one more, I'm concerned that all of the fixes
we've discussed will complicate the rules by which content is encoded
in TiddlyWiki. This makes life harder for people who write tools and
add-ons for TiddlyWiki, adding more friction for people who need to
learn about TiddlyWiki. Because it's basically caused by a browser
bug, I propose that we live with the problem, and advise anyone
affected by it to use a different browser if they can.

What do you reckon?

Cheers

Jeremy

[Eric Shulman]

On Aug 14, 6:11 am, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
> Thinking about this one more, I'm concerned that all of the fixes
> we've discussed will complicate the rules by which content is encoded
> in TiddlyWiki. This makes life harder for people who write tools and
> add-ons for TiddlyWiki, adding more friction for people who need to
> learn about TiddlyWiki. Because it's basically caused by a browser
> bug, I propose that we live with the problem, and advise anyone
> affected by it to use a different browser if they can.
>
> What do you reckon?

while I'd love to have a solution that just works for all cases and
users, there IS a simple workaround that users can apply if they get
bitten by this bug (which should only occur if tiddler content begins
with a newline): simply hand-insert a leading space preceding the
newline in the content of the affected tiddler(s)

Of course, if we leave this problem in place, then we MUST make sure
to clearly document the problem AND the work-around...

-e

[Udo Borkowski]

Thinking about this one more, I'm concerned that all of the fixes
we've discussed will complicate the rules by which content is encoded
in TiddlyWiki.

Is it really that complicate? Maybe I missed something but I think the rule is just:

The text between the <pre ...> and </pre> tags is defined as:

"\n"+text.htmlEncode()+" \n"

This makes life harder for people who write tools and
add-ons for TiddlyWiki, adding more friction for people who need to
learn about TiddlyWiki.

I doubt this has really a big impact. Things like our "htmlEncode/htmlDecode" code are probably harder to grasp than this constant prefix/suffix sequence.

Because it's basically caused by a browser
bug, I propose that we live with the problem, and advise anyone
affected by it to use a different browser if they can.

I recall that we earlier said "switch your browser" is not good answer to a problem if it could be resolved with reasonable effort inside the TW core. That's why we already have a lot of "workaround" code in TW.

Also notice this issue was not introduced by a new browser but a change in our storage format. Before we switched to the new "<pre>" format this newline issue was none because all whitespaces were escaped. In the old TWs using that format it was OK to have leading newlines etc. so I think we need fix this issue in the code for compatibility reasons. Otherwise a person upgrading to 2.2(.5) may lose data. Even if this is just one newline it may already be too much (e.g. when the Tiddler texts have a static format (e.g. line 1 contains the "academic degree" in a contact tiddler).

BTW: "simply hand-insert a leading space preceding the newline in the content of the affected tiddler(s)" as suggested by Eric does not really solve the issue since it is no longer possible to have an empty starting line in a tiddler (it will always contain at least one space). Also you may present this information to everybody upgrading so the person can (and must) decide if his TiddlyWiki is affected, making the upgrade process less userfriendly.

Also consider this "asymmetry": when using 'store.setValue("T1","text",s)' the string s may not start with a newline, but when using 'store.setValue("T1","text2",s)' initial newlines are fine.

So I vote for fixing this issue.

Udo

----------
Udo Borkowski
http://www.abego-software.de

[Martin Budden]

Udo,

I don't think we have consensus on this. In particular:

1) The "separate content and layout" crowd (FND, Simon, me) think that
stripping leading and trailing whitespace is not undesirable
2) The "tools" crownd (Bob, Jeremy, me) don't like re-introducing the
\n sentinel

Even if we agree we should preserve whitespace, there is no consensus
on solution

3) We can solve the leading whitespace problem by always adding a
leading newline character for the browser to eat
4) We could use a space instead of a \n as the trailing sentinel

Martin

[Udo Borkowski]

1) The "separate content and layout" crowd (FND, Simon, me) think that
stripping leading and trailing whitespace is not undesirable
2) The "tools" crownd (Bob, Jeremy, me) don't like re-introducing the
\n sentinel

I don't know where I fit into these "crowds" ;-), maybe I am in the "consistent API" crowd:

I would like to ensure that one can do

store.setValue("SomeTiddler", "text", s)

for any possible string s (including Strings with leading spaces or newlines). When loading the TiddlyWiki the next time and doing

var s = store.getValue("SomeTiddler", "text")

one would get back the same value that was put into the text field.

I thought this would not be too much to ask for, or?

As I already mentioned earlier this assertion ("retrieved value == stored value") holds true for other (custom) fields. Technically this is because these values are stored differently (in tag attributes) but from an API point of view I don't care how the tiddlers are stored and I should not need to care.

Speaking of storage formats: If we would really stick to this "leading newline lost in tiddler text" behaviour for the standard format we would also need to ensure this behaviour of all other storage implementations. Otherwise it would not be possible to switch between Loader/Savers, as some Loader/Savers would preserve the text and others would strip it. I don't think this is desirable.

Notice: I don't care how this assertion is ensured for the tiddler's text: whether using space, newline or whatever sentinels, as long as I can use any string as a tiddler's text and get it back unchanged. Using every (major) browser.

Udo

----------
Udo Borkowski
http://www.abego-software.de