Yes, this is missing in TiddlyWiki wikitext

Note that you can override the behaviour from “;” – or any wikitext markdown AFAICT – with CSS to make it appear as you wish. If you you rarely use definition lists, you could use the : and restyle to remove the indentation.

Using only a : (i.e the dd) actually automatically adds an envloping dl, so this works and I think it fulfills the formal syntactical needs for accessability etc:

:foo
:bar

<style> /* or in a stylesheet, of course*/
dl dd {margin-inline-start:0;}
</style>

Yes, you need to prefix every line with the character, i.e it doesn’t “sense” the soft linebreak, which is what you really wish for.

1 Like

This is correct and it illustrates we just do not have a symbol that can be freely applied to “any other line”. Since the parsers default is to turn “any other line into a paragraph with wrapping” it would be nice to have one that defaults to a “div ending at new line with no wrapping”. Allowing us to add css with the .classname.

In the meantime I will use Marios “space space newline”, using the "space space \" when I need it visible. Then in more advanced cases the custom markup.

I plan to use custom markup to introduce a range of “presentation elements” when authoring content such as indent, assides, sections, info boxes etc… all with a simple “markup”.

1 Like

That’s, what it is intended to be used for.

As I wrote. The next version may have a possibility to define the symbol. So it should be possible to do this:

ASIDE some text.

Where ASIDE is the symbol, that used to be degree ° in my other examples. … I’m not sure yet, if it is possible to replace existing symbols like !, *, # and so on. It’s not a primary goal, to be able to do that.

1 Like

