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 I've felt for a while that most webapps could be implemented with <form> and reasonable CSS, if that. Client-side scripting is way overused.
@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?
@alexbuzzbee I'd add that I think modals have become a useful and dominant enough UI pattern on The Web (particularly in the form of "lightboxes") that I believe they should be native to HTML.
Maybe there's an attribute on links and buttons for that. Which could also set a side of this element to place it on, or maybe even pull in entire webpages for UIs like Stripe or OpenStack Horizon.
@alcinnz Perhaps add a 'modal' attribute to <button> that opens a modal document iframe-style? Or perhaps a modal element which is given by id?
@alexbuzzbee I like it!
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.
@alcinnz Yes! I like these proposals. I have gone myself through this when working with database-related frontends without JS and also came up with some needs:
1. A multi-column SELECT element.
2. A data grid. As opposed to tables, data grids can't span and allow sorting by columns.
3. Selecting the sort column for this hypothetical datagrid via URL, something like page.html?var=val#anchor##table1.sort=name,asc.
4. A "select all / deselect all" mechanism for forms.
I don't think I can agree that it's "plain and simple" when you have to trick the UI into clicking that checkbox by abusing the `<label>` tag. But I really like it in principle, and I would love to see this formalized in a more intuitive way.
Interesting read, thanks for sharing.
Somehow things have gone a bit downhill since then.
FLOSS.social was launched on 1 April 2018 as a Mastodon instance for people who care about, support, or build Free, Libre, and Open Source Software (FLOSS). Of course, discussions aren't limited to just FLOSS -- let's share our unique interests! English is preferred for maximum conversation opportunities within the FLOSS community, but it is not required. Respect is required, however: Users on FLOSS.social agree to abide by the Contributor Covenant Code of Conduct. This service was installed and is maintained in part by Masto.Host with equipment located at OVH. You can support this instance financially through the Monthly Supporter Program, processed through CommitChange using the free software Houdini Project.