I Would Like to Fix the redundant P-tag Problem

[pmario]

TLDR; Fixing the problem described here may cause some compatibility problems with existing themes, plugins and updated wikis.

---

Create a tiddler named eg: show-p-tags tagged: $:/tags/Stylesheet with the following content and then open the ControlPanel or any other tiddler at tiddlywiki.com

title: show-p-tags
tags: $:/tags/Stylesheet

p {
  outline: 1px solid red;
}

It will give you this:

There is only 1 P-tag that actually should be there. All the others are redundant and shouldn’t be there at all.

No only do they cause problems with the existing stylesheets, The also cause problems if someone want’s to create new themes.

The reason why they are there “undetected” is relatively simple. The p-tag has a lot of style definitions, that define vertical “gaps” using CSS padding and CSS margin … So it’s kind of convenient if it is there.

.tc-sidebar-header .tc-sidebar-lists p {
	margin-top: 3px;
	margin-bottom: 3px;
}

...

.tc-tiddler-info p {
	margin-top: 3px;
	margin-bottom: 3px;
}

...

.tc-editor-toolbar button.tc-editortoolbar-stamp-button + .tc-popup .tc-drop-down > p {
	margin: 0;
	padding: 0;
}

...

.tc-drop-down p {
	padding: 0 14px 0 14px;
}

...

.tc-alert-body > p {
	margin: 0;
}

Can you see the pattern? … According to MDN. P-Tags should only contain Phrasing Content

Phrasing content

Phrasing content is a subset of flow content that defines the text and the markup it contains, and can be used everywhere flow content is expected. Runs of phrasing content make up paragraphs.

In the current TiddlyWiki UI it contains all sorts of elements which basically is semantically invalid HTML code.

Browsers are relatively tolerant using invalid HTML, but still it causes all kinds of subtle problems for all users.

Accessibility may be one of them. It profits from valid and semantic HTML code.

It should look as follows. But … As the arrow points out some CSS fixes are needed, which have not been applied to the following image

Conclusion

The question is:

• Should we fix it once and for all and cause some incompatibilities? or
• Should we still let everyone waste time and energy to work around those problems?

[telumire]

Personally I’m in favor for cleaner HTML, but you can usually fix the p tag issue easily with CSS:

:not(.tc-tiddler-body) p{
display:contents;
}

[pmario]

@telumire

Personally I’m in favor for cleaner HTML, but you can usually fix the p tag issue easily with CSS:

That’s a workaround which introduces additional complexity, which is a “shot in the foot” of someone else if they want to use your stuff.

[Maurycy]

Other benefit of fewer p tags is the slightest performance improvement since fewer widgets will get created and recreated all the time. But I’d throw it into the “microoptimzation” bin.

I am very much for cleaning up this P-tag mess. I know backwards compatibility is very important but I firmly believe that at some point you have to stop and say “this sucks more than compatibility rules”. And for me that is the point.

I do realize I speak from the place of privilege though, I am capable of fixing any styling issue that could crop up from this change on my own. I also only have two TW instances that I maintain.

[jeremyruston]

The problem here is that TiddlyWiki tries to figure out where paragraphs should go at the time of parsing tiddler contact. I now believe that that is impossible given the presence of arbitrary transclusion, and that the solution is that some of the work must be done at render time. The rough idea would be to have the parser identify generic blocks that are candidates to be paragraphs, and a new widget that determines which blocks are actually rendered as paragraphs at render time.

@pmario it might be worth linking to the previous discussions on this.

[pmario]

@jeremyruston … I’ll push a draft PR shortly, which also contains a list of xx-todo items with screenshot examples where if found visual differences.

At the moment I didn’t analyse the DOM structure that is different. … I know that there are some problems if content is rendred using widgets and macros only. As soon as there is some plain text involved everything works fine.

The change to the wikiparsre.js is 6 lines of code. It produces the wiki from the second screenshot

I did a manual side-by-side compare from about 1000 tiddlers. I left some of the filter-operators out, since they are templated and I only need to check the template.

Most of the problems come from — doc-macros. But they should be easy to fix. With some docs and checking our copy/paste examples I’m confident, that it works.

[pmario]

@Maurycy

Other benefit of fewer p tags is the slightest performance improvement since fewer widgets will get created and recreated all the time. But I’d throw it into the “microoptimzation” bin.

I think it’s not big performance improvement, but it definitely makes DOM debugging and the JS - waterfall diagram a little bit more readable. …

The next big step, which can make the DOM friendlier is to fix all reveal-widgets in the UI. The reveal widget has a tag= parameter, but it isn’t used … So most reveal widgets also create a redundant SPAN or DIV element. 99.9% of them can be optimized.

[pmario]

@Maurycy

I do realize I speak from the place of privilege though, I am capable of fixing any styling issue that could crop up from this change on my own. I also only have two TW instances that I maintain.

Me too. … But I also think, that after that change we can remove a lot of CSS rules that are overly specific, because they are not needed anymore.

So I hope /vanilla CSS will get a bit simpler to … but we will need some more utility-classes to adjust the vertical gaps, where needed. … The advantage here is that it will only need a view generic rules that can be used everywhere. In the tiddler body, the story river or the sidebar and tabs … instead of having several rules that only work in eg: the sidebar or the tiddler body

[Alvaro]

IMHO, it is better fix it, the new issues in UI (in tiddlywiki or in plugins) will be easily fixable given to the parent element (where there was a p element) a padding.
For example:

.tc-tiddler-info p {
	margin-top: 3px;
	margin-bottom: 3px;
}

to

.tc-tiddler-info{
	padding-top: 3px;
	padding-bottom: 3px;
}

or just

.tc-tiddler-info{
	padding-block: 3px;
}

[Mohammad]

Thank you @pmario
Generating extra p tags makes it hard to create stylish content using CSS, debugging and sorting out such cases take a lot of time.

So, I am very happy to see such efforts to address the problems with extra p-tags

[Mohammad]

Some previous attempts to fix extra paragraph generation issue

Improve p generation by nilslindemann · Pull Request #4290 · Jermolene/TiddlyWiki5 (github.com)

Unified html syntax by nilslindemann · Pull Request #6135 · Jermolene/TiddlyWiki5 (github.com)

Improve parser automatic paragraph generation by nilslindemann · Pull Request #4195 · Jermolene/TiddlyWiki5 (github.com)

I hope this time, p-tag generation fixed.

[pmario]

@Mohammad

I hope this time, p-tag generation fixed.

Not yet, but I hope it’s the right place, to find most of the problems.

[pmario]

There is a new Draft-PR at GitHub – that’s why I’ll close this thread.

Feedback at GitHub please.

WIP Improve redundant p tags