Author: natalie.bates

Description:
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.

Version: unspecified
Severity: enhancement