> > default to HTML escaping on output
> ??? Is that a joke? Don't do that! That's just as bad as magic quotes.
I understand the debates Django had about changing what the unspecified output function did, but nowadays if you're building a new template language of any kind it's an absolute no-brainer: Make it easier to encode than to bypass encoding. The alternative is just awful.
What if I assign that string in a variable, and then output it later?
I'm not convinced this can be done well. Maybe if all you do is make some templates and fill them in you could do it. But I do a lot more than that, I output dynamically built html all the time.
Just give people a very easy and shortly named function for escaping.
Ask any Haskell weeny for details.
Also in your example, you'd probably be better of, if your language knew about the HTML structure, e.g. something like P($var), instead of putting the tags in as strings.
And if you can't extend your type system to make this work, do it in your head, mutating the names of variables to help you keep it straight. For example, esStr and unStr are not of the same type, and moving data from one to the other without conversion is always an error.
http://msdn.microsoft.com/en-us/library/aa260976(v=vs.60).as...
http://roboprogs.com/devel/2009.07.html#2009_07_30 (point number 4 in the numbered list)
Of course, I was thinking of a runtime attribute, rather than static typing, but the idea is similar.
I like this, although when you concatenate strings, does it actually concatenate them (and loose the type info)? Does it escape them, and then concatenate? Or does concatenation actually make a closure, which is only executed upon output? (And does doing that make things memory heavy.)
Haskell is on my next language to learn list.
> something like P($var)
Ugh. I hate that. I've spent years learning HTML, I want to write HTML, not some other language that looks like it.
$foo = <p>$textvar</p>; $foo->append(<span class='will-end-up-before-close-of-p'>Hello!</span>); // etc.
Mozilla proposed to add XML literals to JavaScript at one point, which didn't take off for security reasons, but server-side it's a different ballgame... maybe it could be worked out? Hmm.
Have you looked at how Racket (Scheme, Lisp) deals with encoding HTML in S-expressions? I find that rather nice, and even prefer it to plain HTML or XML. Racket is a fine language for manipulating S-expressions, too.
Also about the HTML: You can of course use different syntax for what I proposed, one that's closer to actual HTML. But I think as long as the syntax tree is preserved, it's still close enough to HTML for me, and all your accumulated knowledge about HTML is still applicable. (Not to be derisive, but if your years of learning are no longer of any use upon such a cosmetic change, you should probably examine your level of comprehension.)
PHP IS a templating language. Writing another one on top of it is just adding complexity for no gain.
I'd say don't do that, refactor into templates instead. With your preferred approach to generating markup, you're largely on your own in protecting against XSS. Hopefully all the developers using your code are awesome at spotting and pro-actively dealing with XSS issues.
Still, with a HTML escape everything default, either turn it off, or use a raw "I know what I'm doing" method instead.
You'd do something like @html.SalesWidget("90% off today") with the SalesWidget being responsible for escaping the string.
Also I don't really get your argument, why not give people a really short and easy way of not escaping a string instead? The opposite of what you're suggesting is just as easy and far safer. You're less liable to accidentally muck up.
Such a mechanism would have to include encoding functions (and assertion override functions), of course.
It seems this would help alleviate many types of fill-in-the-blank injection problems as well.
Not to mention the (also type safe) dead easy to use persistence framework.
I'm still in the process of evaluating different solutions for my next web project but so far I'm pretty sure this is gonna be my go-to framework in the future.