Last modified: 2014-11-04 19:26:06 UTC
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.
Thread on wikitech-l relating to this issue: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/48369
FYI, the (rough) implemention on zhwiki: [[zh:Template:Topicon]] and [[zh:MediaWiki:Common.js]] (search for "topicon).
Created attachment 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.
(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.
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.
(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 :)
(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
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.
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 [details] Partial implementation #2 Redid this with support instead for full wikitext. Still needs proper placement in skin files (under firstHeading?) and CSS ninja-ing.
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.
(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]]). >
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>).
(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.
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.
Might be an idea to add a hook, to directly add emblems from the software in some way? Or am I overlooking that functionality?
(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)
(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.
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.
Removing need-review from my own patch.
+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
Patches: * MediaWiki: https://gerrit.wikimedia.org/r/162609 * VisualEditor extension: https://gerrit.wikimedia.org/r/163563 * Vector skin: https://gerrit.wikimedia.org/r/162610 * MonoBook skin: https://gerrit.wikimedia.org/r/163558 * Modern skin: https://gerrit.wikimedia.org/r/163559 * Cologne Blue skin: https://gerrit.wikimedia.org/r/163560
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!