wikipedia wrote:

allows creation of headers that are collasped until clicked on

This patch is more of a proof of concept then a proper patch. It does do what
it says it does, it adds my suggested syntax though it doesn't implement the
nice [show]/[hide] of the TOC.

attachment collasible_headers.patch ignored as obsolete

avarab wrote:

(In reply to comment #1)

Created an attachment (id=198) [edit]
allows creation of headers that are collasped until clicked on

Please supply a unified (-u) patch.

gangleri wrote:

please compare with

bug 3560: lengthy sections should have the option to hide/show (collapsable)

avarab wrote:

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

zigger wrote:

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

Pasting from Bug 4326 comment #1:

A friend of mine is working on an extension that might interest you. See
http://meta.wikimedia.org/wiki/ShowHide_Extension and
http://crash.vikimedija.org/index.php/ShowHide . [...]

bkwyrm wrote:

The extension has one major issue in that it will not allow hidden sections to
show up in "printable versions" on either my (sorry, intranet) site running 1.5
or on the example site listed above...

wikipedia wrote:

That doesn't sound like a major issue to fix.

I just like my syntax better. :P

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

rb_wiki wrote:

This would be a MAJOR ENHANCEMENT to the useability of Wikipedia and Wiktionary.
And it would go a long way to resolving the differences/ ongoing battles between
inclusionists and deletionists. (Deletionists would see as little as they want to
see, inclusionists would see as much as they want to see.

I will attach a much more compreensive user statement of how it can be
implemented, and the benefits.

So, how do we get this escalated for some real action ?

rb_wiki wrote:

More comprehensive user requirement/suggestion, justification document

There is more value to this than meets the eye on the simple requests so far.
Could be a major improvement to the user experience, and resolve some raging
battles. Yet probably easy to implement.

User Requirement/Suggestion & Justification document.

Attached:

No, this wouldn't have anything at all to do with inclusionism/deletionism.

Collapsable sections are inaccessible, and useless for printed
and other such forms of pages. Going to WONTFIX this.

zocky wrote:

Collapsable text can already be done through css, at least on en.wikipedia.
Maybe you need to copy some css and construct a template?

wikipedia wrote:

Richard's idea was way too complicated. No one is going to understand what some
numbers at the top of the page mean.

As far as inaccessibility, it should really only be used when the alternative is
to create subpages - those are even more inaccessible.

On printed pages, obviously it would just print everything...

rb_wiki wrote:

"No, this wouldn't have anything at all to do with inclusionism/deletionism."
Collapsible sections WOULD GO a long way to resolving inclusionism/deletionism
disputes.

WONT FIX implies it was a bug report. It was an improvment suggestion, based on
many years of intervening between tech heads who suggest technical solutions like
using personal CSS, and real world users.

I do not accept this verdict by one single techhead, against 6 votes for it.

If it doesn't fit into a Bug fix system, then where are serious suggestions for
improvment to be put. Or don't we have such a system ????

robchur wrote:

Both bug reports and feature requests for MediaWiki are placed on this tracker.
We tend to use WONTFIX in the case of feature requests which we aren't planning
on implementing for one or more reasons, and INVALID to close false bug reports.

To start long-term discussion, you are welcome to use one of the many mailing
lists to bolster support for the idea, provide a convincing argument that it
would be useful, and suggest a decent means of implementation which works for
more than just the users with JavaScript enabled.

Please be aware that features in MediaWiki come about via a concensus of the
active developers, with our lead developer Brion having the final statement over
what does and doesn't happen. We don't often count votes as it is our experience
some users don't understand what is best for them.

For what it is worth, I too am opposed to the idea of hiding bits of
information, making reading documents complex where there is no clear need...I
am against a technical solution to a social dispute between several classes of
users, some of whom are misguided.

I won't close the bug WONTFIX, but don't be surprised if someone else does. And
please don't war over it in that case.

wikipedia wrote:

A soluion for the small number of users without
javascript is not necesary, they can see everything, no
big deal. And this should be seen as alternative to
subpages, doesn't have much to do with inclusionism etc.

The status of a ticket really isn't that important from
my experience with other projects, no reason for
bugzilla-drama. ;)

rb_wiki wrote:

As an experienced senior business systems analyst, with 28 years in the IT industry,
starting as a technical programmer, but for the last 20 years mainly being the go-
between to interpret user needs to IT techos, I've got to say I'd back my own
opinion. All that you've done is make this user further lose faith in the developer
community as just a bunch of ego techos who just don't understand the users, even
when they put together a user requirement document.

So, what do you developers really understand about the inclusionist/deletionist
debate, and what kind of solutions are you working on in this area. By all means, let
me know where you conduct these discussions. Of course, I'm assuming that if you want
users to contribute, it will be in a place that doesn't take technical expertise to
take part. Is that too big an assumption ??

Seriously,I want to help bring the user perspective to the developer community in a
better way, since so many technical solutions are being offered, instead of real user
friendly ones.

Contact me on rb_wikitech@boult.mailshell.com

I've been thinking about this same problem for a long time. For my solution, the
key is Bug 6104, which would include CSS classes for all sections and
sub-sections. Site CSS, user CSS, and with some enhancements, user preferences
would then be able to choose which sections are visible or hidden by default
quite easily.

The feature is held up by complex markup on Wikipedias that Wiktionaries do not
suffer from. Somebody could implement a simple solution now for Wiktionaries
which would be disabled on Wikipedia until a full Wikipedia-compatible solution
can be developed.

ayg wrote:

Patch is far too old to be applied and has serious flaws (extension of wikimarkup, breaking reverse compatibility, breaking XHTML validity) for a feature of such questionable worth. The typical use case of MediaWiki is for article-style pages, where this feature would not be useful and would just clutter the interface. It would be perfectly reasonable as a custom script if desired, but not part of the core software. If the core needs flexibility increased in some way to enable this (e.g. bug 6104), please open separate bugs. WONTFIX.

Personal JS for those interested in such functionality

var headings = $(':not(#toctitle):not(#mw-navigation) > h2');
$(headings).each(function (i, heading) {
	var $sectionContents = $(heading).nextUntil('h2');
	if (i === $(headings).length - 1) {
		$sectionContents = $(heading).nextUntil('#catlinks');
	}
	$sectionContents.css('display', 'none');
	$(heading).find('.mw-editsection').css('display', 'none');
	$(heading).find('.mw-headline')
		.prepend('<span class="dropdown-icon">▾ </span><span class="dropdown-icon" style="display:none;">▴ </span>')
		.click(function () {
			$(heading).find('.mw-editsection, .dropdown-icon').add($sectionContents).toggle();
    	});
});