Wow, just wow. I can't wonder how common such securing coding slip ups are these days.
This doesn't strike me as a slip-up, it strikes me as complete apathy on behalf of the developer(s).
On inspecting the page where they list restaurants, I can see a several versions of jQuery code like this, for each cuisine.
$('#Fish & Chips').on('change', function () {
if ($('#Fish & Chips').is(':checked')) {
$('.Fish & Chips').css('background-color', '#3a606e;');
$('.Fish & Chips').css('color', '#fff;');
} else {
$('.Fish & Chips').css('background-color', '#fff');
$('.Fish & Chips').css('color', '#3a606e;');
}
});I have a good feeling this is more of copy-pasta code from either Copilot or ChatGPT or StackOverflow. That also explains why they handled encryption the way described in the article.
Dev: "Hey LLM, how do I pass data around in a secure way ?"
Bot: "You can encrypt the data before you send it, so that only users who have the relevant keys can read them"
Dev: "Hey LLM, it is not possible to access the data I have encrypted on the frontend"
Bot: "Here is the javascript code to decrypt the data you have passed then"
"This is what you mean by CSS-in-JS, right?"
But seriously, those selectors are making me cringe. Does it even work with the spaces?
$('[id="Fish & Chips"]')
$('[class="Fish & Chips"]')with attribute selectors like what you have mentioned it would work. But `$('#Fish & Chips')` most certainly will not, since jQuery would throw a syntax error.
It makes sense to throw a syntax error but I wasn't sure what the actual behavior would be. Made me wonder if jquery did some magic to understand what is being queried.
So using newer CSS selector features, like attribute value selectors, will work fine in post-Sizzle jQuery versions.