BUG? -- In-Tiddler <style> tag

[TiddlyTweeter]

If you test on TW 5.1.21 this works in a single Tiddler ...

!!! Test

<style>
h3 {color: red; font-size: 5rem}
</style>

This seems to break it, no style is applied... The single blank line after  <style> breaks it? 

!!! Test

<style>

h3 {color: red; font-size: 5rem}
</style>

 

Best wishes

TT

[TiddlyTweeter]

Email repeat ...

[PMario]

Hi,

No bug, just wikitext to HTML conversion. The second example results in

<h3 class="">Test</h3><style><p>h3 {color: red; font-size: 5rem}
</p></style>

See the additional <p> tags, that break the style definition.

So it's: What you get, is what you defined and not what you expected.

-m

[TiddlyTweeter]

I need to think about that!

It is counter-intuitive.

Later

TT

[PMario]

Hi,

It's defined in the wikitext paragraph rule. If a text is "prefixed" with 2 newlines, it is covered in a paragraph element. ...

There are some "edge" cases, where the existing parser is relatively "relaxed" about creating invalid HTML text. ... Your example may be 1 of them. ... may be.

There is a pending pull-request, which tries to improve parser paragraph-handling. The PR creator does a deep-dive and seems to understand the topic very well.

So if you think it would be worth it, you can +1 the OP at github: https://github.com/Jermolene/TiddlyWiki5/pull/4290

As I wrote. I don't know, if the PR will solve the problem you mentioned, but it may be worth a try.

have fun!

mario

[TiddlyTweeter]

Mario

Is that to do with the appearance of excess "<p>" under Type: "text/vnd.tiddlywiki" ?

I noticed it since having HTML preview in the editor. I notice it gets worse if when you need normal HTML tags rather than WikiText.

I'd assumed it was a "problem"; not evidence of something you should not do. 

What I mean is---isn't "text/vnd.tiddlywiki" meant to be a MIXED format of WikiText and HTML? 

And the excess <p>'s an issue?

Just asking

Josiah, x

[TiddlyTweeter]

Ciao Mario 

I commented on GH here & here.

Thanks for the pointer!

TT

On Saturday, 23 November 2019 13:54:47 UTC+1, PMario wrote:

[PMario]

On Saturday, November 23, 2019 at 2:36:03 PM UTC+1, TiddlyTweeter wrote:

...

Is that to do with the appearance of excess "<p>" under Type: "text/vnd.tiddlywiki" ?

There is a fundamental difference between tw-wikitext and HTML.

 - As per definition in wikitext "whitespace matters"

 - As per definition in HTML "whitespace is ignored" ....

Those 2 fundamentals won't go together. ... ever...

In "text/vnd.tiddlywiki" the "whitespace matters" rule will take precedence. Except if the \whitespace trim pragma is used.

So TW templates which contain a lot of html should always start with \whitespace trim. UI templates are special, for this reason.

In all other cases, where you don't use the pragma, wikitext rules will be applied.

text/vnd.tiddlywiki allows us to include text/html ... but the rules are txt/vnd.tiddlywiki.

-mario

[TiddlyTweeter]

Are you SURE this is so clear to novice users?

[TiddlyTweeter]

The problem is that the rule is NOT consistent. Works ... & does not

!! Working

<<<

Working

<<<

RENDER 

But this does not ...

Not Working

<<<

Not working

<<<

RENDER 

Why?

TT 

[PMario]

Short version:

The wikitext syntax and the parser contain some inconsistencies, because there are some main goals, which "rule them all"

 - Prose text should be without any "formatting markers"

 - Wikitext should be human readable, even if _not_ rendered

 - Formatting markers should be unintrusive

    - eg: ''bold''  //italic// ...

Those main goals cause a lot of "missing" information for computers. ... Our "super computer" (the brain) on the other hand can still make sense of it, because of sheer calculation power (not speed ;).

In comparison, most datacenters are still stupid.

... There is some hope!

Longer version ;)

On Saturday, November 23, 2019 at 7:53:18 PM UTC+1, TiddlyTweeter wrote:

The problem is that the rule is NOT consistent. Works ... & does not

!! Working

<<<

Working

<<<

This works, since tw tries to "be nice"

I personally would consider a heading starter !! without 2 new-lines at the end to be a syntax error. But that's only my point of view and there would be many complains, if we would enforce it.

TW is able to detect a heading with a !! start and 1 new-line at the end... since we don't allow multi-line headings.

If we would allow them, the above code wouldn't work.

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

You are comparing apples with pears here.

The above would need to be as follows to compare the same tings.

This text starts a paragraph
!! This text should start a heading - but it doesn't since the paragraph isn't finished yet.

The same rule is applied to the text below.

The text with 1 new-line indicates a paragraph start. So the TW-parser searches for the end of the paragraph. -> 2 new-lines

Since 2 new-lines are found after the "heading" it includes the "heading text" into the paragraph.

So the heading isn't detected. Same thing is true for your second example.

But this does not ...

Not Working

<<<

Not working

<<<

There are some more inconsistencies in the wikitext creation, which are "caused" by - how the TW parser works. It's a regexp based parser, which is optimized for speed and "code simplicity".

If you write plain wikitext, the content should be human readable, even without rendering. So if users get some "raw text" snippets, they should be able to make sense of the text.

... But this fact, also makes "format detection" harder for programmers, because wikitext should not be "polluted" with markers. So some times we have to "guess" ... which may be wrong.

Basically, there is a "start sequence" and an "end sequence" defined. Some rules start a "block mode" like <<< ..

If a block mode is active, the "content" between start and end is wikified again. This allows us to detect eg: "!! heading" within a blockquote. and so on ...

As long as "block mode" is active other blocks can be "nested".

But as soon as the parser internal state is "inline mode" it only detects formatting like eg: ''bold'' ... That's the reason, why the transclusion-widget and some others, have a mode parameter: block / inline. Which tells the parser, what it should do, because "guessing" may cause the wrong decision.

I hope that makes sense.

have fun!

mario