>
> It seems the br & p topic is much more heated than I would have imagined.


I'm afraid so. Getting the wikitext syntax right feels like trying to do
twelve dimensional tetris.


> Since it dose seem like people are on one side or the other, maybe the
> simplest option would be to make it a site wide option that can be set in
> the ControlPanel?
>
> ◎ Classic Mode [All linebreaks are created as br tags no p tags
> are generated]
> ◎ MarkDown - Standard Mode [p tags are created on double line breaks, br
> tags are made with double space + linebreak at the end of a sentence]
> ◎ MarkDown Mode + Creole linebreaks [p tags are created on double line
> breaks, br tags are made where \\ are]
> ◎ MarkDown - No linebreak Mode [linebreaks are only made when you use a br
> tag]
>

The trouble here is interoperability - this setting would mean that content
imported or synced from different sources would appear differently
depending on whether it was authored in the same mode as the host document.


> I do have one question though.
> I assume it most not be easily possible but it seems like the ideal option
> would be to have things like this:
> Single line-breaks = br
> Double line-breaks = p
> if you wanted more than one br you would simply add a space:
> [line-break]
> [space][line-break]
>

That suffers from the issue discussed early that spaces are invisible when
editting in the browser. It would be desirable to keep the wikisyntax
visible.


>
> this of course relies on something I've yet to ever figure out... Why do
> we need a system that ignores single line breaks?
> If you want paragraph that don't have line-breaks than the answer seems to
> be to be simply not use line-breaks.
>

I believe that the idea arose in the early days of email: when editing a
message it was a nuisance to manually wrap the text at the customary
column, and so email clients started to automatically reflow messages
during sending. It turns out to be useful when you're copying and pasting
text from systems that use hard line breaks.



>
> Last time I checked periods don't make line-breaks the
> line-break character makes line-breaks.
>
> The only time where single line-breaks create a mess is for styling and
> other special cases:
>
> @@background:red;
> text block1
> text block2
> @@
>
> which is where you really need a special system to null out a line-break
> like like adding ^^ or // or ++ or &&
>
> @@background:red;^^
> text block1
> text block2
> @@^^
>
> To me it seems like the need to remove single-line-breaks are the special
> case rather than the other way around.
>
>
If I understood correctly, the time that this becomes an issue for you is
when making quick notes, where you're accustomed to separating items with a
single line break. Is that right?


> -----
>
> As for the other
>

I'll comment on the behaviour you're reporting here, but acknowledge that
this is an area where the syntax has become confusing, and needs to change.


> I did notice that spans where created for single-line inline which is nice
> in some case but in many cases at least for me I need spans to wrap around
> a larger block of content.
>
> Simple example:
>
> @@background-color:red;display:inline-block;
> text
>
> text
>
> text
> @@
>
> This of course gives p styles so isn't what we want.
> <p style="background-color:red;display:inline-block;">text</p>
> <p style="background-color:red;display:inline-block;">text</p>
> <p style="background-color:red;display:inline-block;">text </p>
>

Currently, when used in block mode, the @@ construction purposely doesn't
create a wrapper element but applies the styling/classes directly to its
child elements. This makes it possible to apply styles directly to, say,
the <UL> element generated by an unordered list - in fact, there's no other
way to do that.


>
> So how about the inline for the span?
>
> @@background-color:red;display:inline-block;text
>
> text
>
> text
> @@
>
>
Here, by using the inline syntax for @@ you are causing the content to be
parsed as inline text, which means that block syntax such as paragraphs and
headings isn't recognised.


> Gives us a span output but nulls out all our <p>'s and with no <br />'s we
> loss all notions of white space.
> <p>
> <span class="tw-inline-style"
> style="background-color:red;display:inline-block;">text text text </span>
> </p>
>
>
> All and all very different than what I would have actually wanted:
> <span style="background-color: red; display: inline-block;">
> <p>text</p>
> <p>text</p>
> <p>text</p>
> </span>
>

Right now, the best way to do this is to write the <span> directly as a
span. Once I'd enabled intermixed HTML tags with wikitext it seemed less
important to provide wikitext equivalents to things that can already be
expressed clearly in HTML.


>
> So I do very much think it's a needed component, to have a unique span
> system that properly wraps around multi-lined content.
> I may be biased to making transition easier for people who already use
> Classic TiddilyWiki but it doesn't seem like the
> {{Class{Content}}}
> is being used by anything else in the new system, and logically makes
> sense simply to carry it over as the syntax given that any other real
> variation ((Class(Content))) is simply aesthetics and in the long run only
> forces people who use both TW5 and Classic to remember an odd difference,
> with no true benefits.
>

Currently, TW5 uses double curly braces for transclusion, following the
lead of a number of other wiki engines.

Best wishes

Jeremy






-- 
Jeremy Ruston
mailto:[email protected]

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to