This wiki is a XML full dump clone of "Heroes Wiki", the main wiki about the Heroes saga that has been shut down permanently since June 1, 2020. The purpose of this wiki is to keep online an exhaustive and accurate database about the franchise.
Template talk:Spoilertext
So are we keeping this template? Admin seemed to suggest he didn't want it... I don't think it's a good idea, either. Too much potential for abuse.--MiamiVolts (talk) 20:28, 10 November 2007 (EST)
- I for one don't see the big deal with this (or really, template:spoilertext--this one's pretty harmless) getting used on talk pages. How is it any worse than what happens now, where people freely post spoilery information in discussions? This happens all the time--scarcely an episode goes by without somebody discussing, say, the "next on Heroes" preview or the upcoming episode clips or other spoilers which seem to be coming to fruition on the epsiode's talk page--and they are, to the best of my knowledge, never removed from the talk pages. I've certainly never removed one for containing spoiler information because I've never given a single thought to spoiler information in talkspace, just in the article space. Even if someone's browser doesn't support this, we're still better off than we are right now, in that some spoilers are hidden for some users. It seems like a lot of sound and fury over something that's, at worst, a slight improvement over the current state of affairs.--Hardvice (talk) 21:27, 10 November 2007 (EST)
- No, you're missing my point. Actually, I just thought up a second point: 1) This black text is easy to hide spoiler info with, which is great, but it also makes it hard to read that text unless you edit the article or grab it with your mouse to highlight it. This makes it a pain in the butt to patrol, and hence a liability, imho. You might want to discuss that on the administrators portal, as I think Admin may have been hinting at this. Since this is a wiki and not a forum, search engines may treat this the same as sites who black-out both the text and background of the entire page (btw, that's now possible with this template...). 2) This is not good for screenreaders. For those people who read the site which are visually impaired or simply like to listen to the site with a screenreader, masking the text this way is worse than using a collapsed table, because at least a collapsed table always has a header row to note there's some text there. I don't always design purposely for the visually impaired, but I try to keep them in mind.--MiamiVolts (talk) 21:53, 10 November 2007 (EST)
- I still don't see any way in which it's worse than what we have now. People with screen readers are currently subjected to spoilers on talk pages; they'll still be subjected to spoilers on talk pages with this. The text is not a hidden element -- screen readers will still read it. Difference pages are used to patrol edits; they show the text, not the formatting. Misuse of this template can be dealt with just like misuse of any template, many of which could do far worse damage than just blacking out a page. This doesn't do anything a reader couldn't do with CSS anyway, except that it doesn't need to be highlighted to reveal, just hovered. Mountains out of a molehill, start to finish.--Hardvice (talk) 22:08, 10 November 2007 (EST)
- It doesn't need to be highlighted to reveal? Hmm, it's not working correctly for me, then. Is it possible to do something like IMDb where instead of a black-background a wallpapered image saying "spoiler" covers the text instead? That at least looks somewhat different than a newspaper edited by a government agency. LOL.--MiamiVolts (talk) 22:17, 10 November 2007 (EST)
- You may need to reload around your cache to get the updated common.css. It works for me in Opera, IE, FF, and Safari, and I confirmed that the text is still readable to screenreaders using Lynx. AS for using an image instead of a BG color: probably possible, but we'd need to use background-image instead of background-color, and we'd need to set the z-index to hide it behind the image (which would make any links unclickable until the box is hovered)--right now, the text prints on top of the bg-color, but since they match, it just blends in. The real problem is that background-image has a habit of working/stretching/filling poorly with inline elements like <span>, so we might need to switch it to a block-level element like <div>, which would likely be a page formatting disaster.--Hardvice (talk) 22:27, 10 November 2007 (EST)
- IMDb uses a span tag to do it as a wallpaper, and it works for me in IE6 on IMDb, but on this Wiki I just cleared my cache and cookies and reloaded the page and it is still not working. In Mozilla, it worked as soon as I opened it, though. Hrm. IMDb uses: [span class="spoiler" onmouseover="this.className='spoiler hover'" onmouseout="this.className='spoiler'"][span]test[/span][/span]--MiamiVolts (talk) 22:39, 10 November 2007 (EST)
- Yeah, they've gone with onmouseover JS instead of the :hover CSS pseudoclass.--Hardvice (talk) 23:01, 10 November 2007 (EST)
- Do you know where the CSS would be stored locally for IE6? Maybe I need to manually delete it in Windows Explorer?--MiamiVolts (talk) 23:05, 10 November 2007 (EST)
- Yeah, they've gone with onmouseover JS instead of the :hover CSS pseudoclass.--Hardvice (talk) 23:01, 10 November 2007 (EST)
- IMDb uses a span tag to do it as a wallpaper, and it works for me in IE6 on IMDb, but on this Wiki I just cleared my cache and cookies and reloaded the page and it is still not working. In Mozilla, it worked as soon as I opened it, though. Hrm. IMDb uses: [span class="spoiler" onmouseover="this.className='spoiler hover'" onmouseout="this.className='spoiler'"][span]test[/span][/span]--MiamiVolts (talk) 22:39, 10 November 2007 (EST)
- You may need to reload around your cache to get the updated common.css. It works for me in Opera, IE, FF, and Safari, and I confirmed that the text is still readable to screenreaders using Lynx. AS for using an image instead of a BG color: probably possible, but we'd need to use background-image instead of background-color, and we'd need to set the z-index to hide it behind the image (which would make any links unclickable until the box is hovered)--right now, the text prints on top of the bg-color, but since they match, it just blends in. The real problem is that background-image has a habit of working/stretching/filling poorly with inline elements like <span>, so we might need to switch it to a block-level element like <div>, which would likely be a page formatting disaster.--Hardvice (talk) 22:27, 10 November 2007 (EST)
- It doesn't need to be highlighted to reveal? Hmm, it's not working correctly for me, then. Is it possible to do something like IMDb where instead of a black-background a wallpapered image saying "spoiler" covers the text instead? That at least looks somewhat different than a newspaper edited by a government agency. LOL.--MiamiVolts (talk) 22:17, 10 November 2007 (EST)
- I still don't see any way in which it's worse than what we have now. People with screen readers are currently subjected to spoilers on talk pages; they'll still be subjected to spoilers on talk pages with this. The text is not a hidden element -- screen readers will still read it. Difference pages are used to patrol edits; they show the text, not the formatting. Misuse of this template can be dealt with just like misuse of any template, many of which could do far worse damage than just blacking out a page. This doesn't do anything a reader couldn't do with CSS anyway, except that it doesn't need to be highlighted to reveal, just hovered. Mountains out of a molehill, start to finish.--Hardvice (talk) 22:08, 10 November 2007 (EST)
- No, you're missing my point. Actually, I just thought up a second point: 1) This black text is easy to hide spoiler info with, which is great, but it also makes it hard to read that text unless you edit the article or grab it with your mouse to highlight it. This makes it a pain in the butt to patrol, and hence a liability, imho. You might want to discuss that on the administrators portal, as I think Admin may have been hinting at this. Since this is a wiki and not a forum, search engines may treat this the same as sites who black-out both the text and background of the entire page (btw, that's now possible with this template...). 2) This is not good for screenreaders. For those people who read the site which are visually impaired or simply like to listen to the site with a screenreader, masking the text this way is worse than using a collapsed table, because at least a collapsed table always has a header row to note there's some text there. I don't always design purposely for the visually impaired, but I try to keep them in mind.--MiamiVolts (talk) 21:53, 10 November 2007 (EST)
- I'm not opposed to this template at all. -- RyanGibsonStewart (talk) 23:35, 10 November 2007 (EST)
- Hardvice, I don't know what you mean by "worse than what we have now." The policy is that spoiler information does not get put on main articles or their talk pages, only on pages in the Spoiler or Spoiler talk namespace. If we are leaving spoiler information on talk pages currently, this needs to change. Spoiler information should ONLY be on spoiler pages. There's no reason people avoiding spoilers should be required to avoid the standard talk pages as well. This template is essentially a hack that is providing an excuse for not putting the information on a Spoiler page where it belongs. When someone wants to reference spoiler information on a non-spoiler talk page, the proper method is to include a link to the spoiler page, not trying to obfuscate the spoiler text on the talk page itself. Aside from being contrary to the reason for the separate spoiler namespaces, it causes issues for browsers which do not honor the formatting as well as for any other tool being used to search through non-spoiler content (for instance I suspect it may return undesirable results using the MediaWiki default search which purposely excludes spoiler namespaces). (Admin 23:38, 10 November 2007 (EST))