Since the move from vbulletin to Xenforo, I've noticed that the tags have been a lot poorer than before. Namely, they create a line break before and after the hidden text, and you can simply roll over the text to highlight it. The original point of the hide tags, as suggested [URL='http://kh-vids.net/threads/alternate-spoiler-format.127678/']here[/URL] by Makaze, was; [quote=Makaze]I feel this would be a good addition because it doesn't provoke as much curiosity as the clickable spoiler and requires a more deliberate action to reveal. It also allows someone to hide text within a line without disrupting the format while the normal spoilers move things down onto the next line and are inconvenient for use in a sentence or paragraph.[/quote] The way that they are currently implemented negates those original reasons for the tags existing, so I feel like it would be hugely worth fixing these problems. The original suggestion thread got a hell of a lot of support for the addition, but there has been no public support for the new changes made, nor is there any evidence that users want an alternate spoiler tag that can be viewed with even less intent than clickable boxes, so I think it would be only fair to make them work as originally intended.
The coding was changed when we went to Xenforo I believe. Yeah, the coding got changed. The tag is really [*hidden] [/B]now (remove asterisk)
The coding itself isn't the issue, but how it works. It used to be that you had to purposefully click and drag the cursor over the text in order to highlight it, but now just rolling over it with the cursor does, making it very easy to accidently view the spoiler. Fixing the problem should be very easy, since the original implementation was a custom BBCode with distinct HTML. The edit wouldn't have been done automatically. If the new one is specialized via an add-on, then that add-on is not what was requested. What was requested was the custom BBCode without the hover effect and without the newline, which is possible via this and perhaps a built-in BBCode framework if XenForo has one.
The line break issue was unintentional, it should be fixed now. However, the hover effect is pretty typical of that style spoiler tags.
Thanks for fixing the line breaks, that was annoying me. About the hover issue, while it may be typical of the tag on other sites, it is still relevant. The other sites didn't ask for the same things we did, and the reason for the suggestion is still negated with the change. Because no public support was put forward for the change and the reasons that people originally voted for have been negated, a change back to the original suggestion still seems only fair. When the tags were suggested, Makaze referred to TVtropes, a very popular site that has a similar spoiler tag set-up, and doesn't have the hover feature. If you don't have a particular reason for why the original reasoning isn't important anymore other than that it seems unusual to you, it doesn't really make sense to ignore it.
Shoo Makaze! ;> Okay so let's see if this works...okay there we go. Sadly this code does not work on mobile devices. Neither hovering nor highlighting it works (on iOS devices at least) So I'm not sure it should be used on important things? Maybe recreationally but even then, those using devices other than a computer will have trouble using it, sadly. Doesn't really have much to do with the overall fixing of the code. Many things went wonky when Xenforo happened, but I figure it's worth mentioning.
Are you sure it's fixed? Rolling over it still highlights it for me. It's still easier to see than the button spoilers. Also, for the iOS-only and mobile device-only issues, this may help. EDIT: In light of the mobile problem Chev corrected himself on, mobile users will see a black block that they cannot unhide either way and have been seeing one throughout both versions. That makes the argument from mobile functionality void regardless of whether or not the link above can help, though I'm pretty sure it can. Since that's out of the way, it's back to the original reasoning (that it should be harder to see accidentally) over it seeming unusual.
So the problem is that instead of highlighting the spoiler to reveal it, hovering over it reveals it, correct? This wasn't always like that, if I remember, even if the /[*hidden] tags is a recent addition. What DarkTraitor is saying is that hovering over it isn't the wanted effect and it should be fixed. I agree. In an ideal world, people would use it for spammy stuff and nothing big and save the better working spoiler tag for real spoilers, but this is neither an ideal world where we can assume other people will behave...ideally and the spoiler tag, like Makaze said, is really tempting to click. Maybe it's some form of psychology, but just like the OP quoted, having to click and drag to highlight a spoiler is a more deliberate action than clicking and -possibly accidentally- hovering over. It only takes an instant for the eye to catch something you don't want to see. moviepilot.com uses the same "simply-hover-over-spoiler-to-reveal" method and because of where my mouse was when the page opened, I got the plot of an upcoming movie spoiled. TVTropes has it right, in my opinion. tl;dr: no hover. Highlight please. +1 to everything DarkTraitor says
Just to clarify, I wasn't saying it was fixed. I was just trying it in a mobile device :x I'm not really stating if it should be fixed or not. Just noting that it does not work at all on mobile devices which could be problematic. It's not 'out of the way' but rather something that was a side-note.
So is anything about this being done? Has the line break problem been fixed? +1 for the highlight spoiler. ...Also, the [hidden*] tags don't do anything but break lines in the post preview. A lot of formatting issues pop up when previewing them it seems. Edit: FFFF- *Adds asterisk to tag*
I was going to change it but with the hurricane cancelling a week of my classes, there's been a bit of a "let's shove everything into the weeks we have" mindset. Unfortunately natural disaster recovery & more important KHV site work comes before a minor bbcode annoyance. c;
Requesting an update on this, please! On top of the previous requests, I believe a change is a prudent move because the tag has a few bugs as it currently is. Taking from the first post, the code right now is this: Code: <span class="spoiler-hide" style="background-color: {1}; color: {1};"></span> Hovering over the hidden text in the first post turns the text white, but nothing else. This happens because there is no argument given in the first post, but it still tries to render without one. This only applies to the [HIDE=COLORVALUE][/HIDE] tag. It's clear from the way the post is rendering that this tag has neither been removed completely nor implemented correctly for XenForo. More on how to fix this below (Possibility 1). The [HIDDEN][/HIDDEN] tag works fine aside from using the hover instead of the select feature, as seen here. In order to fill this request and solve these problems in one go, I think the following courses of action make the most sense: Remove the hover effect and instead force people to select the text. This fills the request and meets all of the criteria asked for in this thread. Additionally, the current hover setting uses white as the hover color on all themes which may become an issue later. Remove CSS rules specific to this code and instead use proper inline CSS without classes. Doing so will centralize the code for this tag and thereby clean up your templates. Remove the [HIDE] tag completely to avoid redundancy. Possibility 1: Make the [HIDDEN] tag have a color value argument to replace the previous [HIDE] tag. e.g. [HIDDEN=#ff0000][/HIDDEN] (for red spoiler blocks) It should be possible to make a conditional statement so that if the tag is used without an argument, it defaults to black as it does right now. Possibility 2: Ignore color options completely and have one static [HIDDEN] tag that defaults to black like the one staff created after the move. I prefer Possiblity 1 because it is more in line with what what was asked and voted for, if it is possible. Thank you for keeping it open this long.
It's actually been my plan to gut the code altogether and redo it. XenForo's Custom BB Code system is vastly better than vBulletin's but I didn't really change the code at all when we moved (and it had problems from the start). I'd like to put together a less hacky solution that doesn't require both the hide & hidden tags, as well as one that doesn't rely on hovering (since that has mobile issues & it's easy to accidentally expose the spoiler). My plan was to do one similar to what they have on NeoGAF, but of course allowing custom colors to be used. So the suggestions are appreciated, it's already in the pipeline.
What is the one on NeoGAF like? I have a copy of XenForo 1.2 (I think it is) for personal development. If you would like, I can cut down on the load and try to code it for you or at least figure out a way to combine the tags into one. I have the free time and the knowledge. I will understand completely if you are not comfortable with that.
First post I came across with a spoiler: http://www.neogaf.com/forum/showpost.php?p=118089767&postcount=23 It's pretty similar to ours at first glance. Instead of hovering, you click on the spoiler and the background color disappears, exposing the text. You could also highlight it to show it but that's not really how it's designed to work. Won't be necessary but thanks for the offer. @libregkd recently became my code slave so if I can't find the time to do this I'll just ask him (provided he's willing I guess lol). I wasn't treating it with any kind of urgency but since you've brought it up & it's a pretty small task it can get done fairly quickly.
Ah, I see. That's interesting... It toggles back if you click again, which is nice. If you want it to work with mobile devices you'll have to use touch events as well as clicks. Bind to both 'click' and 'touchstart'. I'm looking forward to what you come up with. Good luck.[DOUBLEPOST=1403696100][/DOUBLEPOST]Update on the previous post... That's actually incorrect. My mistake. What happens on mobile devices is this: A touchstart event is fired. 300ms delay. A click event is fired in the same place the touchstart was fired. I doubt you'll have issues with this specific code so long as the only thing that changes is the background and foreground color, but it will be 300ms slower on mobiles. On the other hand, if you do what I said at face value it will fire normally and then toggle back after .3 seconds. The only way around that delay/self-canceling (that I know of) is to bind to both like I said and use event.preventDefault() to stop the click event from firing after the touchstart. Sorry for the bad advice before.
I noticed this was implemented! Thank you. I like what you did. There is an error on this page regarding bold. Unrelated, but probably a notable problem. Please take a look at the OP and see what is causing it.
Thank you very much. Funny you mention it now. I just noticed a bug or two with the code. The click functionality does not work until the page has fully loaded. The click functionality does not work on dynamically inserted posts such as the 'latest posts' loaded when a new post is added to a thread. jQuery offers a way around both of these using the .on() function which can add a click handler to all selected elements, now or in the future. Use something like this to add a click handler to all instances of '.hidden', loaded initially or dynamically: Code: $(document).on("click", ".hidden", function() { // do stuff }); It will solve the initial loading problem as well if it is added to the page header instead of the footer.
