Forum:I think I fixed the sprite

Forums: Index > Village Dump > I think I fixed the sprite

Note: This topic has been unedited for 3701 days. It is considered archived - the discussion is over.

I hear tell that the sprite has been having issues and has been replaced with a non-functional placeholder. However, I've noticed that the real sprite does still exist and I've come up with a way to skoosh it back into the desired format.

Add the following code to MediaWiki:Uncyclopedia.css:

.article-thumb.show-info-icon .info-icon {
	background-image: url('http://img2.wikia.nocookie.net/__cb20140528181652/uncyclopedia/images/6/6b/Magnify-clip.png');
	display: inline;
	margin: 0.5em 0 0 0;
	background-repeat: no-repeat;
}

And the following code to MediaWiki:Uncyclopedia.js (to replace what's there):

$( 'a.sprite.info-icon' ).attr( 'title', 'Enlarge' );

...and that should do it -- I've currently got it in my personal css and js files, though it took a while for the changes to take.

I've also got some css for making the style of the thumbnail boxes match Wikipedia (and a bunch of other skin fixes), though I don't know how it relates to what we've already got or if anyone is interested.

Apologies if this is unwanted or in the wrong place; I notice there is already a forum dealing with this but it's archived. ❦ Llwy-ar-lawr • talk • contribs • 03:20, August 28, 2014 (UTC)

If it works better, that's good. Any objections?--RomArtus*Imperator ITRA (Orate) ® 12:06, August 29, 2014 (UTC)

As described in the closed Forum:Thumbnails are broken, I restored the Wikipedia-like "magnify" graphic, except for the business of making it actually do anything. About a week ago, Wikia added the "info icon," which seems to be the lowercase "i" in the photo itself when you hover over it. It would be better if it actually did something; however, resembling Wikipedia is the only point. Right now (with my own preferences), Wikipedia seems not to have the "i", but it also seems not to have the sprite either. If this is what other people see too, I suggest we eliminate both the magnify clip and the info icon. Spıke Ѧ 13:02 29-Aug-14

Yeah, the info icon is apparently a Wikia-specific version of the sprite, which I've modified to be like Wikipedia's sprite -- which, AFAICT, does still exist over there; see the thumbnail here. (Maybe log out first. It definitely exists for me both logged in and out; maybe you've got something in your preferences that gets rid of it.) ❦ Llwy-ar-lawr • talk • contribs • 18:58 29 August 2014

I am not seeing anything today on either website, and I have no local orders that would have removed the "info icon," which is too new. Separately, though, the "info icon" was superimposed over the photo, while the Wikipedia "magnify" was at the upper right of the caption area. If this is still the case, easier to propose a modification of my restored "magnify" to put the behavior back, if you wish, than to relocate the "info icon." Spıke Ѧ 22:26 30-Aug-14

I come not to praise the info icon but to bury it

And propose to add to MediaWiki:Uncyclopedia.js:

$("A.info-icon").remove();

Spıke Ѧ 22:26 30-Aug-14

Hearing no objection, it's toast. Spıke Ѧ 12:33 1-Sep-14

Oh yeah, this explains why I wasn't seeing any sprites. Sorry for not only putting my observations into VFD but giving you information that turned out to be irrelevant (as the sprites I don't see are different from the sprites you don't see if and when you don't see them), but I had noticed in the past that at least one specific article was missing the a.info-icon sprites, so I thought I had encountered that again but instead it was because you had removed all of them. (I was on vacation at the time you made the change, which is my excuse for being a bit slow.)

I did have something of an objection, but I was not sure what to say or if it was worth saying. I would rather my CSS and JS be used to turn the info icon into the sprite, since I'm not sure what's wrong with them and I don't know how to make your sprite functional. (I wish I did. I'm supposed to be doing something else right now, and school starts tomorrow... argh) Also, since you have removed the info icon with JS I won't be able to use my CSS to put it back (which I conveniently realised after you had already done it), whereas if you had instead said a.info-icon { display: none } in MediaWiki:Uncyclopedia.css I could still have made the info icon into a sprite for at least me. (I use too many parentheticals.) Again, I don't know if these things are worth anything, and I don't much mind if they're not, but tell me please... are they? ❦ Llwy-ar-lawr • talk • contribs • 14:23 7 September 2014

If you really need the Sprite to do something, such as what the Info Icon used to, this could be done with JavaScript, and it would only take me two hours to get it right. The reason I deleted the Info Icon, from the Uncyclopedia skin only, is that it has no Wikipedia analog, and users selecting that skin want a Wikipedia feel and not a Wikia feel. But all any of these gadgets did is go to the File: page in various ways, which you can do anyway by clicking on the image. So the best thing for the Sprite to do on a humor wiki is what it does: just throw up a Hint that its only purpose is to look like Wikipedia. Spıke Ѧ 14:34 7-Sep-14

