42 thoughts on “Pseudo-Redacting Spoilerer

  1. Grfg gb frr vs nyy guvf pbzchgrel nhgbzngvba fgvyy crezvgf zr gb znahnyyl ebg13 pbzzragf gung ner rkgen-fcrpvny, qbhoyr-frperg fcbvyrel.

    dangit.Report

  2. Grfg gb frr vs nyy guvf pbzchgrel nhgbzngvba fgvyy crezvgf zr gb znahnyyl ebg13 pbzzragf gung ner rkgen-fcrpvny, qbhoyr-frperg fcbvyrel.

    Strike two.Report

      1. User error? What’s weird is that it redacted the title of the post.

        I’ll try again. First, write some text. Next highlight it. THen click on “spoil”. Is that right? (That’s what I did earlier, but the code, which appeared in the comment prior to submitting wasn’t there when I opened the edit function.)

        Here goes.Report

  3. OK – something about how Chrome handles the command – even with Javascript allowed on all sites – but not when logged in at site – so some security interaction problem is preventing Chrome users from being able to pseudo-redact their comments. Disappointing but not terribly unusual – don’t know whether it’s practicably solvable yet. Excuse me while I proceed to test Windows/Safari.Report

  4. Interesting and disappointing/annoying: Safari – with additional loading problems – shows the same logged-in vs logged-out difference as Chrome. I’m presuming for now that writers won’t have any problems (since they’re all, already logged in when they write). Clearly a matter for further research!Report

    1. I think I may – fingers tightly crossed – be able to solve the problem by loading the relevant Javascript differently.

      PLUS: GENERAL APOLOGIES FOR INTRODUCING THIS FEATURE WITHOUT HAVING FIRST TESTED FOR LOGGED-OUT FUNCTIONALITY. WAS TOO FOCUSED ON A PARTICULAR CODING PROBLEM AND FORGOT!Report

  5. Last one (further investigation to be conducted off site): Firefox logged out.

    EDIT: OK – either a plug-in conflict or a measure related to defense against cross-site scripting attacks…Report

  6. Since I don’t care about spoilers or profanity, and dislike the appearance of redacted text, I trust you’ll forgive me for having added a line to my standard page filter* that overrides this feature.

    * Some months back I got overly offended about how many pages abused the privilege of using their own fonts and text sizes (I believe that at the time one of my friends had to listen to me rant about page designers who had “majored in ugly, or unreadable, or both”). 500 lines of JavaScript later, my routine view of the Web displays a remarkable uniformity of fonts and sizes.Report

    1. @michael-cain Tho come to think of it, I wonder if you’d like to share that JS code. I could see about incorporating it somewhere/how as a “reveal all button” or option. Might be other customizations you perform that others would like.. Do you write browser extensions?Report

      1. In no particular order…

        I can mail you a copy of the current code. No guarantees about quality or readability. Since it was intended for just me and Firefox, I use GreaseMonkey to launch it, or disable it if I need to see an unmodified version of a page. I’m sure it could be turned into an extension. If you wanted to adapt the strategy for a “reveal all” button, you’d only need a tiny fraction of the code.Report

        1. A “Reveal” function would be simple. I might make a button or toggle that a writer could insert in a post, or was automatically inserted in a certain kind of post, that when clicked would simply remove the pseudo-redaction. Could also make the color of the “redaction bars” adjustable for those who find the blackness unappealing. Could add an option to make it really redact, and could accomplish that in different ways. Alternatively or additionally, could add it as an option to the suite of comment-handling features I’m developing.(These all point to making more of this thing, not just for this site.)Report

          1. Yeah, none of the individual pieces are hard. Integrating them all into a nice general redaction capability, somewhat harder, especially if/when they end up interacting with other capabilities from other sources.

            The most surprising result from my little experiment is how consistent I can get the Web to look by the simple expedient of iterating over the text items on a page, looking at some of their calculated style values and what type of block element they are embedded in, and then changing the style values. A handful of rules to deal with small exceptions to the general handling on complex pages that I visit a lot (eg, newspaper front pages like the Washington Post). The only two sites that I don’t apply the script to are (1) Facebook because from time to time their JavaScript and mine get into a thrashing problem changing styles back and forth and (2) the Denver Post, who classes everything and has CSS rules so specific that they overrule anything you can do with the style attribute of the actual element.

            The other day I changed the preferred font to ‘Comic Sans MS’ just to see what it would look like. Spooky — especially the New York Times.Report

            1. There are designers devoted to the perfection and propagation of unique, attractive, expressive fonts, who would look somewhat askance at your efforts.

              I imagine that an application that would make the whole web Comic Sans could be marketed as internet Thorazine for people annoyed or overwhelmed by the vast varietousness of the web… setting aside a small number on the edge of psychotic breaks who might be pushed over the line.Report

              1. There are designers devoted to the perfection and propagation of unique, attractive, expressive fonts…

                Yes, there are. Unfortunately, they are lost in the sea of designers who think there’s nothing wrong with using four different serif and three sans serif fonts, in a total of eight sizes ranging from 4px to 36px, plus bold and italic, all on the same web page. I don’t think it’s all intentional, so much as months/years of accumulated cruft from old CSS — the “three redesigns ago there was a reason to specify a particular font for subheadings” sort of thing.

                I know a couple of people who read the NYTimes regularly, who would probably be pushed over the edge if it were rendered in Comic Sans. Hmm… how to sneak a version this script into their browser…Report

  7. Do you mean to tell me that I suffered through over six seasons and 120 episodes to find out that everyone was just dead the whole fishing time?Report

  8. Testing possible fix to place redacto-bars on excerpts instead of the “SPOILERED CONTENT” notice… Got unexpected end formatting, want to see the cause is so needed a somewhat slightly longish test comment.

    EDIT: Slightly kludgey fix seems to work, not sure if worth perfecting…Report

  9. Just a generic “new feature” comment… I wasn’t sure about the new Commentariate page when it was added, but now I’m getting addicted to it. Well done.Report

    1. Thanks – much appreciated! It’s my own front page for the site most of the time now, and I’m still discovering little undesirable display peculiarities – a few of which I still haven’t fixed – that I probably never would have noticed on a development site.Report

      1. What the hell… Here’s an example of the small changes that my reformating script makes to the site content. The top part is one row of entries from the Commentariate page without the script, the bottom part what I see after the script runs. Some of the changes are obvious — line spacing is the same whether the comment fits entirely in the box or not, and the font size and character spacing on the author name. Less obvious is that there are actually two fonts in the upper version (some elements honor my browser preferences, some don’t — fishing CSS specificity…) and one in the lower, and some small line and character spacing changes.

        The changes are a lot more dramatic at a site like The Atlantic, where they tend to go overboard on fonts and sizes and funky spacing.Report

        1. Firefox, virtually the same on Chrome:

          The difference in padding (extra lines) is one thing that I intend to get around to, but you’ll see that the line spacing is the same on both. I wonder if it’s a peculiarity of your browser or other aspect of the set-up that produces the more radical difference in yours.Report

          1. I do have not only the preferences that can be reached through the Firefox user interface set, but a small userContent.css that sets some additional values. Absent that CSS file, probably more of the values specified by the page get honored when the script’s not running. I don’t keep a copy of Chrome around, but have noticed that Firefox and Safari (with the same preference settings and user CSS file) give somewhat different results.

            There’s still enough ambiguities in calculating CSS specificity, and how to handle stuff like !important, that it’s a miracle if you can get all of the major browsers to render something with complex CSS (lots of nested id and class properties) the same.Report

Comments are closed.