| At line 1 changed one line |
| [BrionVibber] noted at the WMS Workshop that Wikipedia starts its headings with two equals signs because the page title itself is considered as the top level heading. I find this a useful assumption. Our LaTex converter for JSPWiki makes the same assumption, combining different Wikipages as chapters using the page titles. |
| [BrionVibber] noted at the WMS Workshop that Wikipedia starts its headings with two equals signs because the page title itself is considered as the top level heading. I find this a useful assumption. Our LaTeX converter for JSPWiki makes the same assumption, combining different Wikipages as chapters using the page titles. |
| At line 151 added 69 lines |
|
| I don't understand this discussion. Creole just says that you need at least two equal signs to make a heading -- this is consistent with "at least two characters for markup" informal rule. How you translate it to HTML is dependent on the engine used -- some engines have the <h1> tag reserved for page titles, others don't, some might even lack headings at all -- and use <div class="heading"> or even (please forgive me) <b>. The same wiki engine might even render headings differently depending whether the page title is present (in normal view) or not (in print view). |
| Note that (X)HTML in the examples is just **suggested** markup. I think that there is really not much to argue here. |
| -- [RadomirDopieralski], 2006-12-11 |
|
| I must disagree with you Randomir about the number of = signs. One of the unofficial [Goals] states that elements should start with one characters, adding more when required. |
|
| Also, a quick survey of Headings on [WikiMatrix] gives the following results amongst Wiki engines that allow multiple headings in one way or another : |
|
| # Starts at 1 (or with one charater): 68% |
| # Starts at 2 (or with two characters): 19% |
| # Headings in reverse : 13% |
|
| IMHO, headings should start at level 1 with 1 equal sign. Martin has some very convincing arguments. |
|
| However, I completely agree with you about the implementation. The rendering should be left to the engine. I put a note on my personal page about what the specs should do we the X(HTML) suggestion. |
|
| -- [EricChartre], 2006-12-28 |
|
|
| ------------- |
|
| Why in the world would you disallow links in headings? This is commonly done on a good many wikis, and there are many good reasons to do it, such as when there is already a good article on a topic and you just want to summarize the article. A link in such a heading is a succinct way to say "this is not the authoritative statement on this topic, if you want that, click on this here link in the header; if you keep reading beyond this point, be aware it's just a summary". You really want to put three-liners in italics like that on all those paragraphs? |
|
| Also why not support the tikiwiki show/hide convention +/- as part of headings? So ===- means "third level heading, show this hidden by default", and ===+ means "no matter whether this was open or closed last time, show it open every time". |
|
| If you have ANY show/hide convention at all, the use of links in headings is even more important: they avoid having to open up a section to link to another page where the matter is dealt with in more detail. |
|
| Another case where links in headings are very desirable is when summarizing the responses per person or group. In that case, the [[table of contents]] should have links in it if only to avoid some other manually maintained list of same, or absurd show/hide digging to find all the signatures or attributions. If there's a single place for all comments by Ed Jones, I want === [[Ed Jones]] === as that section title. |
|
| In a wiki, links should go literally everywhere in everything. It's also absurd to disallow links in [[edit summary]]/change note where they are essential, e.g. to link to a policy being enforced or another page being referred or a user involved. |
|
| All that said, the worst problem with mediawiki format is solved by this proposal which is the need to balance the = signs. Supporting it in this backward compatible way is probably the best solution that could be achieved. Mediawiki has awesome data weight and the less one departs from it the better, usually. |
|
| As for level one headings, they are disallowed and discouraged for many good reasons, one of which (hinted at above by Martin) is that using them prevents re-use of page content as part of some other document with a different title or level one heading. It's quite dodgy and dangerous to indent everything an extra level when you want to grab a whole page and include it in another document, so having page sections always start at the highest sub-heading (not the main heading or title) is wise. This may be one of the reasons for Wikipedia's success, as there are so many teenagers cribbing from it for essays - which of course have different titles than the articles, but which can contain all the text nabbed from those. So disallowing level 1 is probably not out of the question but using it shouldn't be encouraged either. It may be best to say flatly that this is the "alternate title" or "subtitle" or "extended page name" rather than the "main heading", so it is clear that it may interact with the title of the page in very specific ways. For instance, totally disappearing if the page is imported/embedded into another wiki page, or an XML page, with a different title than the original. This would be very desirable behaviour in a number of circumstances, not least of which would be the essay-inclusion case. |
|
| -- Anonymous, 2007-02-05 |
|
| Just for the record, I remember there was some exotic wiki engine with a pretty neat solution for the //adding a heading above or below problem//. Both with the approach we use, and the reversed one, it's hard to add headings -- on lower or higher level. |
|
| The syntax was very similar to that of structured text -- it used headings of different levels underlined with various punctuation characters, like "{{{-+*@#%~^:}}}". The point is, there was no static mapping between the heading level and the character used. The first heading was automatically made into {{{<h1>}}}, and then all the headings underlined with the same character were also rendered as {{{<h1>}}}. The next //differing// heading was made into {{{<h2>}}} and so on. Then, if you wanted to add a heading of higher/lower level than used already, you just used a new underlining character. |
|
| Apart from this smart advantage, this approach has also severe disadvantages. Two texts coudn't be easily merged together without getting through them and standarizing the heading markup. You coudn't tell what level of heading you're looking at without scrolling the textarea to the beginning and looking through all the source. |
|
| That's why I don't recommend it for Creole. But the solution is still an interesting one. I tested something similar for bullet lists and it worked pretty nice. |
|
| -- RadomirDopieralski, 2007-02-05 |
|
| Its interesting that XHTML 2.0 has the {{{ <section> }}} and {{{ <h> }}} elements which solves this problem neatly. Just unfortunate it was added too late. |
|
| -- JaredWilliams, 2007-02-05 |
|
| You can always approximate it with the wiki script and apropriate {{{<div>}}} and {{{<span>}}} elements. For example, when writing HTML I like to write: |
|
| {{{ |
| <div class="section"> |
| <h1>Heading</h1> |
| <p>The text of the section...</p> |
| ... |
| </div> |
| }}} |
|
| Remember, that your script can "guess" what level of headings to use very easily -- provided you have beginning and ending tags for the sections, like in XML. Unfortunately, Creole only has markup for the beginning of section, and the ending has to be computed based on the level of heading used. But it seems more human-friendly. |
|
| -- RadomirDopieralski, 2007-02-06 |
|
| Yes, could use the list style logic for headers. Still would have to fix up h//n// elements thou. |
|
| -- JaredWilliams, 2007-02-06 |
.