PS--The above fix doesn't work if you are running with images enabled but JavaScript disabled (obviously, as the fix is JavaScript). I'll try to code it in CSS instead. Spıke Ѧ 13:37 10-Sep-14

Table of Contents problems

Separately, can you advise on our bigger crisis? Ever since Wikia implemented "lazy load," a strategy to make pages appear before completely downloaded, the Tables of Contents (filled in at the end of the process, with section numbering, perhaps via Ajax) are an <OL> list whose style specifies a second numbering scheme. I don't know where this style order is coming from, but we ought to override it. Spıke Ѧ 19:13 29-Aug-14

You raise very good points, but unfortunately my knowledge of javascript and CSS is only just enough to know that both situations would require some technique that I don't happen to know just now (with the sprite, there would need to be some kind of variable (?) for the filename to create the correct link target; with the TOC, the numbers would have to be according to a different style (1.1 etc) and inside the links). I'll try to figure something out, though, and I'll get back to you when I have. In the meantime, it's at least easier for me to use CSS to reposition the info icon.

Separately, your mention of the tables of contents reminded me that for some time they had been full-width instead of the correct size; that can be resolved by saying #toc, .toc { display: table; }. ❦ Llwy-ar-lawr • talk • contribs • 20:30 29 August 2014

I see this but had not noticed it before now and don't think it has gone on "for some time." I know plenty about CSS/JS/Jquery, and can see the DOM, but don't have and don't want to install the tools to see exactly whose spell a particular element is under. "display: table" changes the alignment of the heading but doesn't change the width. Someone has recently started specifying "width: 100%" but again, I can't see who. However, I may finally have a solution to the problem of "1 1. Introduction" in Tables of Contents. Spıke Ѧ 20:47 29-Aug-14

And yes, it is annoying that infrastructure on Wikia is "sticky." I think Wikia uses separate servers to view versus to modify the encyclopedia, and the two sets are notoriously bad at communicating during peak times. This has gotten better (the most recent problem is in uploading new versions of images) but may still be a problem when uploading a change to style orders. Spıke Ѧ 20:50 29-Aug-14

OK, here is Table of Contents coding that is working for me:

NAV#toc OL  { list-style-type: none }
NAV#toc     { width: 30% }
NAV#toc DIV { background-color: #DDD;
              border-bottom: 1px solid #444 }
NAV#toc SPAN.toctoggle { padding-left: 1em }

The only problem is in hard-coding the 30%. But when I take this off or specify "auto", it goes back to full-width. Spıke Ѧ 21:12 29-Aug-14

I'm glad you got it working. We seem to be seeing different things, though. I have looked at this test page in multiple different browsers and operating systems, and all of them change the width when display: table is set and show one, not two, sets of numbers (with the exception of Firefox 29 on Windows XP, which can't expand the TOC and therefore can't show me what it would look like): you can see the screenshots here, here, here, here and here. (Firefox on Windows XP also insists on floating the section edit links to the right -- it really has issues.) I think I saw two sets of numbers on VFD once, but the rest of the time I only see the one caused by the <ol>, which your code would hide and therefore cause me not to see any numbers at all. To get the TOC numbers working properly for me we would have to find some way of forcing the usual numbers - the ones inside the links (span.tocnumber) - to always be displayed; it might be related to the option in Special:Preferences (which I haven't been able to find here) that causes each section header to be numbered. ❦ Llwy-ar-lawr • talk • contribs • 22:02 29 August 2014

My solution (for very old Firefox) might not be optimal for the general experience. The <ol> numbers are wrong (from my view) in the case of articles with multiple levels of sections. The inner ones, again, are generated dynamically by Wikia. They do indeed seem to have removed the section-numbering option from Preferences, surely convinced that they had gotten it "right." Spıke Ѧ 22:11 29-Aug-14

---

So, Llwy, your comments convince me that my observations may be atypical and I have not applied my changes. However, your changes do nothing at all on my screen, and your proposal (whose selector applies it to "any element with ID or class toc") is scattershot (though that might be a plus, given possible future changes by Wikia) and I haven't applied it either. I ask Puppy, on his talk page, to check in and add his observations. Spıke Ѧ 11:40 3-Sep-14

And please don't hide technical observations in a ballot at VFD! Indeed, I observe that (1) Wikia is not consistently rendering sprites, and (2) Wikia's "lazy load" is not consistently supplying section numbers in the (software-enhanced) Tables of Contents. Am not sure how much of this is because cute features time-out when my connection is slow. Spıke Ѧ 13:51 7-Sep-14

Does this affect mobile/ipads etc? I recall the conversation I had at Wikia about 30% people viewing the site that way rather than using desktop computers. --RomArtus*Imperator ITRA (Orate) ® 14:09, September 7, 2014 (UTC)

