New Wikitext leading character for paragraphs/text sentences?

[TonyM]

Folks,

I make use of the semi-colon and colon a lot to prefix lines. I believe I have identified a very helpful additional wikitext rule.

On parsing ";" produces the html

<dl><dt>DL dt content</dt></dl>

A Bold line staring at position 1

On parsing ":" produces the html

<dd>DT content</dd>

    A non bold indented

On parsing ::: produces the html

<dl><dd><dl><dd><dl><dd>Three deep</dd></dl></dd></dl></dd></dl>

               A non bold indented three deep

This behaviour is very useful because you can add a paragraph that wrapps, and a custom editor toolbar button allows one to select multiple rows and apply a leading character.

However it would be useful to extend this with another character that on parsing produces the following html

<dl>DL content</dl>

A non bolded paragraph staring at position 1, or effectively a paragraph

I would like to;

• Identify a suitable character to do this perhaps"|" or "^" even "." (if it does not cause other problems)
• Implement a new parsing rule to provide this
• Propose it be added to the standard distribution.
• Add an editor toolbar button to insert/remove the suitable character from the beginning of lines
• Add an editor toolbar button to cumulatively insert/remove the ":" character from the beginning of lines so you can quickly select a block and chose the intent (tab equivalent) applied to each paragraph/line (without installing code mirror editor)

Justification

• On importing text this is a quick way to convert text without additional line feeds to behave as paragraphs
• Empty dl tags will cause a single line break between paragraphs (reduces pasted text with multiple blank lines to collapse, if the leading character is applied to each line)
• I wish I had this when I first came to Tiddlywiki5 as it would have helped me deal with the linefeed issue when pasting text from other sources.
• I think it will support adoption as I know this has being a show stopper for some new users.

Regards

Tony

[PMario]

Hi Tony,

There is 1 important thing you forgot: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dl#Noteit should be used

See the spec, how it should be used: https://www.w3.org/TR/html50/grouping-content.html#the-dl-element

-m

[Hans Wobbe]

Thanks @Mario

One of my on-going pleasures is the learning that comes from following-up on your comments.

[TonyM]

Mario,

You may be able to see in the OT what I achieve with use of the dl tag contrary to the standards you point out. This outcome is what I am after.

I understand your post as implying my use contraveins standards? Fair enough.

However with your broad knowledge, it would be great if you could suggest an alternate and appropriate way to achieve what I proposed, including an appropriate character to use in wikitext.

I am keen to move forward on this and value your "constructive criticism", but to be very honest when someone only offers a criticism and no way forward it basically kills the thread, meaning to progress the matter you force the poster to source a solution to keep the thread alive. I posted because I could not find a solution and needed consensus, and would hope the thread would accumulate suggestions, ie stay alive receiving constructive input.

Please share an inspired suggestion on how we can move the original requirement, if not the proposed mechanism forward.

Best wishes

Tony

However it would be useful to extend this with another character that on parsing produces the following html

<dl>DL content</dl>

A non bolded paragraph staring at position 1, or effectively a paragraph

[PMario]

Hi Tony,

You know, that I try to offer alternatives, if I have one. ... At the moment I don't.

You are right. I did react on the "how" you want to achieve something. ... I should have reacted on the "what" you want to achieve. ... I basically did "kill" the thread, because I strongly think, the "how" has to be killed.

Especially since:

• Propose it be added to the standard distribution

We would have to live with it for ever.

---------------

I think the "what" is a valid! ... We can continue on that one.

So I'd like to rephrase it, how I see it: --- I'm not sure, if that is what you wanted. ... It's what I see.

 1) "How can we achieve text indentation" similar to UL or OL, without the markers.

 2) "How can we improve importing text from other sources" ... IMO that's a completely different thing and it shouldn't be mixed.

ad 1)

There is a limited amount of "text content" html tags. Some of them do include indentation by default. Most of them don't.

IMO candidates are:

 - OL

 - UL

 - DL

 - P

ad 2)

 

TiddlyWiki wikitext is a highly opinionated markup language that started it journey in 2004. There are not many projects on the web, that are living that long and I believe text based wikitext is one reason. 

I think, if other content is imported, it needs to be fully converted. In the long run, this is the solution, which causes the least maintenance problems. Maintenance cost will always outweight initial setup cost.

