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.
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.
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.
Starting at base levels: there are characters, sentences, linefeeds, paragraphs, images, styling (fonts, colours, sizes), structured docs (metadata, titles, sections, lists, tables, references, equations), explicit layout blocks, multimedia (video/audio), programmatic content, remote / cross-site includes.
Each carries capabilities but also risks. Defining, say, a "comment trust level" of "text, paragraphs, bold, italic, superscript, subscript" might be a decent base level.
@alcinnz Elements such as images, audio, and links, would have to be granted based on specific trust relations, though whether those are explicitly granted by a site (or page) author / moderator, through SW heuristics, or some mix, might be open to discussion.
Mind that abusers can abuse virtually anything.
@alcinnz I mean, Usenet had MMF:
My general view is:
- Focus on *behaviour* rather than *features*
- Recognise that *complexity* enables both more bad behaviour, and can mask it.
- Reputations matter. Rather than identify *content*, track the *creators*, both good and bad.
Effective trust networks tend to be *small*. A few tens, *possibly* hundreds, of actors. Trust scales poorly.
@alcinnz Complexity: more pieces, more types, more relationships, more types of relationships, more change over time.
Certainly if/when I do I should start from the behavior their intended to preserve, reimplement that without JS. Make sure they have a use!
But also I'm keen to maintain graceful degradation so, amongst other things, I can always drop those features if they're not worth it.
[Notice Regarding the Transfer of the mstdn.jp / mastodon.cloud Services] We have received several inquiries showing interest in a transfer following the announcement of the end of the mstdn.jp and mastodon.cloud services. As a result of subsequently evaluating the situation and making preparations, we have decided that the corresponding services will be transferred to Sujitech, LLC. on June 30. Thank you.