http://www.perlmonks.org?node_id=328276


in reply to Re: Site HTML filtering, Phase II
in thread Site HTML filtering, Phase II

The only hard part is remembering which of the less common but harmless and useful HTML tags don't work.
No, no, no. The hard part is finding out which elements are named the same in both HTML and Perlmonks, but act differently. <code> for instance means something else in HTML than in Perlmonks. But I still haven't figured out how the <a> element is working on Perlmonks. Sometimes, it creates a link. Sometimes it appears as is.

That, and remembering the entity for escaping the left square bracket. (I usually just put code tags around it. Easier to remember.)
Easier to remember, but not easier to type. Having to type 13 extra characters to be able to type a common character in Perl isn't what I say "easy". At least in POD, you only need three extra characters: C<[>. And in POD, you don't even have to put any markup around a function() or a $variable. POD knows.
If you want to see some needlessly complicated and gratuitously different site markup, have a look at Wikipedia sometime.
Actually, I've contributed some bits to Wikipedia the last week. I vastly prefer the [[link]] syntax over [link] as it means one can use unescaped left brackets if they aren't followed by another left bracket. [..] is common when discussing perl. [[..]] is a rare appearance in Perl code. I also prefer mechanisms like ''foo'' or *bar* to make something emphasized/italics or strong/bold, like Wikis or news/mail readers do.

Abigail