So there can be some buttons, that modify text based input. eg:

 - double line breaks in the text selection, to create a paragraph or

 - convert leading "-" into "*" or "**" depending on their indentation ... or something similar.

For this to work we would need to analyse imported text and create some helper buttons. Which shouldn't be that difficult.

Finding the right buttons and their actions is difficult.

to be continued...

have fun!

mario

[@TiddlyTweeter]

Ciao TonyM

I thought it an interesting question because its trying to find a direct simple solution to a layout issue that makes a bunch of sense. 

I thought that PMario's later comment, a pointer, helpful in underlining that, actually, HTML is *not* that brilliant on variation.

There is a limited amount of "text content" html tags. Some of them do include indentation by default. Most of them don't. 
IMO candidates are: 
 - OL
 - UL
 - DL
 - P  

The issue, I think, is, as you indicate, about parsing? Or, maybe, CSS?

One solution might be to write a modified (JS) parser that will recognise  either additional characters, or perhaps "combos" of what exists, e.g. ::, :;, etc. The issue is the nesting to produce valid HTML, for that, nesting, the List parsers would be helpful models. 

Another way might be through CSS because you could define a cascade of styling that could be applied differently to different HTML nesting structures.

My tuppence

TT

[PMario]

On Monday, September 2, 2019 at 11:18:09 AM UTC+2, PMario wrote:

So I'd like to rephrase it, how I see it: --- I'm not sure, if that is what you wanted. ... It's what I see.

 1) "How can we achieve text indentation" similar to UL or OL, without the markers.

 2) "How can we improve importing text from other sources" ... IMO that's a completely different thing and it shouldn't be mixed.

ad 1)

There is a limited amount of "text content" html tags. Some of them do include indentation by default. Most of them don't.

IMO candidates are:

 - OL

 - UL

 - DL

 - P

As MDN indicates OL, UL and DL should not be misused to create indentation. ... I think there is 1 exception for the UL element. Where we still use it as a list, but without the bullet at the beginning. ... Sometimes the bullet just isn't the right thing to show, so it should be hidden.

I think it's the case, when an indented paragraph is a description of the parent element. Bullets just don't fit there.

We have a possibility to assign user defined classes to UL. like:

*.testClass level 1
** level 2

Which gives us the following HTML code, where the class is assigned to the <li> element.

<ul>
  <li class="testClass">level 1
    <ul>
      <li>level 2</li>
    </ul>
  </li>
</ul>

Which looks a bit strange but is right.

What we probably would like to get is

<ul class="testClass">
  <li>level 1
    <ul>
      <li>level 2</li>
    </ul>
  </li>
</ul>

And define the CSS ul.testClass * { list-style-type: none;}

So a wikitext syntax could look like

*^testClass level 1

** level 2

So the *^ indicator would be only needed once. I personally would go with

*^_ level 1

This would be a new indicator for every element, that allows custom classes AND where a parent element exists.

 - I'm not sure if the parser can handle that.

 - I'm not sure if this can be implemented in a consistent way. Especially:

* level 1

**^x level 2

doesn't make sense, since it is the same as

*.x level 1   ... Which is much more readable.

So this would be my proposal for ULs without bullets. ... Which should NOT be used for indented paragraphs. P-tags should be used there. 

have fun!

mario

[PMario]

On Monday, September 2, 2019 at 2:20:46 PM UTC+2, PMario wrote:

 

 - I'm not sure if the parser can handle that.

 - I'm not sure if this can be implemented in a consistent way. Especially:

* level 1

**^x level 2

doesn't make sense, since it is the same as

*.x level 1   ... Which is much more readable. <-- uups that's wrong!

**^x level 2

Having a look at the HTML code it does make sense. ...

-m

[PMario]

On Monday, September 2, 2019 at 1:18:31 PM UTC+2, @TiddlyTweeter wrote:

...

I thought it an interesting question because its trying to find a direct simple solution to a layout issue that makes a bunch of sense. 

Mixing content with style isn't the best idea, because there should be "separation of concerns". So wikitext should be used for content and CSS should be used for styling.

BUT

We already _need_ to mix it eg:

*.userClass list-text

**.otherClass more-text

Which isn't the best solution, but the only one. ... So if we want to get work done, we need to make compromises. ... AND we probably have to live with them for ever.

The issue, I think, is, as you indicate, about parsing? Or, maybe, CSS?

