- I'm also trying to copy this template to Greek Wikivoyage el:Πρότυπο:Mapbanner but it doesn't work so far. Maybe it needs other templates? Handrian (talk) 07:03, 16 October 2014 (UTC)
- How did you resolve this issue ? --Omda4wady (talk) 09:25, 10 December 2015 (UTC)
- I think it is about div classes? What you think? --Aabdullayev851 (talk) 17:45, 13 July 2016 (UTC)
CSS
[edit]Ping User:Traveler100; regarding Special:diff/3724022
I see my CSS changes have been copied over (thanks). For consistency and optimization's sake, the styles should probably be copied over to an actual CSS file, probably Mediawiki:Common.css. The same should probably also be done to the {{WikivoyageSister}} changes. The file can only be edited by interface admins - @WOSlinker: can it be done?
This also ties in to the search box change. I had planned the same change and noticed the same problem you (Traveler100) did, that changing the inputbox to one that supports placeholder text requires changing to a fulltext search, and so loses the functionality of taking the user to the page if there is an exact match. There is a workaround: it can be changed to a full search, the kind with two buttons, and the second button can be hidden with CSS. Then, both placeholder text and exact matches are supported. The CSS rule would have to be added before the search box is changed, and it is the kind of rule that can only go in a file, not inline:
#mainpage-searchinput .mw-ui-button[name="fulltext"] { display: none; }
- ARR8 (talk | contribs) 23:59, 11 February 2019 (UTC)
- User:ARR8 thanks for looking into this, would be good to get a solution. Have to say CSS is something I do not know a great deal about. Is there a couple of pages can direct me to so I can learn a little more. --Traveler100 (talk) 06:38, 12 February 2019 (UTC)
- ARR8, could this be done with templatestyles rather than adding the CSS to Common.css? It would then allow for easier editing, if it's possible to do with templatestyles. -- WOSlinker (talk) 08:24, 12 February 2019 (UTC)
- That's perfect, thank you very much for letting me know about this feature. I have moved all template-relevant CSS to this file. Could you now remove the lines from common.css? They are now redundant and may cause future conflicts if this CSS is edited. It is everything starting with #mainpage. ARR8 (talk | contribs) 01:59, 13 February 2019 (UTC)
- @WOSlinker: ARR8 (talk | contribs) 02:08, 13 February 2019 (UTC)
- I've removed the css from common.css -- WOSlinker (talk) 18:54, 13 February 2019 (UTC)
- @Traveler100: As with anything web-related, I find w3schools very helpful. Mozilla's documentation is great for looking things up, and CSS tricks has some useful advanced techniques. What I did up there is called an attribute selector; you can select for any XHTML values, not just class and id. ARR8 (talk | contribs) 02:17, 13 February 2019 (UTC)
- ARR8, could this be done with templatestyles rather than adding the CSS to Common.css? It would then allow for easier editing, if it's possible to do with templatestyles. -- WOSlinker (talk) 08:24, 12 February 2019 (UTC)
parameters of template
[edit]I have disconnected the parameters from the mobile part of this template as the format is diverging, and should do. Thinking maybe should remove altogether the text parameters and just have the text editing for top part of main page for desktop and mobile in this template. --Traveler100 (talk) 06:41, 12 February 2019 (UTC)
scale imagemap
[edit]Is there a way to dynamically scale the image of the imagemap (like the feature of the month carousel does) so can use same code for desktop and mobile? --Traveler100 (talk) 21:47, 12 February 2019 (UTC)
- @Traveler100: See my comments at Talk:Main Page#Updating image at top. The imagemap is not very good for technical reasons and should be replaced, ideally with a proper XHTML element like an SVG. It is not really worth trying to make it work better, as a truly scalable solution would be much easier to maintain. ARR8 (talk | contribs) 15:39, 13 February 2019 (UTC)
- @ARR8: With SVG is the link mapping in the file or external to it? Can the image shown at User:Traveler100/sandbox-mapbanner be used directly or does it need editing? And I assume some css needs to be edited for the scaling to work on mobile? --Traveler100 (talk) 20:01, 14 February 2019 (UTC)
- @Traveler100: Inside the file. Unfortunately, that file cannot be used, because it is not a true SVG - the continents are just an embedded PNG in that one. There are a few ways to do scaling, and CSS is not necessarily required.
- I'll look into uploading an example map with the links we want, as a demonstration. ARR8 (talk | contribs) 17:36, 15 February 2019 (UTC)
- @Traveler100: Update: I am finding out that Mediawiki, or the way we have it configured, is very hostile to this sort of thing. I created an SVG with embedded links and hover effects, but was not able to upload it at Commons or here because embedded HTML is not allowed in images. Neither did it work when replacing the anchor links with javascript onclick functions, because this was specifically disallowed. So, I took out the links and uploaded the file without them, to find a way to embed the links in client-side javascript, and discovered this would also not work, because there is apparently no way to directly embed an SVG file without the backend converting it to a PNG first, which defeats the whole purpose. There is probably a way to use javascript to embed the SVG directly and then add links to it, but I'm hesitant to use javascript for this purpose on the final main page because this would prevent users without javascript from clicking the links, which is absurd. @WOSlinker: do you have any ideas for another course of action? Maybe there could be an exception to the image configuration for this? Is there a way to use a small module or something similarly low-level to bypass the normal image embedding process? ARR8 (talk | contribs) 20:05, 15 February 2019 (UTC)
- I'm not aware of any options to allow uploading svg with embedded html. Just wondering if you could try a normal imagemap (which would show the image as a png) and then use some javascript to replace the png image with the svg version? -- WOSlinker (talk) 07:52, 16 February 2019 (UTC)
- It appears you can scale an image and the imagemapping scales at time of coding (see mobile version). Any way to script a choice using new standards? --Traveler100 (talk) 08:02, 16 February 2019 (UTC)
- I should probably link the hover demonstration on this page.
- @Jdlrobson: would you happen to know if this is possible to implement, or have any suggestions? I am not keen on the other options as yet. Let me know if you'd like me to elaborate on what I've tried/considered. ARR8 (talk | contribs) 04:59, 24 February 2019 (UTC)
- It appears you can scale an image and the imagemapping scales at time of coding (see mobile version). Any way to script a choice using new standards? --Traveler100 (talk) 08:02, 16 February 2019 (UTC)
- I'm not aware of any options to allow uploading svg with embedded html. Just wondering if you could try a normal imagemap (which would show the image as a png) and then use some javascript to replace the png image with the svg version? -- WOSlinker (talk) 07:52, 16 February 2019 (UTC)
- @Traveler100: Update: I am finding out that Mediawiki, or the way we have it configured, is very hostile to this sort of thing. I created an SVG with embedded links and hover effects, but was not able to upload it at Commons or here because embedded HTML is not allowed in images. Neither did it work when replacing the anchor links with javascript onclick functions, because this was specifically disallowed. So, I took out the links and uploaded the file without them, to find a way to embed the links in client-side javascript, and discovered this would also not work, because there is apparently no way to directly embed an SVG file without the backend converting it to a PNG first, which defeats the whole purpose. There is probably a way to use javascript to embed the SVG directly and then add links to it, but I'm hesitant to use javascript for this purpose on the final main page because this would prevent users without javascript from clicking the links, which is absurd. @WOSlinker: do you have any ideas for another course of action? Maybe there could be an exception to the image configuration for this? Is there a way to use a small module or something similarly low-level to bypass the normal image embedding process? ARR8 (talk | contribs) 20:05, 15 February 2019 (UTC)
- Image maps have never really worked too well on mobile. Although supported they are not responsive and would have a horizontal scrollbar. Replacing an image map with a SVG via JavaScript is also not ideal as it would cause a bad experience for users on slow connections (imagine you are about to click Australia in the image map and then suddenly Asia moves as the image map is replaced with an SVG). If I wasn't working in the constraints of the MediaWiki system I'd definitely recommend SVG as the way forward. I believe you can wrap path tags with anchor elements... however as you say I don't think MediaWiki supports this in any way. Sadly I don't think clickable maps or SVGs are viable right now if you want this to look nice on mobile and desktop. If you don't mind about JS-only solutions, I'd suggest starting with an image that has to be clicked to become interactive (to avoid the performance problem I mention erlier) or an image that is hidden on mobile using the `.nomobile` class. (Maybe Graph extension could be leveraged in some way looking at the examples?) Jdlrobson (talk) 02:56, 26 February 2019 (UTC)
- @ARR8: With SVG is the link mapping in the file or external to it? Can the image shown at User:Traveler100/sandbox-mapbanner be used directly or does it need editing? And I assume some css needs to be edited for the scaling to work on mobile? --Traveler100 (talk) 20:01, 14 February 2019 (UTC)
Line wrapping
[edit]As I predicted, there was a conflict between duplicate rules in common.css and templatestyles, causing strange line wrapping behavior. I've pushed a fix for now. @Traveler100: The manual <br> can now be removed from the parameters on the main page. ARR8 (talk | contribs) 15:39, 13 February 2019 (UTC)
- thanks. --Traveler100 (talk) 16:08, 13 February 2019 (UTC)
Borked
[edit]This is not being displayed at all correctly on the Main Page (in my FF 113.0.1 for Ubuntu [desktop], anyway). I am seeing the end of the tagline, "Wikipedia for sightseeing, activities, cuisine", below the "morelinks" text, "More: Destinations • Itineraries • Phrasebooks • Travel topics", and slightly overlapping it. And the rest of it ("inputbox" and "touristoffice") is not visible at all. Same thing in both Vector and Vector legacy. Someone needs to look into this. - dcljr (talk) 00:15, 22 May 2023 (UTC)
- If line 15 of file Template:Mapbanner/styles.css uses "55%" width, "mainpage-maplinks" div tag will not overlap "mainpage-touristoffice" p tag. But I don't have permission to edit the file. Public class (talk) 01:06, 5 August 2024 (UTC)
Mapbanner's appearance in Vector 2022
[edit]The balance of the width of elements on the Main Page has bothered me for a long time. A part of what causes that, is Mapbanner's width. I am entirely convinced that it should, in desktop environments, use the full page width available. Back in legacy Vector, this issue wasn't quite as major, but in some configurations of Vector 2022, the template looks painfully out of proportions. I do have a fix ready to deploy - All I need is consensus:
- The width restriction defined in {{Mapbanner/styles.css}} (line 9) gets replaced with
width: 100%. - The first <imagemap> in {{Mapbanner}} gets forced to the right side.
The effect of these simple changes boil down to the template being made as wide as the rest of the page content. The globe image gets shifted along accordingly (as far to the right as possible). This would do the same across all skins, but like I said: This issue happens in each and every skin. It's just especially egregious in Vector 2022.
― Wauteurz (talk) 20:58, 5 May 2025 (UTC)
- Support per nom. I agree the mapbanner as it stands on V2022 is especially egregious and this proposed change would fix what is painfully annoying to look. //23:00, 5 May 2025 (UTC)
- Comment - Images can say more than words. This is how Main Page looks on my end. I do have some changes applied to the JCarousel of featured articles, but you may ignore those for this suggestion.