Provide a way to set page meta-data flags ("featured article", "protected", etc.), configure which ones are available for a wiki, and display icons indicating these statuses
Closed, ResolvedPublic

Description

Currently, the icons in the top-right of an article (e.g. the "featured article" star, the page protection lock, etc) are placed there via CSS absolute positioning. This leads to quirky rendering bugs that cause these elements to render in unfortunate places. Here is one example that works as of this writing:

http://flaggedrevs.labs.wikimedia.org/wiki/Backmasking?useskin=monobook

What we'd like is a standard place to put them in the html, along with a standard mechanism for extensions and page templates to be able to add new icons, so we can use more reliable CSS features to position them sensibly.


Version: unspecified
Severity: enhancement

Details

Reference
bz23796
bzimport raised the priority of this task from to Low.
bzimport set Reference to bz23796.
RobLa created this task.Jun 4 2010, 7:32 PM

FYI, the (rough) implemention on zhwiki: [[zh:Template:Topicon]] and [[zh:MediaWiki:Common.js]] (search for "topicon).

demon added a comment.Jun 8 2010, 4:09 PM

Created attachment 7439
Partial implementation

I've implemented the Parser/OutputPage/SkinTemplate portions of this code.

Format is like this:
{{#pageicon:File1.ext|Alt text}}

Or like this:
{{#pageicon:File2.ext|Message-key-for-some-alt-text}}

You can use it multiple times in a page to allow for multiple icons like FA, page protection, etc. Still needs some loving to put it somewhere acceptable in the UI with the right styling though.

attachment mydiff.patch ignored as obsolete

(In reply to comment #3)

Created an attachment (id=7439) [details]
Partial implementation

I've implemented the Parser/OutputPage/SkinTemplate portions of this code.

Format is like this:
{{#pageicon:File1.ext|Alt text}}

Or like this:
{{#pageicon:File2.ext|Message-key-for-some-alt-text}}

You can use it multiple times in a page to allow for multiple icons like FA,
page protection, etc. Still needs some loving to put it somewhere acceptable in
the UI with the right styling though.

Looks good, now we just need a place to put it and slap some CSS on it.

Could we put it where en.wiki already has them, On the right edge of the title line (example: http://en.wikipedia.org/wiki/Cheese)? Although that might cause issues with templates that place them.

happy.melon.wiki wrote:

The if-a-system-message-exists-with-that-name-use-that implementation used in Sidebar is horrible; definitely not a good idea to extend its use any further. If people want to add a translatable message, they should use {{int:...}}.

I'd rather see this implemented either as full image syntax, or as full wikitext. Supporting only 16px icons with no click-through doesn't actually solve the original problem, which was how to position the FlaggedRevs widget, as well as being useless for most of the things wikis use the icons for. On the other hand, I *do* like the backend implementation via ParserOutput.

demon added a comment.Jun 21 2010, 2:26 PM

(In reply to comment #6)

The if-a-system-message-exists-with-that-name-use-that implementation used in
Sidebar is horrible; definitely not a good idea to extend its use any further.
If people want to add a translatable message, they should use {{int:...}}.

Fair enough.

I'd rather see this implemented either as full image syntax, or as full
wikitext. Supporting only 16px icons with no click-through doesn't actually
solve the original problem, which was how to position the FlaggedRevs widget,
as well as being useless for most of the things wikis use the icons for.

I thought about that. I just didn't get to it. Opening up more of the image syntax (including linking) is a good idea IMO. However, I'm a bit leery of opening up all wikitext. This pfunc is designed for putting little clickable things in the upper right corner of articles, and I'm afraid what opening up the syntax might encourage.

On
the other hand, I *do* like the backend implementation via ParserOutput.

At least I did something right :)

happy.melon.wiki wrote:

(In reply to comment #7)

(In reply to comment #6)
> I'd rather see this implemented either as full image syntax, or as full
> wikitext. Supporting only 16px icons with no click-through doesn't actually
> solve the original problem, which was how to position the FlaggedRevs widget,
> as well as being useless for most of the things wikis use the icons for.

I thought about that. I just didn't get to it. Opening up more of the image
syntax (including linking) is a good idea IMO. However, I'm a bit leery of
opening up all wikitext. This pfunc is designed for putting little clickable
things in the upper right corner of articles, and I'm afraid what opening up
the syntax might encourage.

I agree it needs caution. I think the main step is storing processed HTML in the ParserOutput array; that way extensions can add whatever they like to it (plus it's a bit wierd that what comes out of the 'parser' is not actually *parsed* :D). What we allow people to add directly from wikitext is a separate question.

> On the other hand, I *do* like the backend implementation via ParserOutput.

At least I did something right :)

:D

a.d.bergi wrote:

Also HTML should be parsed. Many Icons and even messages use their own div, span, small or whatever whith individual ids oder classes, which are needed for the stylesheets. For an example look at [[:de:template:Shortcut]]. Links, and imagemaps or pictures-in-links, are a must. Otherwise this very useful extensions imho wouldn't be used.

Strong abuse by users could be prevented by using some CSS, like (max-)width and heigth, and the very useful overflow:hidden.

demon added a comment.Jun 28 2010, 5:52 PM

I'm looking at this some more, and adding full wikitext isn't hard. But I think in doing that the name "pageicon" becomes less descriptive of a parserfunction name.

Is there some general term we can come up with for "little clickable things in the upper right corner?"

(In reply to comment #10)

I'm looking at this some more, and adding full wikitext isn't hard. But I think
in doing that the name "pageicon" becomes less descriptive of a parserfunction
name.

Is there some general term we can come up with for "little clickable things in
the upper right corner?"

Think of the RTL children.

"topicon" seems like a fine choice, though I don't really see an issue with "pageicon".

Created attachment 7531
Partial implementation #2

Redid this with support instead for full wikitext. Still needs proper placement in skin files (under firstHeading?) and CSS ninja-ing.

Attached:

Positioning such icons (so that they work in all popular skins, of course, as users naturally expect) has so far been a very common, time-consuming (and rather silly) job of local administrators – see the list of interwiki links in [[Template:Top icon]]. Quite a lot of them, especially on smaller wikis, don't work correctly (or not at all).

The implementations are very different. Most wikis use position:absolute, but the French, German and Chinese Wikipedias use float:right together with a little script that moves the icons just before #firstHeading (see [[fr:MediaWiki:Common.js]], [[de:MediaWiki:Vector.js]] and [[zh:MediaWiki:Common.js]]).

While I would prefer having them just after #firstHeading semantic-wise, putting them before #firstHeading and floating them right (like editsection links) solves all the positioning problems in a simple, easily-maintainable way. See [[de:Wikipedia:Bewertungsbausteine]] using Vector for how it looks.

Ah, and there are also the coordinates that, for whatever reason, like to be positioned near the title in many wikis.

we need a css ninja, cc'ing trevor (blame reedy).

I'm very much in support of placing a div that can contain 1 - 5 (please not more than 3, but let's be realistic) 20x20px icons, and adding a parser hook to append images with links and titles to it.

However, we need to consider the transition from the old way to the new way - because if we place this div in essentially the same place as the old ones, the old ones with either be obscured or overlayed, either way that sucks.

How consistent is the templating to get these icons up there? If we could first hack together a template that all icons at the top use (if no single template exists already, than replacing the template with software would be simple.

Feedback on this idea would be helpful - I'm mostly just thinking out loud here.

demon added a comment.Sep 21 2010, 6:47 PM

(In reply to comment #15)

How consistent is the templating to get these icons up there?

I think comment #13 has your answer:

(In reply to comment #13)

The implementations are very different. Most wikis use position:absolute, but
the French, German and Chinese Wikipedias use float:right together with a
little script that moves the icons just before #firstHeading (see
[[fr:MediaWiki:Common.js]], [[de:MediaWiki:Vector.js]] and
[[zh:MediaWiki:Common.js]]).

a.d.bergi wrote:

It's not just about icons, [[de:Kategorie:Vorlage:mit absoluter Positionierung]] (templates with absolute positioning) gives you a short overview what could be placed in the same corner, concurrently.
@ comment #15: I dont think there would be a problem with overlaying icons, it's just a few templates to edit from the old syntax to <topicon> (or better <toptext>).

ayg wrote:

(In reply to comment #15)

However, we need to consider the transition from the old way to the new way -
because if we place this div in essentially the same place as the old ones, the
old ones with either be obscured or overlayed, either way that sucks.

I don't think this is a big deal. Any given wiki probably only has a few widely-used templates that do this effect, and they can all be changed simultaneously to the new system. If there are any less widely-used templates that do it, it's okay if they break for a little while until someone notices and fixes them. It should be incredibly easy to port templates to the new system -- replace the whole mess of CSS/JS/voodoo magic with one parser function call giving the image name.

(In reply to comment #17)

It's not just about icons

I would like to see a system with firm boundaries and clear purpose put in place, so that each skin can predictably place these icons with some reasonable assumptions about their size and quantity. Allowing arbitrary HTML would over-complicate the situation in my opinion. What are the serious use-cases for placing something other than an icon in this location? Is that really the best place for that content, or is that just a place that was chosen arbitrarily? However, if there is a reasonable use-case, then I think we should support it.

(In reply to comment #18)

I don't think this is a big deal

I'm not suggesting it's impossible or even hard to transition, I'm suggesting a transition strategy. I think you are right that the transition is pretty feesable.

I'm going to stop talking and start hacking something up.

What are the serious use-cases for
placing something other than an icon in this location?

GPS coordinates maybe. Although enwiki seems to place them slightly lower - ex: http://en.wikipedia.org/wiki/Toronto

(In reply to comment #15)

I'm very much in support of placing a div that can contain 1 - 5 (please not
more than 3, but let's be realistic) 20x20px icons, and adding a parser hook to
append images with links and titles to it.

We shouldn't really limit the number like that, on articles that may be fine but people do use them else where, for example on en.wiki they are/can used to symbolize user rights (the mop, rollbacker, crat etc) or other things (Eg: [[User:Daniel]] uses ~24 icons to denote things.

(In reply to comment #21)

[[User:Daniel]] uses ~24 icons to denote things.

And this is good why?

I'm nearly done with my first revision of this thing, and I have yet to place limitations on it.

If I do add limitations it would only be for initial view, and by expanding it a cookie would be set and it would display expanded from there on out until you collapsed it. Something like that would server both purposes.

Jorm added a comment.Sep 21 2010, 11:47 PM

I think having more than 5 icons would be asking for a super duper amount of trouble, and I don't think that having an expando on it will help solve for bloat.

We expando everything. Too much, imo. No; the only way to restrict bloat is to put a hard limit on the size that can be displayed.

How about r73498 - a new extension called ArticleEmblems. It collects the contents of <emblem>...</emblem> tags and adds them to a list rendered at the top of the page.

(In reply to comment #24)

How about r73498 - a new extension called ArticleEmblems. It collects the
contents of <emblem>...</emblem> tags and adds them to a list rendered at the
top of the page.

Magic words and other variables like that generally aren't available to XML-style tags, so <emblem>{{PAGENAME}}</emblem> will probably fail. This can be worked around with {{#tag:emblem|{{PAGENAME}}}} I suppose, but it might be better to implement as {{#emblem:}} from the outset (similar to the {{#pageicon:}} proposal above).

I suppose I should probably go install the new extension and test it out before commenting further. :-)

(In reply to comment #25)

Magic words and other variables like that generally aren't available to
XML-style tags, so <emblem>{{PAGENAME}}</emblem> will probably fail. This can
be worked around with {{#tag:emblem|{{PAGENAME}}}} I suppose, but it might be
better to implement as {{#emblem:}} from the outset (similar to the
{{#pageicon:}} proposal above).

Oh, bug 2257 (about XML-style tags and extensions) was fixed awhile ago. Hot damn. :D

I tested this new extension on localhost. It seems to work pretty well, though it's not purging the page cache when a template is changed. I'll leave a detailed comment at r73498.

Some figures from dewiki: We currently have 10 templates that generate icons, but they are rarely combined. The vast majority of our 1125000 articles (99.5%) has no icons. 5762 articles have 1 icon, 121 articles have 2 icons, and I'm not aware of any situation where an article could have 3 or more icons.

We also have 11 templates that create text elements; the most used is the coordinates template with nearly 200000 transclusions (18% of all articles). The text can be rather long because Swiss towns have their coordinates in WGS84 and the Swiss national format (therefore the tiny font size of 10px), and they can also occur together with icons (see e.g. [[de:Tägermoos]]). The text templates are deliberately made so that no more than 1 can be used on a page (they would overlap).

I'm a little worried about the order in which the items appear in the wikitext becoming significant. That's fine for icons, but it may be desired to differentiate between icons and text elements. At dewiki, in most cases the coordinates are transcluded from and infobox the top of the article that can't be moved. Similarly, the icons are transcluded from a template at the bottom of the article that can't be moved either.

Seems like we could add a feature to article emblems that would allow overriding of the order on a case-by-case basis, the default being in the order they appear.

TheDJ added a comment.Sep 24 2010, 1:16 PM

Might be an idea to add a hook, to directly add emblems from the software in some way? Or am I overlooking that functionality?

demon added a comment.Sep 24 2010, 1:23 PM

(In reply to comment #29)

Might be an idea to add a hook, to directly add emblems from the software in
some way? Or am I overlooking that functionality?

That's why I put it in core, with easily accessible methods from OutputPage, so things already hooking into the output page could add extra icons

(That was the motivation for this originally anyway...we wanted to move the FlaggedRevs box up there)

Nux added a comment.Sep 29 2010, 8:01 AM

(In reply to comment #28)

Seems like we could add a feature to article emblems that would allow
overriding of the order on a case-by-case basis, the default being in the order
they appear.

The problem with this is that there are other elements that must be sort-in with javascript, but I guess it would simplify existing scripts anyway.

To see what I mean have a look at:
http://pl.wikipedia.org/w/index.php?title=MediaWiki:HeadingIcons.js

We put in header and sort:

  • editsection - 0-section edit link added basically when articles are long
  • padlock - added for locked articles
  • (anything other goes here)
  • coordinates
  • shortcut_upper - WP:FP and such

An over exaggerated example is here:
http://pl.wikipedia.org/wiki/User:Beau/brudnopis

Note that in practice only one of icons on the right side of coords can exist in one article.

Anyway I don't think a 0-section link and padlock can be added with a template... Or maybe it could?

The 0-section edit link shouldn't be added with a parser function, since you would presumably want that on all pages [or some namespaces].

The padlock /could/ be added with this, just as it is done now. Although perhaps some auto-magic could be used to automatically show it on protected articles.

BTW, we should allow to add templates on the protecting action.

Bryan.TongMinh wrote:

Just had a look at the extension. Any reason why you are creating your own table, instead of using page_props? That one is specifically meant for parser-added properties.

(In reply to comment #33)

Just had a look at the extension. Any reason why you are creating your own
table, instead of using page_props? That one is specifically meant for
parser-added properties.

This is discussed here: r73498#c9500

See http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73498#c9500

What you are saying has been suggested. However, "since page_props has a unique key on the page and name columns, I would have to be packing all emblems into a JSON blob or something to make use of it - something I have mixed feelings about."

To elaborate on mixed feelings (for using page_props)

For: Fewer moving parts == Less complexity == good
Against: Packing data into a single page_prop row would make the data nearly un-query-able.
For: The data isn't really very query-able anyways, and packing it would probably be more performant.
Against: Maybe the data should be more queryable, such as requiring the emblem to be a template call or something, not just arbitrary wikitext

So - yeah, please feel free to weigh in, or just change the code, it's open source after all - I would welcome contribution and have no firm position on this matter.

You are just storing html there. So I think it makes more sense to store it in page_props now. We can always add a new table later if needed.

Heh, the was badly named... ^_^ this is actually a dup...

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

(In reply to comment #38)

  • This bug has been marked as a duplicate of bug 12548 ***

You should have duped the other bug, since this one has more useful discussion on it.

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

Tim did a review of the ArticleEmblems extension at http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73498#c15365. Current status is that the extension needs to be rewritten, but there are no interested developers.

Re-written might be an overstatement, but clearly he's made a reasonable case for storing emblem data differently including using the page props system.

I wouldn't say no-one's interested. I am, but I've been to busy. I actually have page icons on the roadmap for skin rewriting, since as far as I'm concerned, they're part of skinning. However it's at a post-template-language implementation point. I want to take advantage of the xml/html based template language's ability to usage detect. ie: If you omit the page icons' marker it'll automatically inject it into the page title's content so that it still shows up.

demon added a comment.Nov 7 2011, 10:42 PM

Removing need-review from my own patch.

sumanah wrote:

+design, +reviewed

(In reply to comment #0)

What we'd like is a standard place to put them in the html, along with a
standard mechanism for extensions and page templates to be able to add new
icons, so we can use more reliable CSS features to position them sensibly.

This could also potentially be used for core features, such as protection. These currently use templates on some wikis, but it would make sense in core.

This feels like the main piece here is the meta-data setting for articles, and the display part is secondary. Moving to "Page editing".

(In reply to James Forrester from comment #47)

This feels like the main piece here is the meta-data setting for articles,
and the display part is secondary.

Really? I thought the opposite. Data is already available, currently in the form of templates and local scripts; the problem is how to output it in a non-conflicting way.

(In reply to Nemo from comment #48)

(In reply to James Forrester from comment #47)
> This feels like the main piece here is the meta-data setting for articles,
> and the display part is secondary.

Really? I thought the opposite. Data is already available, currently in the
form of templates and local scripts; the problem is how to output it in a
non-conflicting way.

That's not "data", that's random wikitext that's not machine-extractable.

(In reply to James Forrester from comment #49)

That's not "data", that's random wikitext that's not machine-extractable.

That's not an opposition.
How data machine readability help with the original objective of this bug, that is:

(Rob Lanphier (RobLa) from comment #0)

quirky rendering bugs that cause these
elements to render in unfortunate places.

[...] What we'd like is a standard place to put them in the html, along with a
standard mechanism for extensions and page templates to be able to add new
icons, so we can use more reliable CSS features to position them sensibly.

I'm going to work on this some time this week. *sinister rumble*

Change 162609 had a related patch set uploaded by Bartosz Dziewoński:
Implement page status indicators

https://gerrit.wikimedia.org/r/162609

Change 162610 had a related patch set uploaded by Bartosz Dziewoński:
Add support for page status indicators

https://gerrit.wikimedia.org/r/162610

Change 163558 had a related patch set uploaded by Bartosz Dziewoński:
Add support for page status indicators

https://gerrit.wikimedia.org/r/163558

Change 163559 had a related patch set uploaded by Bartosz Dziewoński:
Add support for page status indicators

https://gerrit.wikimedia.org/r/163559

Change 163560 had a related patch set uploaded by Bartosz Dziewoński:
Add support for page status indicators

https://gerrit.wikimedia.org/r/163560

Change 163563 had a related patch set uploaded by Bartosz Dziewoński:
Add rudimentary support for page status indicators

https://gerrit.wikimedia.org/r/163563

Change 163563 merged by jenkins-bot:
Add rudimentary support for page status indicators

https://gerrit.wikimedia.org/r/163563

Change 162609 merged by jenkins-bot:
Implement page status indicators

https://gerrit.wikimedia.org/r/162609

Change 162610 merged by jenkins-bot:
Add support for page status indicators

https://gerrit.wikimedia.org/r/162610

Change 163558 merged by jenkins-bot:
Add support for page status indicators

https://gerrit.wikimedia.org/r/163558

Change 163559 merged by jenkins-bot:
Add support for page status indicators

https://gerrit.wikimedia.org/r/163559

Change 163560 merged by jenkins-bot:
Add support for page status indicators

https://gerrit.wikimedia.org/r/163560

Done. Thanks, Bartosz!