I think both. See my other posts.

I think, creating the `^` prefix for "parent-classes" is a real improvement, since we only need to use the "ugly syntx" once.

At the moment we need:

*.class some text

*.class more text

in the future it would be only

*^class some text

* more text

But I'm not 100% convinced atm.

-mario

[Arlen Beiler]

I like what is being proposed here. 

I agree with mario that it would be better to add a converter, or perhaps just a search and replace that supports regex so we can replace single line breaks with double line breaks. That might be another good option. 

The Wikipedia community uses the colon character for indenting text in a forum thread style (which converts to the same HTML as this). It's not the most efficient but it works fine. Because each reply is indented you'll sometimes see a long-running debate WITH 12 COLONS STARTING A LINE. That's a big indent! They don't use it on articles as much as on discussion pages. 

Just a couple observations.

Arlen

--
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 tiddlywikide...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/522ab1c2-a1e3-4605-bedf-d2edf87aaaa9%40googlegroups.com.

[Arlen Beiler]

Maybe we should say if the parser finds the asterisk directly inside a UL tag then it should just output the LI tag without another UL tag. Some with the pound sign and the colon. In other words, if the outer list element is the immediate parent to the list item line, it should not output a second outer list element inside it but go directly to the inner list item. The same would apply to the table tag. 

--

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 tiddlywikide...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/ef87590d-8887-4a20-978d-83d8b7c0d1f1%40googlegroups.com.

[PMario]

On Sunday, September 1, 2019 at 5:10:06 AM UTC+2, TonyM wrote:

...

I would like to;

• Identify a suitable character to do this perhaps"|" or "^" even "." (if it does not cause other problems)

Hmmm,

At the moment a paragraph is started using 2 linebreaks in a row. If we would say: "If a paragraph starts with a dot it is a user class definition"

eg:

.userClass Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,

I'm not sure if

^userClass Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,

would make sense and I'm not sure if the paragraph parser can handle it.

-m

[PMario]

On Monday, September 2, 2019 at 2:41:33 PM UTC+2, Arlen Beiler wrote:

Maybe we should say if the parser finds the asterisk directly inside a UL tag then it should just output the LI tag without another UL tag. Some with the pound sign and the colon. In other words, if the outer list element is the immediate parent to the list item line, it should not output a second outer list element inside it but go directly to the inner list item. The same would apply to the table tag. 

IMO the rules should be simple and generic. If they are, they are relatively simple to implement.

And if they are complicated, I'm very confident, that Jeremy willll be very hard to convince ;)

-m

[TonyM]

Folks

Thanks all for your thinking on this but do consider my initial post. I don't want indentation I want no indentation but not bold as is the case with semicolon. Basically a paragraph.

That's all I want. Very simple leading character addition to wiki text and a matching editor toolbar button that would prefix selected lines just as * and # currently. If available I would use period.

If you want I can argue the merits, but first can we do this - YES and what character can I use?

regards
Tony

[@TiddlyTweeter]

TonyM wrote:

Thanks all for your thinking on this but do consider my initial post. I don't want indentation I want no indentation but not bold as is the case with semicolon. Basically a paragraph.

I think you are missing the point that has been made several times. You are EITHER changing HTML or changing CSS, or both. How else you gonna do it?

The indentation is irrelevant to the STRUCTURAL issue. That is a doddle. After. CSS basic.

 

That's all I want. Very simple leading character addition to wiki text and a matching editor toolbar button that would prefix selected lines just as * and # currently. If available I would use period.

So what HTML or CSS structure you thinking of? 

 

If you want I can argue the merits, but first can we do this - YES and what character can I use?

You can use in a parser anything. How about ".tony" at the start of the line? :-)

More seriously the various non-alpha characters have been used across many implementations. 

I would just use one not used already in TW. 

It is entirely arbitrary so opinion of the matter is slightly irrelevant. Just assert it.

I myself like a way that aficionados of markup loath like "A:". The point is to just do it :-)

TT

 

[TonyM]

TT

I want to extend the Wiki text markup to include a character that does what I suggest. so lets say I go with period "." - paragraphs or lines with a leading period would be rare and unusual. In fact if we make it first character - Period+anychar not space we can make it more precise. 

I believe it is ok to use a simple `<p></p>` tag pair unless it will somehow break tiddlywiki. I am however exploring further improvements.

