Spoiler DW-tag

[magibrain]

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%)

Comments

[cheyinka]

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.

[rho]

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.

[axiom_of_stripe]

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!

[cheyinka]

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.)

[fizzyblogic]

+1, I would love this.

[azurelunatic]

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.

[cheyinka]

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.

[cesy]

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.

[archane]

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.

[cheyinka]

"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.)

[green_knight]

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.)

[cheyinka]

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>.

[magibrain]

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