mastodon.xyz is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Mastodon instance, open to everyone, but mainly English and French speaking.

Administered by:

Server stats:

882
active users

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?

@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.

@ranfdev @alexbuzzbee From what I can tell from that page, this doesn't fully answer the need: how do you open the dialog without JS? But it would be useful to encourage using this element alongside what we were discussing.

@alcinnz @alexbuzzbee @ranfdev there's nothing wrong with using js, just that some developers are evil.
Octavio Alvarez

@tleydxdy @alcinnz @alexbuzzbee @ranfdev There *is* something wrong with using JS [in documents like HTML] although sometimes we don't have a better choice. As an end-user, allowing Web-wide open Javascript means allowing arbitrary remote code execution [with some limits, but still]. JS, being imperative, not only allows for evil but even makes it difficult to detect. If we ever had a <cryptominer> HTML tag it woukd be easily blocked too.

@alvarezp How is this related to JavaScript being imperative? If we had a declarative language in every web browser, I don't see how things would be any different.

@awe @alvarezp What defines an imperative language is that you're specifying WHAT you want the browser to do, not HOW to do it. Thereby allowing the browser to decide the HOW, or even IF, itself.

@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.

@alvarezp @awe I tend to say "Turing-complete", but that tends to sound overly technical even to technical people.

@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.

@alvarezp @awe I looked into that, and the reality is CSS+HTML was kind-of proven Turing-Complete. The proof relies on humans doing exactly what the machine tells them, which I don't consider a serious threat. User input (specific clicks or key presses) was the clock signal.

Clever idea though!

@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.

@alvarezp @alcinnz It's worth saying that Turing-completeness is at some level a kind of naive view of the issue (and itself is also a very narrow way of talking about language expressivity). CSS might be "technically" Turing-complete (probably only when you include user interactions), but it's not actually as expressive as JavaScript (esp. including the APIs that are made available to JavaScript programs to interface with the browser).

@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.