|
Re: black tags
by ww (Archbishop) on Apr 21, 2005 at 18:22 UTC
|
non-compliant with OP's suggestion, in that it uses class "obscure" rather than "black" (This is in keeping with using class_names which describe their purpose rather than their action as advocated by some 'separate content from rendering' gurus (tho I'm not sure I buy it. cf, for example, the oft-repeated perl advice to "use meanful $var names." Yeah, "purpose" could eq "meaningful" but in some instances could lead to the likes of use vars qw( $kill1 $kill2 $kill3... instead of ($kill_print $kill_sys $kill_whatever... so WTH!)
<p style="color: black; background-color: black;">A B C D E</p>
The monastery did not like the attempted-css-demo above when it was in actual paragraph tags, but saving the html below (<!DOCTYPE... etc, omitted) will allow you to view its operation.
typo above cq'ed: s/)with/) will/
<html>
<head>
<style type="text/css">
<!--
.obscure {
color: black;
background-color: #000000;
}
-->
</style>
</head>
<body>
<p class="obscure">abcde</p>
<p>View the chars the blackbox above, by highlighting. Done without
+tables.
</p>
</body>
</html>
| [reply]
[d/l] |
|
|
If you go to your homenode, select "change user settings", go to the textbox entitled "On-site CSS Markup", and paste:
.obscure {
color: black;
background-color: #000000;
}
Then the tag <p class="obscure">
would be viewed as desired. Unfortunately, the tag is useless as an anti-spoiler until everyone does this. sigh. | [reply]
[d/l]
[select] |
|
|
To take it to the next step of using tags to describe content rather than behaviour, the tag would be named "spoiler". And then the CSS could, by default, black it out. And individual users could override that by setting it to do something else. e.g., put the word "SPOILER!" in front, and mark it as blue on yellow. In italics. Or something.
Obscure is an action. Spoiler is a class of text. Mere semantics, but we're accustomed to semantics when naming methods and variables ;->
| [reply] |
|
|
|
|
|
|
|
Re: black tags
by demerphq (Chancellor) on Apr 22, 2005 at 08:20 UTC
|
Sure we can have these. Tell us how we are to implement it and somebody will do it. Otherwise you are at the whims of a pmdever deciding this problem is worth the time and research to figure out how it can be done and then coming up with an implementation. IOW: If you were to include in your suggestion something that I felt was a plausable way it could be done then I might be putting together an implementation right now and not writing a reply.
Issues: how will it be done given that we have a multitude of styles here in play. How will the user control the behaviour, ie turn it on and off or change its looks? Etc. Where will it be documented? A pmdever would be asking What code nodes are involved?
Believe it or not sometime small change requests like this actually take a lot of patches and a lot of work. Just getting all the documentation updated can itself be a lot of work.
Anyway, the point is that if your request contained a large chunk of the research then a pmdever or god would find it a lot easier to knock out your request.
And here is some code!
| [reply]
[d/l] |
|
|
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};
}
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?
| [reply]
[d/l] |
|
|
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.
BTW, the CSS does now support the 'spoiler' class so folks can use that directly if they prefer. see :-)
| [reply] |
|
|
|
|
|
|
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.
| [reply] |
|
|
|
|
|
|
Tell us how we are to implement it and somebody will do it.
$posted_text =~
s{<obscure>(.*?)</obscure>}
{table><tr><td bgcolor='#000000'><font color='#000000'>$1</font></tab
+le>}g;
| [reply]
[d/l] |
Re: black tags
by dbwiz (Curate) on Apr 21, 2005 at 17:25 UTC
|
<table border='0'>
<tr>
<th>You can see this header
</th></tr>
<tr>
<td bgcolor='#000000'><font color='#000000'>
You shouldn't see this text </font>
</td>
</tr>
</table>
| [reply]
[d/l] |
|
|
Sure, It can be done within the current tag set, but don't you find it teadious to type:
<table><tr><td bgcolor=#000000><font color=#000000>
Hidden text here
</font><td></tr></table>
whenever you want to hide an answer.
IMHO <black></black> tags would be sweet! | [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
| [reply] |
Re: black tags
by NateTut (Deacon) on Apr 21, 2005 at 18:08 UTC
|
It would also be nice for those of us who are HTML challenged. | [reply] |
Re: black tags
by Roy Johnson (Monsignor) on Apr 21, 2005 at 22:32 UTC
|
| [reply] |
|
|
Because I can't highlight more than one answer and compare them without switching between two tabs.
| [reply] |
|
|
| [reply] |
Blue tags (was Re: black tags)
by Tanktalus (Canon) on Apr 23, 2005 at 00:12 UTC
|
As long as we're on the topic of wonderful new tags that would be really nifty... Anonymous Monk posted this which, while it was not necessarily the best (nor worst) question, did show something really neat, which cog pointed out. Output in blue. I'm wondering if there were an "output" tag which would do everything like code, except that it would a) not put the contents in the "download code" section, and b) perhaps have some class modifier that could change the colour. Blue is a reasonable starting place, IMO, but that's just a minor detail (and I've already proven that I'm no good at UI design ;-}). Example output would be similar to:here is sample output.
assuming that you don't have the blue theme already in use (which may make that hard to read, or may make it look the same as regular code, I don't know).
| [reply]
[d/l] |
Re: black tags
by eibwen (Friar) on Apr 23, 2005 at 01:55 UTC
|
You cite your argument for the creation of the new macros is:
so that we can easily type solutions to puzzles without bothering others
However, I would consider this a fallacy. I grant I only recently became a scribe, nevertheless I think that such tags would not be conducive to the ready dissemination of perl knowledge. Therefore, perhaps the pertinent question is:
How can we optimize the dissemination of perl knowledge?
This is a complex issue as perl knowledge manifests itself in a variety of forms; however the objective remains the same: to impart (or further) an understanding of perl. I do not purport to know the best didactic method, however I do not think abstractions would be beneficial.
With respect to the notion of a puzzle/quiz thread specifically, why not change the organization so as to better elucidate the solution as opposed to abstracting it within a "spoiler" tag. Furthermore, these threads and their solutions are akin to Categorized Questions and Answers and Snippets Section (and possibly Code Catacombs and portions of Tutorials).
While I enjoy perl puzzles, and often code a solution to a Seekers of Perl Wisdom node as a practical exercise, I think that there are better ways to disseminate perl knowledge than with the inclusion of "spoiler tags."
| [reply] |
|
|
Personally, I hate seeing a solution before even having a try at the problem; that spoils all the fun. But I do admit that having a way to ignore such "black outs" would be nice.
Also, I take it as being too much trouble to hide something creating a whole table just to put a cell in it.
Not to mention the fact that not all Perl programmers know much of HTML, as NateTut pointed out. And even if they do, they sometimes have to think before posting.
I'm talking
<black>solution</black>
against
<table...
er...
<table bg?
<table><tr><td bgcolor="black" ??
See? :-)
| [reply]
[d/l]
[select] |
|
|
Personally, I hate seeing a solution before even having a try at the problem; that spoils all the fun.
Agreed. My point was not that such threads would be necessitated to present the solution, rather that the presentation of the solution be done in a manner conducive to learning perl. Consider:
Q. Perl question of the week.
A. <span class="spoiler">The Solution</span>
versus
Q. Perl question of the week.
A. [id://node|The Solution]
Both methods seperate the question from the solution, but the latter does so without obsfucation (and in my opinion, with a better presentation).
However, in the interest of completeness, for those who aren't as HTML savy and want to use the tags, have you considered adding the "spoiler code" to your user preferences for the text-area default content?
<!--
<span class="spoiler"></span>
-->
The comments would preclude the code from being inserted in every post, yet it would be there as a reminder whenever necessary.
Having said that, HTML is an abstraction. PerlMonks tags are an abstraction of an abstraction. While I have found the [] tags particularly beneficial for intrasite links, I find the proposed <spoiler> tags akin to bbcode, namely a further abstraction. The point being that if one is to learn an abstraction, they may as well learn a productive one. HTML is universal; the proposed <spoiler> tags are not. Consider:
<spoiler></spoiler>
<span class="spoiler"></span>
The proposed tags are slightly shorter, but their use necessitates understanding of HTML (opening and closing tags). The addition of an attribute would require slightly more effort, but as I've said, if you're going to use an abstraction, you may as well use something universal. | [reply]
[d/l]
[select] |
|
|
|
|
|
|
