demerphq, thanks for the patches. I wanted to comment on them here so the comments would be public.

I think what you've got is a pretty good start. In previous discussions (such as Re^2: formatting spoilers (not perfect)) other ideas were brought up that I think are worth including.

First, I'd factor out the 3 copies of identical (I believe) code so we can make improvements easily.

The basic method you chose is the correct one, IMO, including where in the process you process them (after CODE tags but before HTML filtering):

   my $spoiler_pat = $VARS->{spoiler_pat}||
      "<table><tr><td bgcolor='#000000'><font color='#000000'>".
      "%TEXT%".
      "</font></td></tr></table>";
   while ( $text =~ m{<spoiler>(.*?)</spoiler>} ) {
       (my $repl = $spoiler_pat) =~ s/%TEXT%/$1/;
       $text =~ s{<spoiler>(.*?)</spoiler>}{$repl};
   }
[download]

I wasn't fond of the %TEXT% magic string but I've since worked out how to make it not a problem, IMO (see below).

I'd like to have a few predefined choices like:

• Color-X text on color-X background via TABLE
• style="spoiler" via DIV w/ default black-on-black in site CSS (white-on-white for dark theme)
• Just READMORE (readmore processing needs to move for this and other reasons)
• Just a link to reveal the spoiler(s) via ;spoil=1
• A link but also include the spoiler in HTML comments (works cool when the spoiler is in CODE tags)

I'm not saying all of this needs to be implemented before you apply any patches. But I'd like the path for this design worked out well enough that patches that get applied won't be likely to get in the way of such an eventual solution (or something better based on discussions).

BTW, I'd like user settings to mostly become a set of links to other pages that aren't so huge, so I'd put this on a separate page, perhaps will other "node display" settings like text depth and "disable readmore" (maybe also CODE tags settings).

So, how to best implement the interface and the mechanism?

After bouncing around a few ideas, I think I'd have a form with a drop-down list of standard types and a field for filling in either a non-default color (for the TABLE method), non-default text to preface the spoiler (for DIV), or non-default text to use for the link that reveals the spoiler (for HTML comment and "omit")? These would populate the template and then the user could customize that (or just fill in the template directly). The settings page should show a sample spoiler. Spoilers would default to TABLE method for new users. Update: Actually, "link and omit" should be the default, as it would even work on my cell phone.

So the code to factor out would be nearly identical to what you wrote, except that it would simply remove the spoiler tags if $q->param("spoil") was set and it needs a way to fill in the current node ID for making the link with ;spoil=1 added.

Comments?

Ive refactored the parselinks stuff into a single node called ParseLinksInContent. It has a prototype implementation of a spoiler tags, currently defaulted to do the link and omit strategy. I havent touched User Settings yet, so there is no way to control the style of the link. Ill get to it if nobody else does. You can use the param 'oldparselinks' to revert back to the previous behaviour.

<Reveal this spoiler or all in this thread>

BTW, the CSS does now support the 'spoiler' class so folks can use that directly if they prefer. see :-)

---
demerphq

Bravo, demerphq ++
<Reveal this spoiler or all spoilers in this node or all in this thread>
 is grounds for a heartfelt "thank you++"
<Reveal this spoiler>

Ok, ive taken this to step 2. I created Display Settings as the new settings page, and added support for selecting the way spoilers are rendered. I haven't added the textbox feature yet as I havent really decided/figured-out how it should work and what should happen. For instance if the style is table how should the user provide the colors? as a semicolon seperated string? Likewise the text for the link and div and table modes, where would it go in the template?

Anyway, as part of this I created a new nodetype called user_superdoc that restricts access by annony monk at the htmlpage level and not in the code itself. IMO all of the settings superdocs should be switched over to this type (but I havent done so yet).

Lastly, it wasnt clear to me the way that stuff on User Settings should be extracted and grouped. My attempts at Display Settings are just an initial attempt at some such restructuring, and accordingly i havent modified User Settings at all. I welcome feedback or help in restructuring things.

---
demerphq

For instance if the style is table how should the user provide the colors? as a semicolon seperated string?

"Colors"? The foreground and background colors need to be the same or there is no point so the user only specifies one color, in whatever format their browser supports. So they could say "white" or "black" or "#cccc33" or whatever.

Likewise the text for the link and div and table modes, where would it go in the template?

Just provide one value to be optionally overridden and if they want to override other parts, then they can edit the resulting values (as I mentioned).

- tye        

Nicely done! ;)

I just wanted to mention that links to reveal all spoilers up with the print /replies, code, xml, spoil would be cool


___________
Eric Hodges

$posted_text =~
s{<obscure>(.*?)</obscure>}
 {table><tr><td bgcolor='#000000'><font color='#000000'>$1</font></tab
+le>}g;
[download]