embedded HTML code creates issues for MkDocs and results in wrong display on wiki.rusefi.com

[mi-hol]

example:

root cause:

fix:

use only markdown tags and remove embedded HTML code

affected markdown files

117 results - 8 files

FAQ-Ignition.md:
  42  
  43: <details><summary><u>I want to buy new coils</u></summary>
  44  


Pages-Fuel.md:
   2  
   3: <details><summary><u>rusEFI Project</u></summary>
   4  


Pages-HOWTO.md:
  2  
  3: <details><summary><u>HOW TO</u></summary>
  4  
...
Pages-Ignition.md:
   4  
   5: <details><summary><u>rusEFI Project</u></summary>
   6  
...

Pages-Sensors-and-Actuators.md:
   2  
   3: <details><summary><u>Throttle and ETB</u></summary>
   4  
...

Pages-Software.md:
   2  
   3: <details><summary><u>rusEFI Project</u></summary>
   4  
...

Vault-Of-Terminology.md:
    4  
    5: <details><summary><u>AAP</u></summary>
    6  
...

[chuckwagoncomputing]

details and summary tags work fine in Wiki3, but you have to add markdown parameters - see Cranking.md for example.

[mi-hol]

details and summary tags work fine in Wiki3, but you have to add markdown parameters

This is really thin ice and from my view won't work reliably without proper documentation and tooling!
As we already see the negative impacts of not having that, a plan to get this back under control would be a starting point.
Anything to contribute?

[mi-hol]

documentation and tooling is missing, #318 only fixed "tip of iceberg"

[chuckwagoncomputing]

Documentation now exists in https://wiki.rusefi.com/HOWTO-contribute-to-documentation/
Do you have any ideas for checking this with tooling? Write our own linter? In my opinion, the effort required to write a linter is so much more than the effort for editors to check manually that their edits haven't created a broken details section, that it's not worth writing a linter.

[mi-hol]

Do you have any ideas for checking this with tooling?

Do you happen to know https://github.com/DavidAnson/markdownlint-cli2?
Blog post https://dlaa.me/blog/post/markdownlintcli2 makes me optimistic it will fit with our requirements. See #308 for first results.

my decision factors are driven by long-term benefits & reliability not only by efforts.

editors to check manually

is unfortunately not an option to trust on because even an editor with only the best intent (like me) may introduce errors unintentionally due to lacking context, skill or requirements for a specific aspect.
What I learned is that there is never stability regarding contributors in a project team!
Meaning someone is always below the required skill level to work "error free".
Tooling is the only option to safeguard against this thread for a project's health.

[chuckwagoncomputing]

markdownlint doesn't come anywhere close to doing what we need without writing our own checks for it. I guess if somebody wants to do that, they can, but it seems to me like a poor use of developer time.

[mi-hol]

markdownlint doesn't come anywhere close to doing what we need

Could you perhaps add what you know to be needed?

[mi-hol]

markdownlint doesn't come anywhere close to doing what we need

did you check https://github.com/DavidAnson/markdownlint-cli2 as the tool I currently use?
This tool already reports them:
example:
ASIC.md:10:66 MD033/no-inline-html Inline HTML [Element: br]

[chuckwagoncomputing]

markdownlint only checks for presence of HTML.
We need HTML, with particular parameters for tags if there is markdown within them, and empty lines after particular closing tags. markdownlint doesn't know how to do any of that.

[chuckwagoncomputing]

If you want to modify markdownlint to do that, you may. If not, let's close this issue.

[mi-hol]

again #363 :(
This is my issue to deal with!

[mi-hol]

below approach is not what I envisaged

[chuckwagoncomputing]

Fixed. Details in #268