More headings in the wiki syntax

[anonymous]

There is now only 2 levels of headings in the wiki.

I would propose too add it to 3 or 4.

So

!=== Heading3 ===

!==== Heading4 ====

How do you escape the above and get rid of the '!' ????

[daniel]

The Trac wiki formatter will properly process H1-H6 headers.

Example:

= Header 1 =
== Header 2 ==
=== Header 3 ===
==== Header 4 ====
===== Header 5 =====
====== Header 6 ======
======= Header 7 =======

Display:

Header 1

Header 2

Header 3

Header 4

Header 5

Header 6

======= Header 7 =======

[anonymous]

Sorry. I checked and it works for me aswell. I think that settings were just set so that I didnt see that the fonts were different.

Thanks.

[sid]

Replying to daniel:

The Trac wiki formatter will properly process H1-H6 headers.

Actually, it only supports H1-H5. Anything beyond that is ignored. See WikiFormatting.

[marc@…]

What about

info

or

search

(can anybody see the search keyword? in the header above??)

How to avoid special processing here?

source

== info == 
or
== search ==  
(can anybody see the **search** keyword? in the header above??)

[Christian Boos]

Replying to marc@…:

What about [… anything some-id title that matches #<some-id> CSS rules …]

That's indeed a very unfortunate side-effect of the automatic creation of anchors out of section titles…

How to avoid special processing here?

An easy workaround is to change the id by specifying it explicitly, like in:

Wiki Markup	Display
== search == #search-topic	search

The real fix however would be to avoid having CSS rules relying on such common names. If we can get all the ids used in CSS rules to start with the trac- prefix, it would be easy to ensure that no generated anchor would ever clash.

See #8645 for further updates on this topic.

[anonymous]

Replying to cboos:

Replying to marc@…:

What about [… anything some-id title that matches #<some-id> CSS rules …]

That's indeed a very unfortunate side-effect of the automatic creation of anchors out of section titles…

How to avoid special processing here?

An easy workaround is to change the id by specifying it explicitly, like in:

Wiki Markup	Display
== search == #search-topic	search

The real fix however would be to avoid having CSS rules relying on such common names. If we can get all the ids used in CSS rules to start with the trac- prefix, it would be easy to ensure that no generated anchor would ever clash.

See #8645 for further updates on this topic.

WorksForMe! thx!

Gr. Marc