Last modified: 2014-09-03 12:03:31 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 T72198, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 70198 - Parser should wrap page sections (and lead section) in some containers with class or ID attributes
Parser should wrap page sections (and lead section) in some containers with c...
Status: RESOLVED DUPLICATE of bug 6104
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Unprioritized enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2014-08-30 00:01 UTC by natalie.bates
Modified: 2014-09-03 12:03 UTC (History)
5 users (show)

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


Description natalie.bates 2014-08-30 00:01:39 UTC
Common.css is a great, easy way for an average user to make big style changes: the learning curve for CSS isn't terribly steep. However, Common.css is limited by which elements MediaWiki, or a given skin, decide to enclose in containers or assign class or ID attributes. Unfortunately, many elements are currently unlabeled, and that makes styling those elements frustrating, if not frequently impossible.

For a few months now I have been editing Common.css and doing hours of Google searches, but I have continually run up against one big issue: there are no container divs for many MW elements. I have also continually come across dead-end threads where, over the years, people have tried to do the same thing I am looking to do, but ran up against the same issue.

This is not something the average user can fix on their own. I have moderate programming experience (C++ and Python) and I have determined that I would not only need to learn PHP and JavaScript, but I'd have to make sense of the actual MediaWiki files necessary as well: it is difficult to even figure out where the HTML is generated for a given element, much less to determine how to insert the divs or class/ID attributes. I've read evidence that plenty of people are in my position and have just given up on styling certain elements. Worse, I found a handful of threads where people abandoned MW altogether in favor of other solutions that were not so frustrating to style. I probably would have done the same thing if MW's organizational capabilities and extensions didn't suit my needs so well.

Here are the elements that I have identified could benefit from containers with class/ID attributes:

1) The lead article text needs its own containing div and ID. There is often no way whatsoever to select this text in CSS.

2) Section text needs its own containing div and class, so that one may style it independently of lead article text.

3) Each section and subsection needs its own containing div and class, which should include its header along with its text; classes like "h2-section" "h3-section" etc would suffice. 

For example, this would allow people to style all H4 subsections differently: its text could look different, it could have a different background, it could have borders that enclose the text and header together, etc.

4) The table of contents and the lead article text need to have a shared container div with an ID, so that one can style the top of the article independent of the sections. This also allows more precise positioning of the ToC relative to the lead article text.

4.1 - Googling has confirmed to me that lots of users do not like the default positioning of the ToC below the lead article text, and wish to instead position it to the left of the lead article text. The typical solution of adding float:left to #toc can produce problems depending on the rest of the styling, plus the ToC still comes after the lead article text. This means that users need to invoke the ToC magic word before the lead article text, but doing this on every page is tedious: this is why people want skins and extensions, after all, so they don't have to do this on every page.

4.2 - Assigning a containing div to the ToC and lead article text, along with the suggested lead article text container div, would get around the magic word problem: it allows one to make the ToC-and-lead-article div a flexbox, and then assign order:1 and order:2 to #toc and #leadtext (or whatever) respectively. This would position the ToC to the left ("before" the lead article text) without having to float it, without the order of the source code mattering, and without needing to invoke the magic word every page. 

As it stands, I have to get around this by invoking a template at the top of every page, which is unwieldy and tedious. But this solution is especially infeasible for most users: while I am the sole editor of my wiki, the whole point of most wikis is collaboration. I can't imagine the logistical nightmare of ensuring that users invoke and preserve a template solely to style the top of an article.

5) Similarly, I'm sure some users would love a container div/ID that encloses all the sections together, and excludes the lead article text and ToC. Off the top of my head, this would allow people to put the sections in columns, or grids, or whatever else they could think of, while leaving the ToC and lead text untouched. I have seen requests and questions all over the place where users want to style their wiki pages to look like newspaper or magazine layouts, and this would make that possible.

There are probably other labeled elements people would like to see, too, these are just the obvious needs I've run across.

I feel that implementing these changes would make MW more accessible, and greater customization would appeal to more users. MW is a great solution for a lot of projects that require organization or collaboration, but web design has advanced a lot and MW is held back relative to newer solutions when these elements cannot be styled. MW has good default skins, but even still, the design gets trapped in an antiquated state because of the level of technical prowess required to overcome these limitations listed here. Where people have the time, skill, and inclination to actually get into the PHP and JS to style those elements the results are fantastic, but currently that far exceeds the resources of most users. Most great designs that I see would be within the grasp of mere CSS, however, if only these elements were labeled.
Comment 1 Bartosz Dziewoński 2014-08-30 15:05:49 UTC
What you described is actually a non-trivial change to MediaWiki's parser. It's particularly problematic because MediaWiki lets you do very silly things like stuffing a heading inside a table cell, which completely destroys any attempts to add container divs. This would have to be handled somehow, and I have yet to see a good idea how (other than just not generating the containers in such cases).

It's also definitely a good idea, and you're not the first person to ask for it or experiment (one early installment of Brandon's Winter tech demo,, has implemented something along these lines in order to correlate the section edit links with the areas of the article that they correspond to). I definitely hope it happens one day, but it might take a while…
Comment 2 Bartosz Dziewoński 2014-09-03 12:03:31 UTC
There is an older bug about this, actually.

*** This bug has been marked as a duplicate of bug 6104 ***

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