Hacker News Reader

Comment by EE84M3i | Hacker News Reader

From the FAQ:

>Why doesn't Maud implement context-aware escaping?

>If a project follows best practices in separating HTML and CSS/JavaScript, then context-aware escaping is unnecessary.

>Google uses context-aware escaping because it has a large, decades-old code base, much of it written before these best practices were well known. Any project that uses Maud is neither large nor decades-old, and so should not have the need for this feature.

This seems misguided. Javascript and CSS are not the only contexts. Another example is URIs (which can be javascript: or data:), which Golang's html/template correctly escapes: https://github.com/golang/go/blob/master/src/html/template/u...

View on HN

seems like the FAQ is outdated regarding the authors view on that: https://github.com/lambda-fairy/maud/issues/181

Author here. Yeah, that FAQ was written a few years ago and my opinions have changed since then.

I'd also like to emphasize that no Rust template engine – that I'm aware of – does context-aware escaping. At least Maud has it on the roadmap.

I hate to come across as elitist or something—noone's perfect, and I appreciate people building software libraries & releasing them, regardless of their experience as a programmer.

But if someone's publishing a HTML templating system, and they don't have enough knowledge about HTML to understand the need for contextual escaping, I would have grave concerns about the Dunning-Kruger effect & the quality of any software that engineer writes.

Dunning-Kruger effect seems like a weird accusation to throw here. The whole basis of it is "a false sense of superiority", but the author is clearly willing to engage on this issue.

I think a better way of terming this would be that you have concern the the author might not have enough domain expertise, which is very different than being incompetent.

This gives me pause that Maud isn't right for a production system at this time, but is that so surprising for a 0.11 library?

I suppose one does gain good experience and knowledge if one is receptive to feedback during the developing & maturing of a software project, so that is positive.

I guess what I was more getting at was the thought process that goes "I'm going to develop and release a library in X domain", when ones knowledge of said domain is low. And then launching said library before one has really gained a lot of knowledge of that domain.

I might be biased, as I'm the engineer that you're talking about, but that characterization feels unfair. Context-aware escaping is by no means common in the open source world—just look at Jinja or Handlebars. So unless you're knee-deep in an ecosystem that embraces it, it's easy to brush it off as unimportant.

javascript: URIs aren't legit and shouldn't be used. Yes, they work. No, there's no excuse for using them.

Maybe, but the point of this protection is to avoid accidentally using them. If you let a user supply a URL and they enter a javascript: URI then it'll be defanged.

There's no real alternative to `javascript:void 0`. If you need to have a link that absolutely will not do anything, even under noscript, it's the only solution. Using `href="#"` is not an alternative, because it messes with the user's navigation history.

A link that has a noop href should not be a link. Either give it a meaningful href if that’s possible, or realise that it’s actually a button in disguise, and so turn it into a button.

Yes, I am saying that you should never use <a href="javascript:void 0"> or similar. (<a href="#"> is illegitimate in most cases, but is occasionally used honestly to cause scrolling to the top of the page.)

I use them with progressive enhancement, so if javascript is available, then a dynamically generated href is added. Otherwise, I prefer non-functional links, because hiding the links often affects layout and can be confusing. If the link is visible, but not working, it's obvious that there's an issue with the application. If the link is hidden, it's not really clear why its missing. (Did the site change? am I on the wrong page? etc)

Buttons aren't perfect, either, you have to write additional code to handle middle-click actions, and the right-click menu doesn't contain the expected "Open in New Tab" or "Copy Link Location".

Can you give an example on when you would need a link that does not link anywhere? The only cases I can think of are better served by `<button type="button">`.

I use them for progressive enhancement. If javascript is available, I'll add a dynamically generated href, or call .addEventListener("click", ...) and add behaviour to the link. Buttons can be used sometimes, but if you're wanting something that behaves like a link: middle click works, right click "Open in new Tab", Copy link, etc. then a button doesn't work.

I prefer to use buttons to affect the state of the current page. And use anchor tags for all other navigation, even if I'm handling it with .addEventListener("click", ...).

I suppose I could just hide the non-functional links, or add them dynamically with javascript. But that could affect layout.

If it’s not going to work if JavaScript is unavailable, I would suggest either adding it dynamically with JavaScript, or else omitting the href attribute so that it’s not a link; this could be paired with hiding it, or just giving it attributes like title="JavaScript is required for this link to work" and style="cursor: not-allowed". (Maybe aria-hidden="true" too.)

That's a reasonable option, I'll have to try that. My only concern is that when an anchor tag has no href attribute, the styling is different. It usually behaves as plain text, if I remember correctly, which is really confusing if you expected a link. Nothing that styling can't fix, but that's why, historically, I have always tried provide an href tag, even if it's just href="javascript:void 0".

Still, your solution is nicer in many ways, thanks.

My point is that it semantically isn’t a link until the JavaScript executes (if it ever does). A link is something you can click on and it does something.

But yeah, stylesheets might need adjustment for best results if you want to keep it on-screen even when it’s not operative, e.g. add a class link-needs-js which you style along with your :link, :visited.

In the hidden versus disabled thing, I do approximately this, if I have functionality that can’t work without JS (for whatever reason): if it’s completely optional, I hide it; if it’s important, I show it with a disabled style including not-allowed cursor (the disabled attribute if it’s a button, or a class if it’s an anchor) and some kind of “JS required” title, to at least give a hint as to why it’s not working and what the user must to do make it work. Anything between those extremes, I decide on a case-by-case basis, being influenced also by what else is there and does work.

Reply on news.ycombinator.com