User talk:Majr/Archive 15

Collapsible stuff
Instead of maintaining a custom-built solution, is there any reason not to recommend the use of ? There's no additional overhead involved with it, since the code's included in core and is thus already sent on every page request. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 16:01, 17 November 2015 (UTC)


 * Yeah, mw-collapsible sucks, which I why I originally wrote an updated version based on the script that mw-collapsible was meant to replace. Its main issue is it purely uses JS to collapse elements, which means there is a large page jump once the page finishes loading where all the elements collapse, this is especially problematic for anchor links, as you will end up further down the page than the anchor, as the collapsed elements above it have moved the rest of the page up. This also makes the page a lot slower to load if there are a lot of things on the page to collapse (you may recall the issue with the recent changes being slow when it was first changed to use mw-collapsible).
 * Other issues are:
 * It doesn't have the ability to specify the collapse button to be inline (we use that a fair bit).
 * It uses actual links for the collapse toggle, which is semantically poor and can be confusing to users (middle-clicking a collapse toggle will open the current page in a new tab rather than do anything sensible, for example). To be fair we use a span styled to look like a link, rather than using a button, so it's not much better off semantic wise, but at least it won't do anything but toggle the collapsing.
 * It uses silly low performance jQuery animations which don't work properly.
 * –Majr 01:58, 18 November 2015 (UTC)


 * mw-collapsible is pure JS because if you use CSS to hide the content initially and then JS is used to show it after page load, viewers with JS disabled will be unable to show the content without using developer tools in their browser. Because of this and other accessibility concerns/problems, Wikipedia policy is to never put actual page content in a collapsible section, which is why the vast majority of collapsible content on WP articles is the navboxes.
 * I actually don't recall anything about RC being slow, since I haven't used enhanced RC for years. And I can't really comment on your other concerns, since I only have personal anecdotes I could respond with, and I'm definitely not a UI/UX expert. Mostly I was curious about why you were reinventing the wheel here, especially since you could just submit patches against core to have fixes and features added for all MW users. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 20:21, 18 November 2015 (UTC)


 * Except it isn't because there's MediaWiki:Noscript.css (which reminds me I didn't update it), to unhide the content when JS is disabled, and mw-collapsible would be able to restrict its stylings to.
 * In the end, even if I did patch mw-collapsible (which would only be possible for some configurations), I wouldn't see the change for at least a year, maybe two, since we're always on an old version of MW. So we either have no collapsing, or I re-invent the wheel with a ~100 line script. –Majr 05:41, 19 November 2015 (UTC)

Edit or delete user profiles?
User:Taxdepreciationschedules is using their profile as a fairly typical spam page. Is there any way to delete it, or at least edit it to remove the link? -- Orthotopetalk 21:54, 20 November 2015 (UTC)


 * There's a pencil icon to the right of the profile text that allows it to be edited. Although, there's nothing stopping them changing it again, since being blocked doesn't stop you from editing your preferences. –Majr 14:28, 21 November 2015 (UTC)


 * I don't see that icon on anyone's profile but my own; is it possible the ability to edit other user's profiles is restricted to Curse only? Had a few more cases of this kind of spam in the last couple of days. It seems like the profile system is rather flawed if people can put any kind of garbage they want in there and admins have no way to stop them or get rid of it. -- Orthotopetalk 08:19, 31 December 2015 (UTC)

Untitled
I see the smooth stairs now. My bad. Won't happen again. I just wish there was a good screenshot of the block..... --minecraftprimalgroudon –Preceding unsigned comment was added by MinecraftPrimalGroudon (talk • contribs) at 14:40, 03 December 2015 (UTC). Please sign your posts with

Random "red links".
Welp, just now, and I'm not sure if its just me, but random "red links" have been popping up everywhere. -BDJP (t 22:29, 17 December 2015 (UTC)
 * I'm getting it too. Nothing seems to be actually gone, thankfully. – Sealbudsman talk/contr 22:33, 17 December 2015 (UTC)
 * Wait a second. It's just visited links, they used to be purple or something, now it's red.  Wow, something so simple as a color yet so profound.  – Sealbudsman talk/contr 22:35, 17 December 2015 (UTC)


 * The issue seems to be with the class  having lost the blue override, thus defaulting back to the red default from somewhere before. This something I noticed on a few special pages before (most notably Special:ListUsers), so I actually have some user CSS that fixes the issue (search "Stop the visited links") if any of you want it as a temporary fix until Curse/an admin more properly fixes the CSS. – KnightMiner  t/c 23:02, 17 December 2015 (UTC)
 * You are basically right, KnightMiner. The command in question overrides the default a:visited color with red - I suspect it should've been  in that CSS file (whichever that is). Without the repetition of the class 'curse_account', the single a:visited behind the colon is "universal", not limited to the selection before. It's something Curse has to fix, and it's been introduced quite recently, so whoever did this will certainly know the right file :D --CalebBlackhand (talk) 23:10, 17 December 2015 (UTC)
 * Seems to be fixed now, both here and on the german Wiki. --CalebBlackhand (talk) 23:28, 17 December 2015 (UTC)
 * Still happening on my end, unfortunately. -BDJP (t 01:24, 18 December 2015 (UTC)


 * I don't have visited links enabled, but inspecting the CSS shows that it should be fixed. Clear your cache. –Majr 06:26, 18 December 2015 (UTC)

Permission Request
Hello,

I'm wondering if I could get permission to use the "block renders" from the Wiki in production of my YouTube videos. Obviously will be attributed too!

Thank you - MrCrayfish Twitter: https://twitter.com/MrCraayfish –Preceding unsigned comment was added by 101.177.211.30 (talk) at 5:22, 30 December 2015 (UTC). Please sign your posts with


 * Most of the images are licensed under Mojang's license for the textures (which allows them in non -commercial things almost freely), and CC BY-NC (which allows you to use and edit it, provided you give attribution and use it non-commercially).
 * Most of the newer files (either made by Majr or others) only state the Mojang license, so I assume they default to either CC BY-NC-SA + Mojang's license, or just Mojang's license, though I am a little unsure of which (but either one allows for non-commercial usage like above). – KnightMiner  t/c 16:52, 30 December 2015 (UTC)


 * I'm sure all my videos fall under the Videos and Screenshots section of the Mojang lisence, so the use of overlay an item sprite on the video would be allowed (They will be used in Redstone Tutorials). It's just the block renders Majr has created, do restrict the use of commercial use without explicit permission. Basically I'm half way there to full permission. 101.177.211.30 03:00, 31 December 2015 (UTC)


 * That's fine. Any images which still have the license on them are outdated, they should just have the Mojang license on them now. –Majr 10:39, 6 January 2016 (UTC)

Spam accounts
Hey Majr, staff attention is urgently needed in regards to Minecraft Wiki:Admin noticeboard. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 18:41, 5 January 2016 (UTC)

Editcounter.js
Does your editcounter.js still work? I copied it, translated some to Dutch, or at least what I thought was translateable, but it does nothing... No link to run the script or am I being stupid and not having the right pages to make it work? (link to editcounter is here: editcounter.js) -- DarkShadowTNT  NL Admin ( t  ♦  c ) 19:07, 23 January 2016 (UTC)


 * Haven't run it in a couple of years, but it appears to. Look in the tools section of the sidebar while on your userpage. –Majr 06:17, 25 January 2016 (UTC)


 * Apperantly I was having some cache problems then, it did not appear in the sidebar... Thank you anyways! -- DarkShadowTNT  NL Admin ( t  ♦  c ) 07:04, 25 January 2016 (UTC)


 * Does your editcounter still works after MediaWiki update 1.26? Mine doesn't, unfortunatly... -- DarkShadowTNT  NL Admin ( t  ♦  c ) 18:31, 5 February 2016 (UTC)


 * Looks like it almost works, but fails to save at the end, due to changes in how tokens are handled. –Majr 02:53, 6 February 2016 (UTC)


 * Aw... I hope there is a solution for this problem soon, I really liked it, and it was less time consuming than counting all the edits manually -- DarkShadowTNT  NL Admin ( t  ♦  c ) 11:43, 6 February 2016 (UTC)

3D Block Rendering
I am an Admin on a wiki for a minecraft mod, and I am currently working on adding a lot of 3D rendered images to that wiki. I found some of those 3D rendered block images that are on the Block page, and I am wondering what tool you used to make those rendered images. I'm hoping that whatever it may be, it is possible to upload any range of block textures, not just vanilla MC pics. ~Samwise (Functioning as Anon, so yeah...) –Preceding unsigned comment was added by 50.109.66.78 (talk) at 1:13, 03 February 2016 (UTC). Please sign your posts with


 * See User talk:Majr/Archive 10. -- Orthotopetalk 01:37, 3 February 2016 (UTC)

hex.colorrrs.com works
How is the site broken? I've been using it for years and it still works to this day. CircuitSoft (talk) 21:03, 19 February 2016 (UTC)

Yeah, I just checked, I have had positive impressions so far -- what is broken about it? – Sealbudsman talk/contr 21:11, 19 February 2016 (UTC)


 * When you posted it, the site did nothing. It had a script error, which seems to have been fixed now. –Majr 05:17, 20 February 2016 (UTC)

Release table clarification
This comment doesn't read well. What did you mean by removed? I added an additional level of closing and opening a DIV to match the level that table 2 and 3 are closed and opened so that the tables would end properly. Also, what did you mean by disabled and broken browser? Thank you. AeronPeryton (talk) 06:53, 28 February 2016 (UTC)


 * Your summary made it sound like the wrapping was not working on your (if so, broken) browser. There's only one table (the computer edition versions), not sure what else you think is a table. Every tag is opened and closed at the correct level. That can be easily seen if you copy it into an editor that can auto-indent it. –Majr 01:06, 29 February 2016 (UTC)


 * From the looks of it though, within the main div for the editions there is an additional div containing the computer and console editions, plus a second one containing just the pocket edition (and Aeron's edit separated the PC and console editions). Are any of them supposed to be inside additional div's, since  adds a div as well? – KnightMiner  t/c 02:18, 29 February 2016 (UTC)
 * Edit, nevermind, it seems those are forcing the Console Edition to join the same line as the PC edition on large screens, rather than choosing the pocket edition. It does seem to do that anyways if they are all in a div together, though I'd assume that is be based on the contents. – KnightMiner  t/c 02:38, 29 February 2016 (UTC)


 * Each first level div is a flex group, pocket and pc/console are separate groups. As you'd have to have an ultrawide monitor (in which you probably wouldn't have the browser fullscreen), or the browser spanning across multiple monitors to get all three fitting side-by-side, it didn't seem necessary to move them to the same group (which wouldn't make any difference on normal screens). Of course, they were originally separate groups because we had 4 boxes before, in which case the browser across multiple monitors would be the only way to fit all four side-by-side, but no one would do that. –Majr 02:44, 29 February 2016 (UTC)


 * Wrapping is only failing between tables 1 and 2 but it works fine between tables 2 and 3 (Safari without fix, Chrome without fix, Safari with fix). I was just going to report it but I looked at the code and realized that tables 1 and 2 are technically part of the same group, while 3 is its own group. So I copied the same amount of divs closed and re-opened between tables 1 and 2 as there are between tables 2 and 3 and it fixed it. Safari is not broken, but WebKit has a much stricter adherence to the HTML5 spec than any other browser, and employs very little proprietary secret sauce in its rendering engine. It's most likely that the table bug is either ignored or automatically corrected in other browsers such as Chrome or Firefox.


 * And to respond to KnightMiner, as you can see from the images the tables don't resize the rest of the page with them when they sit side by side. So it is clearly a mistake, and not an intentional effect meant for wider resolutions. AeronPeryton (talk) 04:19, 29 February 2016 (UTC)


 * "Tables" 2 and 3 aren't wrapping, they're separate blocks. Only 1 and 2 wrap, which is obviously not working on your browser. What version of Safari are you using? –Majr 06:59, 29 February 2016 (UTC)
 * ...What you said. I don't know your lingo but, yeah, tables 1 & 2 are part of the same block, and table 3 is its own block. The fix puts each table in a separate block. I don't understand why the first two need to be bundled together but the third does not, but for some reason that's borking the layout under Safari. The latest version of Safari is 9, which is only included with OS X El Capitan. The browser is updated in tandem with the OS. And I personally know that Safari 8 on Yosemite doesn't do this. So since the latest stable build of WebKit is added to Safari when the OS gets updated, I presumed that Safari's stricter-than-everyone-else's HTML5 support was to blame. Lemme check it using the latest WebKit snapshot... AeronPeryton (talk) 10:55, 29 February 2016 (UTC)
 * (installs WebKit) Same effect in the latest version of WebKit, built today. However... I got curious and stumbled upon something interesting that makes this even stranger. I opened the debug console and edited the CSS entry for .edition-box, changing the flex entry from 50% to 51% and that also somehow fixed the problem (picture). I changed the dimensions of the browser window and the fix held regardless of how the page was rendered. I have no idea what that means because I stopped making websites before flex was an argument in CSS, but maybe you do. If you implement the compatibility fix this seems like a better way to do it. AeronPeryton (talk) 11:34, 29 February 2016 (UTC)


 * Just wanted to say that I'm getting this layout bug on Safari in El Capitan and also on iOS 9. –Goandgoo ᐸ Talk Contribs 12:02, 29 February 2016 (UTC)


 * I've already explained why 1 and 2 are in the same block, so they can be side-by-side. Previous versions of safari didn't do this, because they didn't support flex (without a prefix), and thus always had each box on its own line. Safari 9 now supports flex, but is affected by a webkit bug, fortunately there is a workaround. Obviously setting it to 51% would "fix" it, because then two boxes can never fit side-by-side, removing the point of the whole flex styling, as did your previous solution. –Majr 23:13, 29 February 2016 (UTC)
 * I understand what the intended effect was, I just didn't see any reason for it. But I appreciate you taking the time to talk to me and digging up that bug report, good to know. And your edit to the main page fixes the issue for me, thank you. It's good to not have to scroll sideways. AeronPeryton (talk) 00:17, 1 March 2016 (UTC)


 * The reason is simply to save space. On a standard HD screen, there would be a lot of unused horizontal space, which wastes vertical space. Compare: with and without. –Majr 00:28, 1 March 2016 (UTC)
 * (plays with the resolution) I see it now. Boy, you have to go way out to make it happen... and the site itself stops expanding shortly after that. Another suggestion: If the idea is to prevent white space, wouldn't it be better to swap Console and Pocket? The Console table has the most entries, and would take the most advantage of the space in a block of its own. Or is the current sorting of the release categories more important? AeronPeryton (talk) 03:39, 1 March 2016 (UTC)


 * It made more of a difference when there was 4 boxes. The site never stops expanding, although the table does when there is no more content to wrap (which would be easy to fix if it actually mattered).
 * Pocket and Console take the same space, even when there is a development version. –Majr 03:59, 1 March 2016 (UTC)