Re: black tags

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

Comment on Re: black tags

Replies are listed 'Best First'.
Re^2: black tags by cog (Parson) on Apr 23, 2005 at 15:29 UTC
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]
Re^3: black tags by eibwen (Friar) on Apr 23, 2005 at 17:39 UTC
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> -->` [download] 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>` [download] 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]
Re^4: black tags by Anonymous Monk on Apr 25, 2005 at 09:10 UTC
Both methods seperate the question from the solution, but the latter does so without obsfucation (and in my opinion, with a better presentation). I disagree with the "better presentation". I prefer the former one. The latter one requires another client-server round, downloading another perlmonks page - with all it's irrelevant stuff like boxes, headers and banner ads. Just for what's often is less than a line of text or code. Very inefficient in user time. It's even worse if you have a post with several replies with masked answers. Instead of getting the original post, and the, say, five masked answers in one HTTP transaction, you need six for the link variant.	[reply]
Re^5: black tags by eibwen (Friar) on Apr 25, 2005 at 15:32 UTC
Re^4: black tags by demerphq (Chancellor) on Apr 25, 2005 at 08:00 UTC
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 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 tags are not. You seem to overlook the fact that with special tags we can all kinds of server side special processing of the contents of the special tags. Doing so with attributes would be much much more difficult, to the point that in my mind it would be impossible. For instance how would you simulate the behaviour of the default "link-and-omit" with attributes and without JS? This is an example spoiler.... --- demerphq	[reply]