Page MenuHomePhabricator

Some way to specify heading level for new sections
Closed, ResolvedPublic

Description

Author: lunasantin

Description:
When using the '+' new section button (or passing section=new to index.php) to
create new sections, I believe the new section is always a second-level heading
(first-level being the page title). It'd be handy if we could somehow specify a
different heading level for newly created sections (say, third-level). A magic
word would work, I guess, but even just being able to pass some value to
index.php would be great.


Version: unspecified
Severity: normal

Details

Reference
bz9426

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:41 PM
bzimport set Reference to bz9426.
bzimport added a subscriber: Unknown Object (MLST).

I believe the intend was to have the ability to set the header level anytime user uses + link to add new section.

I can imagine it like:

Level: [Dropdown h1-h6]

Subject/header: ___________________________________________

[textarea for content]

However the r25396 patch is also useful and should remain as well.

robchur wrote:

(In reply to comment #1)

Fixed in r25396.

Don't think I like the idea of abusing a message for this purpose...

t.laqua wrote:

(In reply to comment #3)

(In reply to comment #1)

Fixed in r25396.

Don't think I like the idea of abusing a message for this purpose...

How is it message abuse? Where else should a global setting be stored? The reasoning behind it was that the H2 heading (==...==) was hardcoded and should be "customizable" - and that felt like a job for a system message to me. I have qualms with the "dropdown" idea as it allows users to choose, which might not be desired behavior (I certainly don't need my users creating H6 headings all over the place). In the event that a dropdown was added, I would personally need a $wgAllowUserSpecifiedNewSectionHeadingLevel global or some such thing to turn it off.

I would argue that section additions need to be consistent (i.e. no user customization) otherwise the TOC will be all wonked out with unintended sub-sections when all the user wanted to do was leave a "new" section - the dropdown will just confuse people.

Not having it as a system message would make it difficult to customize.

Where else should a global setting be stored?

Shouldn't it go in something like $wgEditSummaryHeadingLevel?

I don't think a drop-down would be useful, but maybe people would like a [+] next to section [edit] links on talk pages (settable in preferences?) that would create a new section with a heading level one below that of the parent section (for a discussion subtopic, which seems like the only place the drop-down would be useful).

t.laqua wrote:

(In reply to comment #5)

Where else should a global setting be stored?

Shouldn't it go in something like $wgEditSummaryHeadingLevel?
I don't think a drop-down would be useful, but maybe people would like a [+]
next to section [edit] links on talk pages (settable in preferences?) that
would create a new section with a heading level one below that of the parent
section (for a discussion subtopic, which seems like the only place the
drop-down would be useful).

Interesting idea - but it's straying from this particular bug's scope. Can we close this one out and start a new thread for investigating your suggestion?

(In reply to comment #6)

(In reply to comment #5)

Where else should a global setting be stored?

Shouldn't it go in something like $wgEditSummaryHeadingLevel?
I don't think a drop-down would be useful, but maybe people would like a [+]
next to section [edit] links on talk pages (settable in preferences?) that
would create a new section with a heading level one below that of the parent
section (for a discussion subtopic, which seems like the only place the
drop-down would be useful).

Interesting idea - but it's straying from this particular bug's scope. Can we
close this one out and start a new thread for investigating your suggestion?

Ok, I've created Bug #12115 for subtopic headings. I still think a configuration setting would be more appropriate than a system message for this bug, however.

t.laqua wrote:

Why? That moves the setting outside of wiki\sysop permissions and moves it in to filesystem realm. It doesn't make sense.

Things like default user options, which this reminded me of, go in the configuration, but I see your point.

  • Bug 12115 has been marked as a duplicate of this bug. ***