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.

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

@alcinnz Then there's interactions.

The idea of a comment thread is ... well, it's _dynamic_. At the very least, it's additive: others can add their Considered, Reasoned, and Illuminating Thoughts.

Or whatevs.

So: reply.

There's the question of ranking and rating, ordering, filtering. Possibly editing (and questions of versioning). Deleting. Moderation.

Some minimum featureset should be specifiable here, and generally, implemented through HTML, HTTP, and browser features.

@alcinnz And given that We Have Been Doing This Shit For Neigh On Forty Years, there might even be some sort of rough reasonable concensus as to What Said Features Might Be.

(Apply the exponential doubling cost rule to any proposed extensions as with page schemas.)


@alcinnz But again, in brief:

Within page layout: a parent-child hierarchy.

Between documents: a citations / in-reference-to relationship. Children know their parents, parents know some of their children.

For elements: a set of defined actions: reply, rate, hide/dismiss/flag, classify. Moderation and reputation features. Spam classification.

Sign in to participate in the conversation

Generalistic and moderated instance.