https://bugzilla.wikimedia.org/show_bug.cgi?id=70198
Bug ID: 70198
Summary: Several elements cannot be selected by CSS and should
have container divs with class or ID attributes.
Product: MediaWiki
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: Unprioritized
Component: Skin and page rendering
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected]
Web browser: ---
Mobile Platform: ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