I think you are missing the point that has been made several times. You are EITHER changing HTML or changing CSS, or both. How else you gonna do it?

OR Wikitext markup! Most respectfully, perhaps you are missing my point? Of course wiki text in rendered to html/css but I want a single character wiki text indicator 

The indentation is irrelevant to the STRUCTURAL issue. That is a doddle. After. CSS basic.

I am not sure what it has to do with structural issues but it is not irrelevant to handling pasted text 

 

 

You can use in a parser anything. How about ".tony" at the start of the line? :-)

More seriously the various non-alpha characters have been used across many implementations. 

Perhaps period is a good one, this is why I asked. Ideally a single character entry to allow one to quickly refomat a text tiddler with a "." at the start of each indepenednt paragraph that will also have single line breaks between paragraphs.

 

Regards

Tony

[PMario]

On Tuesday, September 3, 2019 at 3:03:01 AM UTC+2, TonyM wrote:

...

Perhaps period is a good one, this is why I asked. Ideally a single character entry to allow one to quickly refomat a text tiddler with a "." at the start of each indepenednt paragraph that will also have single line breaks between paragraphs.

 

I'm pretty sure single line breaks between paragraphs can't happen. It is not backwards compatible and will produce a lot of unwanted p-tags all over the place in the existing UI.

-m

[PMario]

On Monday, September 2, 2019 at 2:01:53 AM UTC+2, TonyM wrote:

...

You may be able to see in the OT what I achieve with use of the dl tag contrary to the standards you point out. This outcome is what I am after.

I understand your post as implying my use contraveins standards? Fair enough.

If you have a closer look at the spec at "Content model" for the dl-tag, it states:

Content model:

Either: Zero or more groups each consisting of one or more dt elements followed by one or more dd elements, optionally intermixed with script-supporting elements.

Or: One or more div elements, optionally intermixed with script-supporting elements.

IMO we can't use this element.

With TW we already have some severe and hard to fix problems, because the existing parser is a bit sloppy at creating HTML code. Not to say it ignores most of the rules.

This isn't a big problem if the content and the created HTML output stays within TW. _But_ it is a problem if the content should be re-used as an input for an other system that runs an HTML validator as the first step. ... Such systems can be found in enterprise environments or if a user needs to have "semantic" HTML code.

We want TW to spread. So we should make our output more compliant and not less.

just some thoughts.

mario

[@TiddlyTweeter]

TonyM wrote:

 quickly refomat a text tiddler with a "." at the start of each indepenednt paragraph that will also have single line breaks between paragraphs.

Did you really mean 1? Or a blank line between paragraphs (which means, 2 in editor)? Just checking. 

 

PMario wrote: 

I'm pretty sure single line breaks between paragraphs can't happen. It is not backwards compatible and will produce a lot of unwanted p-tags all over the place in the existing 

That is my impression too. In a way the discussion is touching on "Content-type". My understanding is that the standard CT in TW has some "global" parser rules that other parsers need honour? Not sure.

FYI, I have myself used BJ's plugins that can create new CTs, or support hybrid ones, where you can run a "pre-parser" before the standard parsers kick in. It works well for my needs (screenplays).

TT

[PMario]

On Monday, September 2, 2019 at 4:07:03 PM UTC+2, TonyM wrote:

Thanks all for your thinking on this but do consider my initial post. I don't want indentation I want no indentation but not bold as is the case with semicolon. Basically a paragraph.

I'm confused

A Bold line staring at position 1

use

''A Bold line staring at position 1''

This produces:

<p><strong>A Bold line staring at position 1</strong></p>

------------------

A Bold line staring at position 1

produces

<p>A Bold line staring at position 1</p>

That's all I want. Very simple leading character addition to wiki text and a matching editor toolbar button that would prefix selected lines just as * and # currently. If available I would use period.

IMO no new syntax needed.

-m

[PMario]

On Tuesday, September 3, 2019 at 10:19:53 AM UTC+2, @TiddlyTweeter wrote:

...

That is my impression too. In a way the discussion is touching on "Content-type". My understanding is that the standard CT in TW has some "global" parser rules that other parsers need honour? Not sure.

FYI, I have myself used BJ's plugins that can create new CTs, or support hybrid ones, where you can run a "pre-parser" before the standard parsers kick in. It works well for my needs (screenplays).

