And he's got a list of things he wants to be able to do without JS. discuss?
"1. Why can't we have a standard search element that filters a list on the client side (similar to how ng-repeat | filter: worked on Angular)?
2. Wouldn't a standard HTML element for drag-and-drop sorting be awesome?
3. More advanced validation functionality, like comparing equality of two different form fields.
4. The ability to do the modal/checkbox trick above without it feeling like a hack and writing weird CSS."
@alcinnz Basically what you need for 4 is the ability for an element to toggle the hidden attribute on another element. Maybe a 'shows' and/or 'hides' attribute?
Actually, there is already an element for dialogs, lightboxes and modals, but it's still not supported everywhere (ex. It doesn't work on Firefox for android)
But I don't think it should have ever been a part of the web. All our standards should have remained declarative for the sake of user-control, accessibility, and ease of authorship. Not to mention security in the face of vulnerabilities like Spectre.
Just so you know where I'm coming from.
@tleydxdy I'm confident they wouldn't find a way if we didn't give them Turing Completeness. Which yes, requires great care.
But yes it is worth considering whether creating another language is appropriate for the tasks he (or anyone else) cites. And in the case of triggering modal dialogs to show, it looks to me like just a different presentation of link traversal.
@tleydxdy Yes, avoiding Turing Completeness can be difficult. And yes, other measures would be necessary to achieve widespread privacy.
@awe Can you give an example?
@alvarezp Say that web browsers all had their own special Web version of Prolog. We would still be in exactly the same boat with arbitrary remote code execution. The issue isn't whether the language is declarative or imperative, it's fundamentally that we're, by default, downloading and executing whatever program someone asks us to, and that program can do whatever it wants. That is, what matters is the language's expressivity and API surface, not the programming style.
@awe What terms would you use? Can't say "the problem is that JS is code" because HTML and CSS are also code. Can't say "the problem is executable code" because JS is interpreted, not executed. Nitpicking will always find a flaw. That's why I provided an example: a computer can identify and block a hypothetical <cryptominer> tag easily but can't identify if a piece of JS is a cryptominer or not as none of the individual instructions to cryptomine are actually malicious.
@alcinnz @awe That would be a better term but I read somewhere that CSS was recently proven to be turing-complete so I am also not sure.. Now that I looked at Prolog syntax, I probably should have not used the term "declarative". But the point remains. Have you seen the video about using JS in PDFs? Same principle. I don't have enough knowledge of formal languages and grammars to properly express myself.
@alcinnz @awe So, not by itself? That is good. In any case, CSS is much easier to audit and contain. Once I discussed in Twitter about JS and tracking and got the immediate the response: you can get tracked with CSS too. I saw a somewhat unreliable PoC involving CSS selectors for text input content and remote styling for different cases. But a browser can easily just retrieve all the listed CSS resources on page load.
@alcinnz @alvarezp I think a perfectly reasonable way of talking about the issue is simply as arbitrary code execution. The whole point of something like blocking a <bitcoinminer> tag or something would be that the tag is _not_ arbitrary code, but rather refers to a specific program with specific behavior. It's the restriction of the language to specific behaviors that makes things like HTML and CSS less problematic.
Linux Geeks doing what Linux Geeks do..