Use [[...]] for shortcuts not [...].

Define which fields hold HTML and which hold text and display them properly (always escape the text into entities and always filter the HTML).

Use UTF-8.

Define the valid ranges of characters allowed (may vary by field). For example, filter out non-whitespace control characters everywhere. You might want to disallow poorly supported and dingbat-like characters from titles and/or usernames.

Spend some quality time designing login / security. Provide automatic means for handling when people forget their password and lose access to their selected e-mail address.

Keep the mark-up simple and be *very* wary of purists and pedants. For example, HTML tables have proven to work better in a wide varieties of environments than anything I've seen anyone propose.

I'll probably write up more specifics when I have more time.

HTML tables have proven to work better in a wide varieties of environments than anything I've seen anyone propose.

Non-horizontal layout works better. Especially if everything can be left-aligned. If you don't need a chatterbox or always-visible poll, find a simple layout. Avoid tables and CSS if you can. If you cannot, in 2005, I think it's best to try and find a layout that works with pure CSS. And make sure testing isn't limited to the usual browsers. Include some PDA browsers and text browsers and hack in special cases if needed. Oh, and if you dislike headaches, let ancient browsers be the problem of their users instead of your problem, because it will only get worse as time passes.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Oh, and if you dislike headaches, let ancient browsers be the problem of their users instead of your problem, because it will only get worse as time passes.

I cannot agree with this more. Given that Firefox is a free download, installs quickly, and is a minimal impact on the system ... there is no excuse to not have a CSS-capable browser. Period.

And, if you're complaining that you may not be able to install it at work - what're you doing reading Perlmonks at work? :-)

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

I think for a site supporting a perl like language that <[...]> might be better. Its a little uglier, but IMO a lot less likely to occur in code.

---
demerphq

I am not sure one needs to be able to include shortcuts in the code snippets. PerlMonks does not let me. At least not in this response:

[Code]
[download]

Then I only have to cae that the end-of-code sequence (</code> in PerlMonks) is not likely to occure in code.

What have you learned (regarding the markup) from the past 5 years here ?

That tables sucks for design, because they make the entire page wider if only one node is wide. And that demerphq doesn't like users to use structured HTML with h1 and h2, but wants them to start with h4 instead, because PM itself uses h3 for the title. (I disagree and think PM should be fixed, because that can be done much more easily (with CSS, for example).)

Is the list of approved HTML tags the Monks have a good list ? Are there HTML tags that would make life easier ?

It's good now. Although some complain that images cannot be used, I think this is a good thing. Images are slow and, for Win32 users with MSIE, dangerous :)

How do you like the system of the shortcuts ?

I like it a lot, but I still don't understand why // is needed. [id:422484] instead of [id://422484] would be nice. The double slash has a specific meaning according to RFC 1738, and PM breaks this. // is a promise that //<user>:<password>@<host>:<port>/<url-path> (the common internet scheme syntax) can be used.

Would it make more sense to disallow the submission of bad markup or that of not approved HTML tags ?

Yes and no. I don't think this is a big deal. It would be nice if a simple HTML parser were used to close open tags, or to avoid tags being closed without ever having been opened.

And that demerphq doesn't like users to use structured HTML with h1 and h2, but wants them to start with h4 instead, because PM itself uses h3 for the title. (I disagree and think PM should be fixed, because that can be done much more easily (with CSS, for example).)

Well, i agree with your diagreement, but until it is changed I do have more or less that opinion. OTOH since I've only ever considered a node about it once (which was yours) and that the community didn't agree with me when I did, I pretty much recognize that moaning about it is a lost cause. :-) (And by inference im not really sure why you brought it up, my opinion in things like this is no more relevent that anyone elses.)

---
demerphq

im not really sure why you brought it up

To answer the question. I had always learned that h1, h2, etc were for structuring, but your POV appears to be that the number in there is to indicate the size of the heading. This demonstrates that even something with a spec, like HTML, is open to multiple interpretations. For the OP, it is a hint to define these things, or at least think of a way to handle them.

I pretty much recognize that moaning about it is a lost cause. :-)

I am not convinced that it is. If you feel this is important, we should still seek a way to fix it. Either through CSS (just define font-size in the right contexts) or by disallowing the "big" (or, from my point of view: higher level) headings. There was no clear concensus on the consideration, but there were in fact more people who voted edit than who voted keep, and this proves that you're not the only one who dislikes the current state of things.

About the headings being too big: I agree, even.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Just a quick comment on "shortcuts" along with a favorite soapbox rant.

As has already been well-discussed, and well-considered: whatever character sequence you use for interpolating "shortcuts" will preclude their use as ordinary text, therefore it is best to choose a "rare" character sequence.

The problem is, in the discussion-space of 'computer programming languages' (especially versatile ones like perl) there *are* no rare character sequences. With all the different mini-syntaxes, protocols, idioms and neologisms out there, it's (arguably) impossible to choose a syntax that can never be misinterpreted as a command when it was really intended as plain text. Especially when you limit the command-delimiters to the fewest number of total characters. This is the classic linguistic problem of 'use versus mention'.

Ironically, perl (and unfortunately, perl seems to be alone on this) solves this universal problem *exceptionally* well. Namely, allow the user to specify her *own* command delimiters, and completely obviate the need to add cumbersome 'escape sequences' in nearly all circumstances.

q§This is a $brilliant$ idea.§;
"This is a $brilliant idea.";
qq^This is a "$brilliant" idea.^;
q{This is a $brilli@nt ide@};
qŠThi§ i§ a $brilliant idĽaŠ;
[download]

This unique aspect of perl should be on the "best practices" short list of how to solve this particular problem. A+

Indeed. Let's play chase the delimiters (trying to get deparse to resort to escaping):

$ perl -MO=Deparse -e'print "foo"'
print 'foo';
-e syntax OK

$ perl -MO=Deparse -e'print "foo'"'"'"'
print q[foo'];
-e syntax OK

$ perl -MO=Deparse -e'print "foo['"'"'"'
print q(foo[');
-e syntax OK

$ perl -MO=Deparse -e'print "foo(['"'"'"'
print q<foo(['>;
-e syntax OK

$ perl -MO=Deparse -e'print "foo<(['"'"'"'
print q{foo<(['};
-e syntax OK

$ perl -MO=Deparse -e'print "foo{<(['"'"'"'
print q/foo{<(['/;
-e syntax OK

$ perl -MO=Deparse -e'print "foo/{<(['"'"'"'
print q"foo/{<(['";
-e syntax OK

$ perl -MO=Deparse -e'print "foo\"/{<(['"'"'"'
print q#foo"/{<(['#;
-e syntax OK

$ perl -MO=Deparse -e'print "foo#\"/{<(['"'"'"'
print 'foo#"/{<([\'';
-e syntax OK
[download]

The problem is, in the discussion-space of 'computer programming languages' (especially versatile ones like perl) there *are* no rare character sequences.

That I do not believe. Sure, every character sequence can occur inside a perl program (just put it inside quotes), but many sequences are rare. And the current delimiters, [ ] are one of the most common. [[ ]] would be far less common. Sure, one can make Perl code that uses [[ ]], but if you'd do some statistics on <code> fragments on Perl monks, you'll see that [ ] is uses far, far more often than [[ ]].

Hence my suggestion of <[]> something that I dont think I've ever seen in real code. IMO [[]] is all too often found in Perl code:

my $AoA=[[1,2],[1,3]]
[download]

---
demerphq