There is some discussion going on, how to use different TW type field settings. ... But imo that's more of a 5.2.x topic.

-m

[@TiddlyTweeter]

PMario wrote:

With TW we already have some severe and hard to fix problems, because the existing parser is a bit sloppy at creating HTML code. Not to say it ignores most of the rules. 

This isn't a big problem if the content and the created HTML output stays within TW. _But_ it is a problem if the content should be re-used as an input for an other system that runs an HTML validator as the first step. ... Such systems can be found in enterprise environments or if a user needs to have "semantic" HTML code. 

I always appreciate  you contextualising TW in a bigger picture! It actually is very helpful.

We want TW to spread. So we should make our output more compliant and not less. 

I like idea of compliance as a key goal. 

On the other hand, TW, as a self-contained App., I'm not convinced "drift" from standards is always bad so long as the thing functions for purpose.

TT: FYI, I have myself used BJ's plugins that can create new CTs, or support hybrid ones, where you can run a "pre-parser" before the standard parsers kick in. It works well for my needs (screenplays).

There is some discussion going on, how to use different TW type field settings. ... But imo that's more of a 5.2.x topic. 

But will I be dead before 5.2? That is a question :-). One has to get on and do stuff already too!

Just a footnote

TT

[@TiddlyTweeter]

TonyM wrote:

... so lets say I go with period "." - paragraphs or lines with a leading period would be rare and unusual.

Regardless of other points. One of the reasons for using "punctuation" in simple markup systems is that "?!;:',. etc" in normal writing don't occur at the start of lines alone. In writing usage they are always abutted to text. 

So "." looks viable.

TT

[Jeremy Ruston]

Hi Tony

There’s also the blockquote markup:  “>” for single lines, and “<<<“ for block mode. The single line format is treated as a list format:

> I’m a quoted line

>* I’m a nested bullet point

* I’m a top level bullet point

>> I’m double quoted

>># And I’m numbered

>># Like this

The default styling applies a vertical bar to the left of blockquotes, but you can remove that with some CSS:

blockquote {

    border-left: none;

    margin-left: 25px;

    padding-left: 10px;

}

You can also apply a class to any of the list formats:

>.my-class This is a blockquote with a class applied to its nested paragraph

*.another-class This is a list item with a class applied to its LI tag

Best wishes

Jeremy.

--
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 tiddlywikide...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/a67dd7c2-1d70-41ba-975b-c4478f605d95%40googlegroups.com.

[TonyM]

Folks,

I have continued looking at this and it seems '<p>' is enough unless it interferes in some way with tiddlywiki.

Mario I understood I proposed an illegal use of DL. I was using it initially to demonstrate it working as desired. Thanks

If a 1st leading period wrapped the line/paragraph in the p tags during rendering, it would do as I suggested. Multiple empty pairs of paragraph tags collapse into a single blank line on display.

An aside. I note In tiddly wiki you can make up your own html tag name and apply styles.

So If I paste text from a source that does not have sufficient breaks to stop all paragraphs flowing together it would be possible to have an editor toolbar button that prefixes every line/paragraph in a selection with a period. On rendering the leading period will cause each line to be wrapped as a paragraph which in fact they are. The render process could also include an identifier for additional styling.

It should be just as easy to remove the leading period if required.

The advantage over other methods is all wiki text markup will be valid within the paragraphs.

Much of the text I have sourced either has insufficient breaks or too many. This method helps with that as well.

I will keep looking to see if there is a better way.

But any advice how to implement it would help.

Thanks
Tony

[PMario]

On Tuesday, September 3, 2019 at 12:07:56 PM UTC+2, TonyM wrote:

...

So If I paste text from a source that does not have sufficient breaks to stop all paragraphs flowing together it would be possible to have an editor toolbar button that prefixes every line/paragraph in a selection with a period.

Or you create a toolbar button, that doubles every linebreak and make it a human readable wikitext paragraph, that is rendered by the default renderer.

-m

[TonyM]

Mario

I think even wrapping each line in a '<p class="custom">' may be effective however a leading period that does the same at render time has a much lower impact visually when editing the text. It would be convenient when typing text just as ; and : # and * are.

I would be fine if this was an optional wiki text character/rule and would be easy to remove if necessary especially with an editor toolbar button.

So if I can get some tips to add this it would be great.

Regards
Tony