Remote View
why do & ampersands never display properly in titles?
why do & ampersands never display properly in titles?
but work in body text &
35 comments
-
The API sanitizes them, so they're stored encoded (&) in the database.
Some frontends correct for this when posts are rendered, some don't. Voyager and Tesseract, at least, seem to correct them. Not sure about others.
-
Working fine on Sync.
-
That's the problem, then. You shouldn't store entities in the db, the table is likely already utf8, which supports all characters
-
I think 0.19 is reverting that behaviour, because it was indeed a certified bad idea.
I think the idea was to attempt to bulletproof potentially crappy clients especially after the XSS incident, but the problem is it's simply not even always rendered in a web context which makes the processing kind of a pain.
Wouldn't surprise me if it becomes double and triple encoded too at times because of the federation. Do you encode again or trust that the remote sent you urlencoded data already?
Best format is the original format and transform as late as possible, ideally in clients where there's awareness of what characters are special. It is in web, not so much in an Android or terminal app.
I don't think the Lemmy devs are particularly experienced web developers in general. There's been a fair amount of dubious API design decisions like passing auth as a GET parameter... Thankfully they also fixed that one in 0.19.
-
-
Thanks
-
Works fine in connect
-
Does not work on MacOS Firefox.
-
imma quicky test on thunder
edit: displays &
-
-
There was some scare in lemmy development circles recently about script injection vulnerabilities. The various apps and frontend developers "solved" the problem by peppering untrusted user input with escape sequences all over the place. User submits post? Escape title! Receive new post from a federated instance? Escape title!
Obviously if you escape the title twice and display once, it will show up weird. The problem is that the various devs haven't agreed yet which parts of the messaging protocol are supposed to be already escaped and which are not. Ideally all user input should be stored and transmitted in raw form, and only escaped right before displaying. But due to various zealously-cautious devs we get this instead:
-
There's a difference between cautious and incorrect. It's broken. If they're that concerned, where are the unit tests?
-
They incorrectly broke it because they were overzealous.
-
Content showing up weird in federation sounds like a good use of integration tests to me
-
-
This was a really informative comment, thanks!
-
-
For me(using sync), it shows a different font for each &
-
That has nothing to do with the ampersand, it's just that post titles and bodies in general have different fonts. It's just easier to notice in the ampersand since it's so different between the fonts.
-
-
They show as & on the mobile web interface for various instances. I would say it’s something improperly done with what are called HTML entities. HTML entities are a way of encoding various elements that have meaning in HTML so they can be displayed, without being interpreted as HTML by the browser, which could not only break a layout but have security implications. So the titles are sanitized to prevent injection attacks but somehow are not stored/output in a way that they display properly.
-
Thanks for the explanation
-
-
Looks fine to me. It works.
Using Voyager on Android
-
Thanks, I'm on Jerboa Android & they show as & amp;
-
Works on Sync.
-
Same on Boost
-
-
Fine for me too with Eternity
-
I have Eternity on Android and it says "& ampersands". Broken on boost.
-
-
-
I believe it's been fixed for the next version of Lemmy. But for now, small ampersand (U+FE60) works as a substitute: ﹠
-
Small ampersand I love it
-
Also I wonder if your username and my own, (head tilt) may share the same meaning
-
-
On Eternity we have the opposite (work in title but not body), but when I click into the post it looks fine.
-
They're also broken in code blocks
35 comments