It seems like a great time to reiterate: I hate clientside JavaScript, and the feature bloat it has brought to The Web and mainstream browser engines (Gecko, WebKit, & Blink). This can't and shouldn't last!

I want The Web to focus on hypertext (without JavaScript turning every feature into an attack vector on privacy) that can be rendered nicely in more form factors than just a laptop or tablet.

Everything else should be shoved off onto other MIMEtypes or URI schemes.

@alcinnz A huge amount of JS could be eliminated if basic HTML had some notion of a post/comment response tree, relation, and interactions (scoring, filtering, replying, muting, blocking). That should be a fundamental part of the epistemic (content-based) Web.

I've also argued that the Web should be divided into four roles:

- Text/content and interactions.
- Commerce, including payment and trust mechanisms.
- Multimedia: video/audio playback.
- Apps beyond these.

old.reddit.com/r/dredmorbius/c

@alcinnz The Web *began* as a content delivery / publication systems (though lacking Critical Bits such as Search and Archival).

Media got bolted on via the <img> tag (later audio and video), and commerce was later added. Both remain problematic.

The absence of sane defaults for styling, a recognised set of standard page formats (index, article, gallery/catalogue, discussion, stream, etc.) and uniform formatting, is a huge part of the problem -> CSS and JS paper that over.

@dredmorbius Wow! That's plenty to think about!

After next week I'll start exploring tag-based bookmark management, and I'll be keen to get your feedback on my take.

I can't say I'm 100% against CSS (I prefer webdevs to apply style that way rather than using HTML), but at the very least userstyles need to significantly more prominant. Whether or not we want to block author styles.

@dredmorbius Certainly I do want to seperate apps out into their own platform, for which I generally like proposing an offline Elm sandbox.

If we got rid of JavaScript, it should be trivial enough to render <audio>/<video> as download links.

And it strikes me when creating a browser for a voice assistant (and maybe eventually Smart TV) form factor I am tending to seperate forms (as used in checkout) into their own UI.

So I think we have some very similar ideas here!

@dredmorbius Oh, can you elaborate on how you imagine this comment tree working in HTML?

@alcinnz So a comment tree in straight HTML might require some thinking. There'd have to be _some_ smarts, client or server side.

Basically: you need elements. And/or relationships. I think you can even skip specific <article> vs. <comment> elements if you have instead <parent> <child> or <in-reference-to> / <citations> type relations. See email threading and specifically Mutt and jwz's threading model for Netscape.

@alcinnz Then there's the question of _what elements are actually within a particular comment thread or tree_. We've relied entirely on server-side, parent-centric, site-specific models for that to date. Basically: everyone codes their own and they don't interoperate.

Also: we've had interoperable systems (Usenet, Listserve, Mailman), and ... they had ... issues.

Mostly spam.

Lots of motherloving spam.

So: the parent might compile a list of validated responses as comments. Option # 1.

@alcinnz A feature (problem / benefit depends on your viewpoint) is that parents could determine what responses they do or don't want to acknowledge. If you're mitigating stalkers / hackers / trolls, that's good. If you're trying to deceptively manipulate conversation / narrative, maybe not so much.

So option # 2 is for freestanding references to be able to cite what they're referencing. The tree can be acquired from the branches rather than root.

@alcinnz Oh, and inherent in this is that parents and children are explicitly distinct documents with relationships. Rather than chunks of stuff within a single page, though they might be _represented_ that way.

Mind: you could (and ... some poor lost disillusioned soul might) try to throw it all in one bucket. But That Would Be WRONG!!!

Within a rendered page ... some sort of inclusion reference. Which does, natch, raise all kinds of further issues (security, snooping, etc., see IFRAMEs).

@alcinnz Any time you allow content from multiple authorities / entities to be intertwingled, you're going to want to set some sort of baseline of maximum allowed features. Say, just straight text and styling, perhaps.

(And just having a limited feature set doesn't preclude misusing that feature set, though it may make misuse easier to identify.)

@dredmorbius I really don't have much of an opinion on what the best approach would be, but from my perspective of being deep in the weeds attempting to implement new browser engines:

It'd be reasonably easy for the browser to support inserting HTML snippet HTTP responses into arbitrary elements on the page. Many existing forum/commenting systems could easily be recreated with that...

I would simplify HTML error recovery, and not allow any additional CSS & ofcourse JS.

@alcinnz Easy != Good Idea.

Look at where <iframe> got us. Yes, you can embed entire Web pages inside other Web pages. The trust / risk implications turn out to be ... immense.

This gets to a general model of coming up with some kind of document complexity and capabilities model, and granting capabilities based on trust. uMatrix is effectively one (fairly crude) tool for doing this. I've taken a few stabs at defining this, none are especially satisfactory.

Follow

@dredmorbius True. While I do think it's a nice evolution of hyperlinks to cover many/most use cases for Ajax, we probably shouldn't be embedding third party HTML that or any other way.

Though I certainly wouldn't include that in the voice-assistant form factor I mentioned, it doesn't fit the experience I'm designing.

Sign in to participate in the conversation
FLOSS.social

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).