dw_suggestions | Spoiler DW-tag

Entry tags:

Spoiler DW-tag

Title:
Spoiler DW-tag

Area:
DW custom tags

Summary:
Add a tag to easily add spoilertext to a post.

Description:
I suggest a [spoiler][/spoiler] tag which would automatically generate spoilertext (often black text on a black background, so that a user can choose to highlight it to read it), with a hidden-from-screen-display but screen-reader-accessible (possibly using WebAIM's hidden content trick - http://webaim.org/techniques/css/invisiblecontent/ ) link to skip the spoilered content. The rough format I've been using in my posts is this (brackets flattened because preview didn't like < and > codes):

[a href="#skip_spoiler_1" style="width:1px; height:1px; position:absolute; left:-10000px;"]skip spoiler[/a][span style="color:#000; background-color:#000;"]SPOILERS SPOILERS SPOILERS[/blockquote][a name="skip_spoiler_1" /]

It seems that the following code:

[spoiler]SPOILERS SPOILERS SPOILERS[/spoiler]

would be much cleaner, and guarantee accessibility for people using spoilertext who might not otherwise consider screenreaders.

As for drawbacks... I'm not sure how many people actually use spoilertext on a regular basis, I don't know if color choice would be controversial, I'm not entirely happy with the disparallel between functionality for sighted and screenreader-using folk (where people reading visually have to take action to see the spoilered content, but people using a screenreader have to take action to *avoid* being spoilered), the outputted HTML is still a little bloated, the trick to not display the skip link is a kludge (because screenreaders have erratic handling of both visibility:hidden and display:none), and I imagine it would get extremely ugly if used on a large patch of text. But it'd be cool to hear discussion on any/all points. :)

Poll #9002 Spoiler DW-tag

Open to: Registered Users, detailed results viewable to: All, participants: 101

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
46 (45.5%)

Should be implemented with changes. (please comment)
22 (21.8%)

Shouldn't be implemented.
10 (9.9%)

(I have no opinion)
22 (21.8%)

(Other: please comment)
1 (1.0%)

Flat | Top-Level Comments Only

This was previously suggested at http://dw-suggestions.dreamwidth.org/31862.html and rejected for being something that couldn't be implemented in a way that would be usable for all users (mobile devices in particular) and for being something that could be achieved through other means. I'm letting it through for rediscussion since it's been two years or so since the last discussion and somebody may have a good argument to overcome the problems!

I don't know about accessibility for all users including mobile, but I do know that people are currently hacking this up on their own, and those versions are likely to be less accessible than anything DW comes up with. For example, I see people who chose to set the background but not the foreground, not including a "skip" anchor for screenreaders, etc. This happens already. Better to have a DW version of it that uses current best practice, and encapsulates workarounds for platforms with potential difficulties, than have everyone hacking up things that are less good.

Implementation note: given that it would only have to be written once, centrally, the spoiler code can be far more complex than individuals usually use. That means we can include, say, iOS-specific stuff for iPhones/iPads (which can't highlight-to-read), and so on. I'm not a front-end web developer of any kind, let alone a mobile web specialist, but it seems to me that a simple javascript onClick which removes the special styling might do the trick (on iOS at least).

Another note re: colours... in the previous suggestion, people suggested black/black with a white border as a universally viewable scheme. As a reader I happen to prefer grey/grey, but that's irrelevant, because presumably it'd have a CSS class on it that could be styled via the usual means (i.e. DW styles or custom CSS). So remember that whatever colour combo we're talking about would just be a default, not a universal. (And if someone wanted to always see the spoilers, they could in theory set the CSS to make it readable rather than obfuscated.)

Regarding colours... I think hard-coding colours would be a Bad Idea because everyone has different preferences (should it be dark/dark with a light border or light/light with a light border, and should it be black and white or dark and light shades of grey); and since we (very easily) have the capability to be more flexible, it would be wise to do so. I'd style it with the spoiler block background colour being set to the text colour, ie.:

spoiler {
    background-color: $*color_entry_text;
    color: $*color_entry_text;
}

Text and background colours are set to be different (obviously, as otherwise the text wouldn't be readable), so this way the spoiler block would be easily distinguished from the background and would be consistent with any theme being used.

It could also be done using by setting the text colour to the background colour, though this would make it unclear where the spoiler block is in some cases. A border (say in the text colour, or in another theme colour) could help there. Though my personal opinion would be to set the background colour to the text colour, as above.

Agreed, having it centrally done is better. No solution is going to be perfect for all platforms yet, I don't think.

(The on-click for iOS, while it would let you view the spoilers, would lead to unwanted spoils for some people. It's way too easy to 'click' when you were trying to put your finger down to 'scroll' - I follow a decent number of links that way and have to abort them or go back. But I think the on-click is probably still the best solution. It'd be nice if you could click again to re-hide, that way if you see the block of color turn to text you *might* be able to make it go away before you registered what it said....)

I think you have to do a javascript onclick method for this, or else too many people either can't see the spoiler text or they see it even when they don't want to. Taking some points from other comments...

So what if:

The spoiler text starts out visibility: hidden so there's space for it in the layout, but no one sees it. It shouldn't show up in plain text or in an email content version of the post (some people email themselves posts so they can read them not logged in), screen readers don't read it.

Only those people who want to read it can make it appear by clicking a button the code inserts in front of the hidden content. Click it again and it's hidden again. This way the spoiler text can just be in the default content colours and you don't have to fuss about colour combos. It could be made visually distinct with a text-colour border or something if you wanted to make it obvious that it's special text.

Drawbacks:

You'd need functional javascript to get it to show up.
A miss click shows the spoiler.
Might not work on every device? I'm pretty sure screen readers will read something made visible by JS in this way, particularly if the button is before the spoiler text, but do all devices?
Inserting the button into the post takes up space the post creator might not be expecting to be used.

I see this as something that's best achieved by extending the functionality of the cut tag, rather than by adding a new tag. As it stands, the cut tag can already be used to have text be hidden by default but shown after an action by the reader, which seems to fit the bill perfectly.

So, what problems currently exist that stop it being used that way? The largest is that the page for a specific entry (eg http://dw-suggestions.dreamwidth.org/1303478.html) automatically expands all cut tags. If this behaviour were changed, would that work to take away the need for this? What other problems are there that make people want to use this method of hiding spoilers rather than the cut tag?

I wouldn't want to see the page for a specific entry keeping the cut tags - if I'm clicking a link to an entry, especially if I'm clicking a cut tag rather than expanding it inline, I want to see the whole entry. I suppose the spoiler-tag could essentially be the same thing but invoked differently and handled differently, though; I wouldn't have a problem with that.

It wouldn't be too difficult to work around that. For instance:

Add an ?expand=yes argument to the URL.
When this argument is present, all cut tags will be automatically expanded. When absent, cut tags won't be expanded.
When following the link in a cut tag, the argument will be automatically appended.
Entry pages could also have an "expand all cuts" thing in the same way that the reading page does currently.

The advantage of this is that it works for more than just spoilers. For instance, if I use a cut tag as a trigger warning, this is negated if anyone is linked directly to the entry, or if anyone wants to comment on an uncut portion of the entry. Ditto with using a cut to hide spoilers. The "black on black" (or any other colour) is workable for short snippets of hidden text, but when you end up with paragraphs hidden that way, it gets awkward and ugly.

I'm totally with you in not wanting to go through a lot of hassle to get at cut content, but I don't think this is an insurmountable problem. And since it bugs me that I might have to see, possibly triggering images, say, if I want to comment on an entry, I think trying to solve the more general problem is better than concentrating on a single narrow use case.

When following the link in a cut tag, the argument will be automatically appended.

I like this idea, but the problem here is that clicking on the cut text would then automatically show spoilers/other hidden content, which I don't think would be the expected behavior. Also, the "expand all" command on a reading page would also show the spoilers.

Maybe something like a <cut text="foo" spoiler="yes">, to indicate a cut which shouldn't ever be auto-expanded, only manually expanded?

I definitely like this idea, though, because it offers the ability to hide IMAGES as well as text, which is often forgotten!

I'd be okay with spoiler="yes", especially since it could be used to hide images, like you said. (It might be easier if <spoiler text="bar"> were synonymous with <cut text="bar" spoiler="yes">, I suppose.)

+1, I would love this.

I really like the concept, but the thing that's making me balk now is using the terminology "spoiler" for a property that could and very immediately would be used for serious things like trigger warnings and hiding the sort of stuff that you can't unsee, and fun but not spoilerish things like games, or huge/pagebreaking images, or even tl;dr out of courtesy for a friend who you know is reading from their phone.

If this happens, and I hope it does, I would want it to be called something that is very clear about the effects of the feature, and then leave the suggestions on use (spoilers, trigger warnings, etc.) for a FAQ.

I'd also like a nice large "expand all concealed items" or some such toggle, as a very easy way for someone who wants to view everything to not have to deal with, say, 25 concealment tags which were someone's idea of being cute.

Having it be textually and visually distinct from the standard cut-tag could be useful as well.

Maybe <cut text="blah blah blah fishcakes" conceal="yes">? It describes what it's doing (concealing that cut even when the entry is open), doesn't change base functionality, and doesn't call itself a spoiler or a trigger warning or a page-breaking-image-hider.

This sounds good to me, and "mask" sounds like a good term for it. I'm in favour of it being converted to the best spoiler code we can when sending to LJ, and working in comments as well as entries.

In email notifications it would need to work like spoiler text rather than a cut, though - I'd want to be able to read it by highlighting within the email.

I also like the idea of this being an attribute of the cut tag, where the default behavior functions as it currently does, but an optional value which wouldn't auto-expand when the entry page loads. I agree with

azurelunatic, though, that it should be named something other than "spoiler" so that it indicates function rather than a single type of use.

"Cuts don't stay cut when the entry page is opened" is expected behavior for me as well as being what I want to happen, and I don't think that should be a problem that Dreamwidth fixes, because I don't think it's a problem and fixing it would cause me problems.

If the problem is "we need spoiler tags that are both accessible and easily invoked", I think it's better to have a new tag; it could work exactly like a cut tag, except that going directly to an entry page wouldn't unfold the spoiler tags, and spoiler tags could be used in comments. (Or it could be totally unrelated to how cut tags work, but I like the idea of being able to hide images as well as text, and a repurposed and renamed cut tag could do just that.)

I'd prefer it to extend the cut tag behaviour, for the simple reason that I'm crossposting to LJ, and accidentally leaving content completely uncut would not be a great idea.

I like the idea of adding an 'autoexpand' flag to cut texts, because I often make posts where I ask people about their immediate reactions to something - and then add my own reaction in a separate post, so it won't influence their reaction. Being able to do that in one post - with cuts that stay closed even on the posts's page - would be awesome.

Hm. 'autoexpand=none' for cut tags that stay cut, 'autoexpand=rlist' for cuts that get closed on the reading list and expanded in posts (standard behaviour), 'autoexpand=all' for content that I want people to see on their first encounter, but which is long enough they might wish to hide it? (I sometimes choose not to use cut tags because I want to make it harder to skip posts. So sue me.)

Well, if it gets a new name, like <mask text="fishcakes">, the crossposter could be smart enough to convert both <cut> and <mask> to <lj-cut>.

Does LJ handle nested cut tags at all? In case someone wanted to mask something under a cut.

I think anything that worked like this should also be implemented with the option of a "trigger warning" flag (which it would be useful to have the option of keeping collapsed on entry pages).

Perhaps <mask type="trigger"> with "spoiler" as another possible type?

+1 ( this is my with changes )

I incline to "Yes", with

laitaine's method of choosing colours, but

rho's alternative solution might be better. I think people using visual browsers and mice expect to see highlight-to-read spoiler text because that's what you get elsewhere, and it's pretty easy to code ... if you don't care about accessibility. I've got a bookmark to the cheat-sheet for an accessible method, and it's really complicated. A pseudo-html tag would take away a lot of effort in applying the cheat-sheet, and could be updated if new methods became available, but it would still be some clumsy-looking code. An extra parameter on a cut-tag to make it stay closed unless specifically opened would be spiffy.

I think having a DW-default way of marking spoilers would be really nice, honestly. Even if it isn't the most accessible thing ever, it's still going to be more accessible than what people come up with on their own. I know I'm too lazy to ever do more than font color="white", and I know that's a terrible way to do it.

I'd be mildly against a cut-tag version of this, at least implemented as specifically spoilery. I assume it'd have to be expanded into being able to cut comments, and that's going to run into problems with the expand all comments feature and people using it to cut pictures and other non-spoilery uses, and while I don't necessarily object to that, I think that's a fairly different suggestion that I haven't really thought out enough to properly say. And my prior experience in anime forums is that cut tags labelled specifically as spoilers bug me to no end when people promptly start using them for non-spoilery reasons, even when I agree with the non-spoilery reasons. So I'm a little wary.

I agree with the point about in-comment spoilers.

That's a good point about wanting something that will work in comments!

And that's also a good point about "spoiler" cuts turning into things unrelated to spoilers -- however the feature works out, it should probably be named by what it does instead of which problem it's designed to solve. Something like "strongly hidden" or "never auto-shown" or something catchier instead of "spoiler", so it's just as relevant to those other problems it'll inevitably end up solving as well.

I think the point about spoilers in comments as well as posts is a valid one, and I'd like it to be flexible so it can be styled according to the user's preference, and ideally I'd like a 'reveal' button for it (and a '?reveal=all' setting - if I don't care about spoilers, or have already read them, I'd like them to stay put.

If the technical and accessibility issues can be surmounted, I would love and regularly use a spoiler/trigger pseudo-tag; as it is I have to open a file where I've stored a template for one that I got from a friend of a friend somewhere some while back...

I think it would be a very useful feature, though I have no strong feelings about how it is implemented.

It would be good to have it work in such a way that cross-posting didn't break the spoiler protection, however that might work.

I think it shouldn't be called a "spoiler" tag, since it could be used to mask triggers and other things that aren't spoilers. Maybe just "mask."

As far as issues of accessibility, I don't have any solution to suggest for that.

But FWIW, I'd like to have an easy way to do this, rather than playing with colors and various scripts.

+1 to "mask", that's a great word for it!

( It's so cool that everybody thinks about accessibility of suggestions here! \o/ )

I do like this idea and I do agree that even if we can't implement it perfectly for everybody that we'll probably end up with something that's better than what's already being hand-coded in many cases for spoilers and potential triggers.

"Mask" is a great nonspecific nonnegative term to use and leaves the field open for users to find other uses for it as well, as they always do!

I do think that this is a separate use-case from existing cut tags because it's often used inline in the case of fic headers especially, for example to hide warnings that the reader may not want to use. Cut tags are great for hiding a paragraph or more but really awful for hiding just a few words which are part of an otherwise visible paragraph. This is akin to the HTML division between 'div' and 'span' in my head. Whether it's implemented using the shortcut of <cut type="inline" ... or as another different tag <mask ..., the use case *is* currently different and I think it should be considered as such. It does occur to me that as inline-expanding cut tags evolve and this (if implemented) evolves they may eventually come together in the future and re-merge. In that case, forming the tag as an argument (etc.) to our existing <cut tag would give us the greatest future freedom to change the implementation without confusing people more than is absolutely necessary. The one accessibility use case which hasn't been discussed (as far as I can see upon quick skim) is keyboard-only users who don't use either screen reader or mouse. For these people an "unhide" link or button (perhaps a magnifying glass icon?) which displayed inline before the hidden text may be a solution - this could possibly also help certain mobile device users? I will defer to actual UI designers for how this should look, but I will note that keyboard-only users will not be able to trigger a JavaScript "onClick" block whereas they would be able to trigger a href containing a Bookmarklet-type JavaScript block. This information needs to be confirmed with keyboard-only users and screen reader users, of course! It's academic knowledge to me as I don't use either technology. r

I would really love an easy spoiler tag that did the right thing for screenreaders/mobile/everybody. Failing that, I'd like something that did the right thing for as many groups as possible, because the status quo is more bunk than pretty much any of the alternatives.

(I found something tonight that works great on mobile and desktop without needing Javascript, but readers won't get the benefit unless they view the entry in my style, and I won't get the benefit unless the folk I read write their spoiler tags so they'll work with my reading page. That's kind of frustrating.)

azurelunatic suggested integrations with the [lj-spoiler] tag. [lj-spoiler] does work in comments, and Dreamwidth doesn't currently have a cut-tag for comments. This is something I would find useful, and also something that I would be interested in contributing development effort to (though I would need help on where to start!).

Flat | Top-Level Comments Only

Spoiler DW-tag

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

suggestion: [lj-spoiler]-type cut with LJ integration