Last modified: 2011-03-13 18:05:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3257, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1257 - allow sections to be collapsible, like table of contents
allow sections to be collapsible, like table of contents
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Lowest enhancement with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
: 3560 4326 5826 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-04 05:55 UTC by Ian Monroe
Modified: 2011-03-13 18:05 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
allows creation of headers that are collasped until clicked on (4.33 KB, patch)
2005-01-05 09:09 UTC, Ian Monroe
Details
More comprehensive user requirement/suggestion, justification document (15.15 KB, text/html)
2006-05-04 23:04 UTC, Richardb
Details

Description Ian Monroe 2005-01-04 05:55:20 UTC
On Wiktionary there is some content, such as quotations, that would be nice to
remain hidden until the user chooses to see it; otherwise they could easily
dominate the page. It would encourage people to add quotations to pages.
Currently some users are making seperate Quotation pages, which might make pages
harder to maintain in the future.

Here's a suggested syntax:
===-Quotations-===

It would then have the same [show]/[hide] link as the table of contents. <div>
tags could be used instead of the <table> used by the TOC. 
A pretty neat way of doing it:
http://www.evolt.org/article/Collapsible_page_elements_with_DOM/17/45831/
Comment 1 Ian Monroe 2005-01-05 09:09:36 UTC
Created attachment 198 [details]
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.
Comment 2 Ævar Arnfjörð Bjarmason 2005-07-11 00:08:45 UTC
(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.
Comment 3 lɛʁi לערי ריינהארט 2005-10-02 08:55:35 UTC
please compare with

bug 3560: lengthy sections should have the option to hide/show (collapsable)
Comment 4 Ævar Arnfjörð Bjarmason 2005-10-02 21:41:55 UTC
*** Bug 3560 has been marked as a duplicate of this bug. ***
Comment 5 Zigger 2005-12-28 00:26:01 UTC
*** Bug 4326 has been marked as a duplicate of this bug. ***
Comment 6 Filip Maljkovic [Dungodung] 2005-12-30 15:12:46 UTC
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 . [...]
Comment 7 Kristin 2006-01-03 19:07:43 UTC
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...
Comment 8 Ian Monroe 2006-01-04 05:10:44 UTC
That doesn't sound like a major issue to fix.

I just like my syntax better. :P
Comment 9 Brion Vibber 2006-05-04 19:00:40 UTC
*** Bug 5826 has been marked as a duplicate of this bug. ***
Comment 10 Richardb 2006-05-04 22:50:49 UTC
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 ?
Comment 11 Richardb 2006-05-04 23:04:50 UTC
Created attachment 1654 [details]
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.
Comment 12 Brion Vibber 2006-05-05 01:45:47 UTC
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.
Comment 13 Zoran Obradovic 2006-05-05 02:01:18 UTC
Collapsable text can already be done through css, at least on en.wikipedia.
Maybe you need to copy some css and construct a template?
Comment 14 Ian Monroe 2006-05-05 17:53:37 UTC
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...
Comment 15 Richardb 2006-05-30 00:42:51 UTC
"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 ????
Comment 16 Rob Church 2006-05-30 00:50:02 UTC
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.
Comment 17 Ian Monroe 2006-06-04 13:49:01 UTC
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. ;)
Comment 18 Richardb 2006-06-11 03:09:52 UTC
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
Comment 19 Andrew Dunbar 2006-06-11 13:34:09 UTC
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.
Comment 20 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-05 04:58:34 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links