No data, but I guess that the Table of Contents issues involves software that decides what text to provide, and not how to render it, and that it would apply to all viewing modes. I wonder if "lazy load" has access to My preferences to determine whether the user has opted for section numbering or none. Wikia could conceivably inhibit Sprites and Info Icons on mobile devices. If you don't see the Info Icon, it is because I turned it off (above). Spıke Ѧ 14:14 7-Sep-14

PS--No, correction: There is no section-numbering preference anymore. There might be a hidden preference flag, Wikia might be doing it two ways, and not based on anything correct. Another correction: The current Sprite doesn't come from Wikia at all but from my code, which depends on there being a FIGCAPTION with a P inside it with class "caption". If you observe that the Sprite is missing on a thumbnail that has a caption, point me to it and I'll see what code Wikia is generating. Spıke Ѧ 14:46 7-Sep-14

So... unfortunately now I seem to have no numbers at all in tables of contents. This is how it looks to me by default, logged in or out. This is what it looks like in Monobook and Wikia; the numbers have mysteriously reappeared and look just about exactly like they're supposed to. This piece of code generates those numbers in Monobook:

#toc li:before {
	content: counters(item, ".", decimal) " ";
	counter-increment: item;
}

So I figured, that should do it for 'Vector' (or however you call it) too, right? Wrong. It looks like this. The numbering seems to be based on what level of section it is, rather than how many sections there are. Not especially helpful.

I'm afraid I haven't tested this in other browsers and operating systems (aside from Chromium 34, which gave the same result as Firefox 31, both on my usual operating system). I probably should, but judging by my earlier screenshots I don't expect a significantly different result. Sorry for not having a solution to this weirdness. I thought sure I'd pinned it down, but then it slipped away like a jellyfish. I admit I don't quite understand the CSS properties I dug up, though. ❦ Llwy-ar-lawr • talk • contribs • 04:17 12 September 2014

Machinations

Yes, yesterday I put this piece of the above "fix" into MediaWiki:Uncyclopedia.css:

NAV#toc OL  { list-style-type: none }

So we no longer ever have two sets of section numbers, the first being serial numbers that don't show structure such as 1.1. (Your override undoes this.) However, now we sometimes have no section numbers. Again, my diagnosis is that Wikia "lazy load" is sometimes not providing them when it fleshes out the Table of Contents. Spıke Ѧ 10:47 12-Sep-14

PS--I see from your screen shot that you too need a second line of my fix, which I'll install now, to separate [show] or [hide] from the header. Spıke Ѧ 10:50 12-Sep-14

PPS--In fact, I'll implement my cosmetic fix too, with a light gray background and horizontal rule under "Table of Contents" to look like Wikipedia. That's everything except to force the width to be something less than full-page, which looks wrong when wrapping long section headings. Spıke Ѧ 10:56 12-Sep-14

---

I've reported to Wikia (again) that they are not always rendering section numbers in the Table of Contents (ticket #155599), citing this Forum. Spıke Ѧ 12:22 12-Sep-14

Thanks, let's hope Wikia can get it sorted. I see DaNASCAT has removed your code; I don't know if they think that will resolve the problem or what, but there's definitely something wrong on their end.

About the light grey (dark grey?) background and the horizontal rule, I'm afraid I don't see any such thing on Wikipedia. This is what I see. No extra styling or anything. The only real difference is that the numbers are well behaved and inside the links. ❦ Llwy-ar-lawr • talk • contribs • 16:40 12 September 2014

He has restored the code now; surely it seemed wise to remove my code before starting his test.

I cannot explain why you don't see the highlighting in Wikipedia's Table of Contents, but I do, and it is not coming from my local CSS. If others confirm that this order introduced a divergence from Wikipedia, I'll back it out. Spıke Ѧ 18:02 12-Sep-14

---

TOR of Wikia staff has just added Llwy's fix to the Table of Contents:

1. toc {display:table;}

Spıke Ѧ 11:31 18-Sep-14

Screenshots

In case this will help you (responding to Romartus' message about mobile platforms and Spike's last comment), I'm posting the tables of contents I see here and on Wikipedia:

Anton (talk) 19:07, September 12, 2014 (UTC)

[screen shots omitted]

You failed to mention what Wikipedia skin you have selected. I selected Modern (because it sounded, well, Modern). My observations may be atypical, and Wikipedia surely is not interested in changing its platform to let us track any of four Wikipedia skins, so I will back out the shading and horizontal rule. Only, not in the middle of Wikia's testing! Spıke Ѧ 19:26 12-Sep-14

Oh, is that what's going on. I use Vector and I assume Anton does too; I've also tried Monobook, which gives the same result. Never thought to look at it in Modern, but I did just now, and lo and behold, I saw exactly what you see. Most Wikipedia readers probably expect to see Vector, so it seems wise to follow Vector's styling here. ❦ Llwy-ar-lawr • talk • contribs • 19:33 12 September 2014

This cosmetic change is now rescinded. Spıke Ѧ 10:44 13-Sep-14