Wunderbar! Even if the simplicity of a single symbol typically is desirable, I think it would be really cool with full string names (like `ASIDE) and creating complex styles/behaviours… in fact: just WOW! …CSS is pretty powerful and in combination with some programmatic behaviour (like breaking newlines) this really opens up possibilities.

Wundercafé!

My experience with Custom Markup has been wholly positive. It works very well with extant TW and is extremely powerful. In my use cases I use it to deliver custom layouts and to easily access some HTML elements that normal TW Wikitext does not fully support.

In a way it is a “minority sport” but, overall, it is very liberating.

Cutting to the quick … I, for my use, want to be able to utilise the gamut of HTML elements in an easy way. Custom Markup makes that easy.

IF @pmario might allow arbitrary designation of the base markers I think it could be ace+.

Side comment
TT

On a best-practices note, I have recently been trying to wean myself from using this easy trick

:line one
:line two
:line three

… when I want a super-fast way to make line breaks behave as desired. Why resist this? Well, the resulting html from ; and : shortcuts is semantically bound to the defined-term and definition <dt> and <dd> tags. Not all of my wiki-making is public, but some is, and I want to be free to pull things over into public projects without second-guessing their accessibility.

Most occasions when I want simple line-breaks without extra space, I’m effectively making an unordered list (say, “thoughts while listening to this talk”). So figuring out how to make a whole tiddler, or part of a tiddler, display in this way ought to involve a variant on <li> tags, along with css that styles them without any bullets or indentation. (Or, more likely: we keep hanging indents in the css, so that the start of a new line is visually salient even when a long line wraps.)

-Springer

In the same vein I commonly do this;

;next actions

  • act1
  • act 2

But in what way does that make it inaccessible? Is it that e.g a “voice reader” or other accessibility tool will read it out as a dt list but in your text it is not shown as such but merely appears as a list? If this is the distinction, when would this have any negative consequences?

Just an observation.

The whole layout thing here is also dependent on CSS.
Break control is well managed via CSS for all the spacing variants.

TBH I think this is a hot sweat looking in the wrong direction.

Just a comment,
TT

@TiddlyTweeter I will respectfully disagree with what appears to be the minimisation of this problem that at least I recognise for myself.

CSS can resolve issues especially for less common cases but there are few word processors or markup (as others reported) where being able to choose between a newline representing a “line” or “Paragraph” is not possible, at the keyboard and in the editor.

CSS often demands we wrap something, apply a class etc… which means we are forced enter css, remember a class name and have to nominate a beginning and an end, and in future make sure new items are placed inside or outside this wrapping. CSS also usually involves more than one tiddler. This although achievable is long winded, fiddly, requires memory/documentation and introduces some fragility.

Now if you are an author, wanting to produce a lot of content, just a little extra complexity will reduce productivity.

Problem statement follows (again)

I do think this is a glaring gap; show me the intermediate result in wiki text between
Text in the editor;

line one
line two
line three

Paragraph process appends and gives you
line one line two line three

<new-line><new-line> ie an empty line between. Gives you

line one

line two

line three

There is no option to simply type at the keyboard so you see the following;

line one
line two
line three

I just tried the <space><space><newline> of @pmario and unfortunately it itself is forcing two extra line breaks if you want wikitext recognised;

This is a sentence ending in space-space-newline  
* next item

Returns exactly what you see above and the * is not transformed into a bullet.

You need two empty line, yes two, before the bullet works defeating the value of space-space-newline in the first place.

Sure;

line one<br>
line two<br>
line three<br>
* next

The above gives the desired outcome but is this acceptable? 4+ characters, two needing shift to enter, to represent end of line? is somewhat ugly, and needs to also be applied to subsequent items inserted. Not to mention the next line not working as wikitext.

Sorry, but “something is not right, in paradise”.

I’m not sure what I’m more surprised by in the following - that // and '' work, or that * etc don’t.

And no, placing newlines around the bullets does not affect the result.

Tones, you’re right. It’s a “gap”. I don’t foresee it changing either (based on something I recall Jeremy saying a long while back).

1 Like

Yes, I have being down the “”“triple quotes”"" path before and saw the inconsistencies you do.

What I would like recognised, not how but that it needs to be resolved.

It is irrelevant, if it can or can’t be done using the core, the parser or any other obscure component or mechanism.

This is to me a clear usability requirement, if it needs a plugin, a hack, new type, an alternative view template, custom markup - one of dozens of different approaches available to us in tiddlywiki then so be it. If such a solution is not perfect then lets see if we can improve it, or live with it.

Also necessity is the mother of invention, so let us say “it is necessary”.

Certainly stretches (if not outright fails) PLS - the principle of least surprise.

@jeremyruston care to jump in and explain the outcomes we’re seeing?

1 Like

I’m not Jeremy, but I know the reason.

From https://tiddlywiki.com/#Block%20Mode%20WikiText:

The above WikiText types are only recognised in block mode . However, the text enclosed by most of them will be parsed in inline mode (Block Quotes in WikiText and Styles and Classes in WikiText are the two exceptions in which the parser will continue in block mode ).

https://tiddlywiki.com/#WikiText%20parser%20mode%20transitions attempts to explain when parsing mode transitions will happen. HTML element with a blank line is one way to get the parser to recognize block mode punctuation again:

"""
* not recognized as a list
* also not recognized as a list
<div>

* blank line following html element transitions to block mode and this list item is recognized
* and so is this list item
</div>
"""

These tiddlers show a lot of parser mode examples:

https://tiddlywiki.com/#Block%20Mode%20WikiText%20(Examples):[[Block%20Mode%20WikiText%20(Examples)]]%20[[WikiText%20parser%20mode%3A%20HTML%20examples]]%20[[WikiText%20parser%20mode%3A%20macro%20examples]]%20[[WikiText%20parser%20mode%3A%20transclusion%20examples]]

twMat,

Yes: Universities and other institutions require employees to abide by accessibility norms for screen-readers whenever they generate public-facing html. And indeed, being told that one is about to hear a definition would be pretty annoying, if in fact that’s not what’s going on…

Meanwhile, I myself have decided to embrace semantic html anyway whenever possible (and to tweak my css as needed). After all, if my future self – or someone who inherits my project, etc. – decides to bring some fancy css to bear on things like definitions, abbreviations, citations, emphasis (whatever), it would be nice to know my tiddlers are not littered with gratuitous cosmetic uses of the corresponding tags for each of those information niches. (This is analogous to specifying named Palette-colors rather than hard-coding a color, to maximize forward-compatibility.)

-Springer