Replies are listed 'Best First'.
Re: Re: Site HTML filtering, Phase II
by theorbtwo (Prior) on Feb 11, 2004 at 16:05 UTC

    There is only one "tag" that behaves differently on PM vs elsewhere, and that is <code>. <readmore> is an additional pseudo-tag, but has no meaning in normal HTML. (In fact, we make use of the fact that it is meaningless in normal HTML.) I have no idea what behavior you're seeing with <a>; if you give me further information, I can attempt to explain. Perhaps you'll trying to put it in a place where all HTML is escaped.

    As to <code>[</code> being difficult to type, you're correct, it is. However, it's rare to mention the [ character all by it's lonesome. When you do, &#91; is not difficult to type, or to remember. Code tags are useful semantic information, and allow for better visual cues. Please, don't abuse them for formatting.

    Allowing input-as-POD, or another semi-plaintext format is easy to do wrong and difficult to do right. So far, we've done pretty well, I think, at not doing things wrong.

    Having a tag like code that says "things inside this tag are PODish" is an interesting idea, and I may get around to taking a look into it at some point, but many, many, many things are higher up on my todo list.

    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

[reply]
      <a href = "http://people.ku.edu/~nkinners/LangList/Langs/P/PEARL1.htm">Try this. I've also have had problems in the past where the only way to get an <a> element to be accepted was to remove the spaces surrounding the =, but I can't remember exactly where I tried to link to, and I can't reproduce it.

      Abigail

[reply]

        Ah, thanks. My initial diagnosis is that the bracket expansion is happening first, and then the html screening, and the screening after, and you're ending up with quote-within-quote problems, which the html screener throws it's hands in the air about. This could be completely wrong. In any case, URI-encoding or HTML-encoding the inital [ fixes it. I may use this as a test case to unravel tye's new code at some later point; I suspect figuring out just what goes wrong and how to fix it will take me on a nice tour of the code.

        Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

[reply]

        Tricky URL to try to link to. You could escape the brackets in the URL and use <a href=""> or the Monastery "in-house" brackets:

        [http://people.ku.edu/~nkinners/LangList/Langs/P/PEARL%5B1%5D.htm]
        yields
        http://people.ku.edu/~nkinners/LangList/Langs/P/PEARL%5B1%5D.htm

        But i am afraid that linking via [http://people.ku.edu/~nkinners/LangList/Langs/P/PEARL[1].htm] is not possible, not even with <a href=""> ...

        But i did make a link to the page. ;)

        jeffa

        L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]
      When you do, &#91; is not difficult to type, or to remember.

      I want to live in your universe.

      When I was an Initiate (and a Novice, and an Acolyte...), I kept &#91; on my scratchpad, so that I had an easy way to find it. However, I discovered that however I put it, it would either be visible when I viewed my scratchpad in a textedit box, or else it would be visible when I viewed it the regular way. So I put it both ways (with the ampersand escaped or not). I was hoping that eventually I would just remember it, but I keep getting it confused with the entity for single quote (which I *have* to remember, for non-Perl work-related reasons), confusing it with other random ASCII character numbers, and otherwise mixing it up and getting it wrong. So I had to consult my scratchpad for the correct number nearly every time.

      Eventually I needed my scratchpad for something else, so I gave up and started putting the left square bracket in code tags, which was so much easier (not having to consult my scratchpad every time I post anything) that I instantly became addicted to it. This is where I stood until this thread; now I have arranged to have the entity in my signature for easy reference :-)

      If there were an easy pseudoentity for it, such as &lbracket;, I would use that instead. Or maybe *eventually* I'll memorize the numerical code for left square bracket, but with all the other ASCII codes floating around in my head for one reason or another, that one has a tendency to get lost.

      Read more... (499 Bytes)
      I guess I don't use it quite often enough. Plus, numbers are much harder for me to remember than words.

      The real problem with escaping the left square bracket, though, is for newbies. The entity for it is (not surprisingly) not on *any* of the usual lists of HTML entities. It's not on the htmlhelp.com lists, not on the w3schools lists, nowhere. Nor is it documented in the FAQ here. You've got to drag out an ASCII chart. This is not newbie-friendly. update:Hmmm... It *is* listed in the "how to escape" thingy that's linked from preview, though; how come I never noticed that before? I could have saved myself all that messing around with my scratch pad.

      ;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print
[reply]

        OK, perhaps I'm overstating it a bit. It's not that much harder then &lsb;, &lbracket;, &ob;, or whatever, would be, and has the advantage of being a real HTML entity, and not something we just made up.

        It took me a long time to be able to remember it too.

[reply]
2Re: Site HTML filtering, Phase II
by jeffa (Bishop) on Feb 12, 2004 at 01:59 UTC

    I have been quiet on this matter, but i have to pipe in and say that replacing [ .. ] with [[ .. ]] is a SPLENDID idea and you hit the nail on the head why it is a better fit for this site. (typing &#91; is a royal PITA!)

    There seems to be two major problems (barring having all pages be W3C compliant (X)HTML)

    1. newcomers not knowing how to format code sections
    2. folks using "unescaped" [ .. ] sequences, inadvertently producing potential Google hits to their array indices.
    I think that getting newcomers to use code tags will always be a problem ... but switching [ .. ] to [[ .. ]] should completely alleviate the need for "inline" code tags, such as $this->[$example].

    As for using POD ... newbies have a hard enough with programming, let alone Perl. Offer them POD and watch them run screaming ... maybe not a bad idea after all ...

    My stock answer for posting with POD is pod2html | perl -pe 'custom filters here' | tidy which has served me quite well for several of my larger, premeditated posts.

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]

      Now all you have to do is convert a few hundred thousand nodes to this new standard... not a small number of which are nodes used to implement the site and that contain Perl code (sometimes in templates -- BTW, the templates use several flavors of square brackets for designating different types of code) and some of that code emits square brackets because it knows they'll be turned into links... well, and a few other tasks will also be required...

      Having written POD, I'm convinced that the problems with < and > would be worse with POD than the current problems with [ and ]. And I bet the problems with URLs would be worse as well (I've certainly heard several people get frustrated trying to make POD link to URLs). I find it mildly humorous that the problem of using C<...> to surround Perl code (which has lots of uses for < and >) was "improved" by adding support for C<< ... >>, since Perl code also has several uses for " <<" and " >>", and such uses rarely nest. But then I haven't had reason to study the new POD yet. And I'm not trying to bash POD. I like many things about POD.

      I also think PerlMonks should take a few good ideas from POD.

      And [[ ... ]] is a fine idea. We could even add support for it. But that won't do much good since it won't really help until we can remove support for [ ... ], and I doubt that is going to be in the ballpark of either quick or easy.

      I'll continue working on making this site work better. The handling of HTML(ish) and [ ... ] has improved quite a bit over the last few years and several more improvements are already begun. There are certainly still bugs and other room for improvement.

      [ ... ] parsing should probably be merged into the HTML filtering (since some people expect to not have to escape square brackets inside of links even though they have to escape them most other places at PerlMonks) and we already don't have to escape < and > most places, including inside of square brackets. There's a good chance I can do that without increasing the cost of the filtering considerably.

      I think new users should have "[possible link]" displayed as "[possible link]" so the problem of forgetting to encode your brackets is less severe. I think we should support &lsb; and &rsb;.

      I'd rather use [[...]], but I don't currently see a path to it that is worth persuing. This is probably where someone will suggest starting over. Feel free. It's a great idea and I'd love to see it happen. However, I have no interest in working on it myself.

      I'll be watching to see what schemes for solving the backward compatibility problem get posted, and the back of mind will be thinking about it as well.

      - tye        

[reply]
[d/l]
[select]

        I came up with an idea that I might like for moving forward regarding this type of change. I'd add a field to the node table for 'format' and a corresponding user setting.

        All existing nodes would be tagged 'e2'. New users would start at 'pc' (which would be like simplified POD: preserve blank lines and treat paragraphs containing indented lines like code). When you compose a node, it'd default to your selected input format but you could select another.

        But trying to support too many input formats would probably be a mistake, so new formats should probably be added slowly and deliberately.

        Just the start of an idea...

        - tye        

[reply]
        &ob; and &cb;, please.
[reply]
Re: Site HTML filtering, Phase II
by jonadab (Parson) on Feb 12, 2004 at 12:38 UTC
    The hard part is finding out which elements are named the same in both HTML and Perlmonks, but act differently. <code> for instance means something else in HTML than in Perlmonks.

    code tags are something I use often enough that they're not hard to remember.

    But I still haven't figured out how the <a> element is working on Perlmonks.

    Hmmm. I haven't run into that one. As near as I can tell, it works like in regular HTML. Must be I just haven't tried the right (or wrong) thing yet.

    Easier to remember, but not easier to type.

    Agreed, I find having to escape the left square bracket annoying (I did say it was one of my two pet annoyances on pm, didn't I?), and doing the editing in a browser textarea control instead of a real editor doesn't help this any. Sometimes I'm tempted to do a whole post in Emacs and copy-and-paste it over. Sometimes I do that. I suppose the bracket syntax for perlmonks was taken from E2 and/or Wiki, but I've always wondered why the same things couldn't be done with angle brackets...

    How It IsHow It Could Have Been
    [jonadab] <node jonadab>
    [id://328276] <id 328276>
    [cpan://Net::Server::POP3] <cpan Net::Server::POP3>
    [Newest Nodes] <node Newest Nodes>
    [weird syntax >= escaping] <node "weird syntax >= escaping">

    However, retrofitting those changes now would be quite painful, as all existing nodes would be impacted (and that's ignoring developing and testing the code for the changes).

    At least in POD

    Please, no POD. I do *not* want to try deal with significant whitespace in a feature-impoverished browser textarea, and if you think getting newbies to use code tags and whatnot is hard with an HTML-like markup, just you think about trying to convince newbies who want help with PERL that they should post their question with POD markup. Gah. Gives me the heebie-jeebies just thinking about it. 

    $;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/

    [download]
[reply]
[d/l]
[select]
      Please, no POD. I do *not* want to try deal with significant whitespace in a feature-impoverished browser textarea, and if you think getting newbies to use code tags and whatnot is hard with an HTML-like markup, just you think about trying to convince newbies who want help with PERL that they should post their question with POD markup. Gah. Gives me the heebie-jeebies just thinking about it.
      An option to post in POD doesn't mean a requirement to do so. If Perlmonks were to allow posts in POD and/or plain text, I'd imagine a drop down box, or a radio button next to the textarea to flag the format of the posting. Defaults could come from a user preference, or from the users last post. I'd also imagine a heuristic that classifies the posting with a great degree of accurancy, and relative simple ways for the poster to force a markup style if the guesser guesses wrong. (Say, a post starting with <html> is in HTML, a post starting with =\w+ is in POD, regardless how the rest of the post looks like).

      As for the significant whitespace thing, whitespace inside <code> is currently significant. Quite significant actually.

      Abigail

[reply]

In Section Perl Monks Discussion