Just finished writing an overview of my ideas for a post-JS web. Next I'll be expanding on what each of those HTML extensions might look like.

And maybe draft some example code.

git.nzoss.org.nz/html6/whitebo

I'm keen for feedback!

@alcinnz Though I like some of the aspects, I think on a technical level one thing we need to get way more clear about is completely different use cases "the web" is being used for, as of today. I dare to say that a *very small* crowd of people in 2019s web still does, in example, have sort of a "document-driven" approach, like, "accessing a document resource" to read through it and, this way, extract information. πŸ˜‰

@z428 I percieve that what draws people to particular sites is what information it is (even if that's "here's something you can purchase"), and what draws them to particular apps is what it does.

Though I guess that gets a bit muddled.

Anyways I'm keen to hear other takes...

Follow

@alcinnz I see people being attracted way less by *information* itself but actually by *interactivity* surrounding this. In my environment in example, writing weblogs or websites never "got off" the way Twitter or Facebook did, later - because in the days of weblogs or (semi-)static web sites, communication and interaction was somewhat clumsy and difficult and mostly limited to using web forms (slow) or e-mail (slow and considered way too "formal" for random exchange of thoughts).

@z428 Ah yes, that might be a good way to put it. Information brings them to the site, interactivity makes them stay.

@alcinnz At least that's *one* relevant aspect, I guess. Not sure, though, it's *only* information that brings people to particular sites. I've mostly grown up in an age of "starting online communities" (which early-on used to be based on telnet or web forums but got replaced by social networks at some point). In these cases, it was all about communication - which is what people very much use "the web" for, right now, even while it's not at all the use case the WWW was thought to cover. πŸ˜‰

@z428 @alcinnz
I'd argue that the majority of websites are still one-directional:
newspapers, official information websites of a company/organization/government/university, etc.

We may be using the interactive, two-way-communication-oriented ones the most, but there's few of them. So it wouldn't be unreasonable to turn them into native applications.

@Wolf480pl I'd make a difference here between "the majority of websites" and "the websites a majority of web users tends to visit frequently or even regularly"... πŸ˜‰

@alcinnz

@z428 @alcinnz
Yeah, my point is, "the websites a majority of web users tends to visit frequently" are very few.

And they aren't websites, they are web applications.

So make them real applications.

And then see how many features of your web browser no longer have a legitimate usecase for the remaining websites.

@Wolf480pl @z428 Hmmm, one question I've been asking since I've implemented the feature is: Would the Web be much different if browsers would recommend apps to install when opening an unsupported URI? If webdevs didn't have to worry about whether their readers had a e.g. BitTorrent client installed?

And in my writing in that repo I'm starting to ask questions about "What if Google Doc's features were just part of the browser, allowing users collaboratively edit (copies of) all webpages?"

@alcinnz I think it's a mix of all these things. Back in "those days", it was good to have, like, open protocols and applications handling those. However, this also caused an *incredible* amount of trouble (just try sending, in example, a file to an arbitrary XMPP contact, or a pixel-style formatted e-mail to an arbitary e-mail recipient). That's why a lot of teams moved from building a *protocol* (for arbitrary client applications) to building *applications* (that, under the ...

@Wolf480pl

@alcinnz ... hood, of course use protocols which, however, aren't suited or supposed to be re-used for random clients to build on top). Slack is a good example for that. And on the other side, a lot of devs have moved from "native applications" to "web apps" because it makes it easier (or, in some cases, even possible in an economic way) to cater for multiple desktop platforms and get rid of a lot of nasty issues such as deployment/software distribution, remote ...

@Wolf480pl

@alcinnz ... debugging, all this mess. That's what I see right now: A lot of people actually (ab)uses the WWW as a runtime for rich client/server applications and cross-platform clients. Generally, I don't even disagree with this, but it's a completely different use case with different requirements, and doing so on top of means of technology supposed to transport structured (and, at best, visually enriched) information seems difficult. πŸ˜‰

@Wolf480pl

@z428 @alcinnz
Well, I fundamentally disagree with this approach they have taken. But I'm willing to make compromises.

For me, they can have their client/server application platform, provided that those features required for having a client/server application platform are not available to just any random news site.

Or put it another way: aside from an application platform, we also need a separate hypertext platform.

@Wolf480pl I disagree with the approach they have taken, but I understand that decision nevertheless. We're in the late 2010s, with technology having moved forth quite a bit ever since, but a lot of our protocols are still rooted in (and left compatible to) the late 1970s. Effect: We do have ridiculous constructions such as the whole RFC stack that tries to allow for "rich e-mails" which is in many ways a complex and dreaded mess, abused by some and simply abandoned ...

@alcinnz

@z428 @alcinnz
btw. look at the contemporary socnets, IMs, chats...

Half of them doesn't allow rich text of any kind, the other half supports at most markdown or sth like that.

And picture attachments.

This is how much rich text people need.

Not pixel-perfect styling.
Only marketing needs pixel-perfect styling.

@z428 @alcinnz
So IMO nobody really needs rich text emails.

@Wolf480pl Well yes, business people expect pixel-perfect styling, just the way they expect their (written) letters or their web site to adhere to a certain visual style. Invoices are a good example (rather than again rendering them to PDF and sending out attachments). πŸ˜‰ I don't even see a problem here if we actually accept these use cases to be valid. πŸ˜€

@alcinnz

@z428 @alcinnz
Well, I probably still want a pdf invoice... easier to print. Also, pdf was specifically designed to be pixel-perfect, unlike HTML.

@Wolf480pl That's what I meant. πŸ˜‰ A lot of people I know who want to send out "designed" e-mails couldn't care less about HTML or PDF. They however *want* something they can use to make e-mails that allow for basic formatting and that are available without requiring an additional application. So far, HTML is the best (only) thing they got. Which is bad. πŸ™‚

@alcinnz

@irl you mean for casual formatting, or for invoices?

If for casual formatting then... uh, I think we don't need a binary format... also, Markdown degrades gracefully, to the point that the even if you view it as plaintext, it's still readable *and* you can intuitively see what the formatting was supposed to be.

@z428 @alcinnz

@Wolf480pl @z428 @alcinnz Markdown isn't formatting, it's semantic markup. There's no styling in Markdown.

Invoices should come as PDF and they should have signatures. These are documents that have meaning, in many cases will lay out credit agreements, etc. Sending invoices as HTML email is a joke and I will treat any HTML invoice as such.
@Wolf480pl @z428 @alcinnz Even if it's just a receipt. I'm going to have to upload that to my finance system for expenses or audit purposes. Please don't give me a MIME multipart document that I have to hack into my corporate finance system. It's designed to take PDFs.

@irl @z428 @alcinnz
We seem to agree about invoices.

Now as for markdown - yeah it's (almost) semantic. Definitely closer to semantic than to styling.

So now my point is:
people don't really want styling/formatting in most of their communication. They want to be able to

- express lists of things
- *emphasize* some words
- etc.

for which Markdown or sth similar is a better fit than RTF or even BBcode.

@Wolf480pl Hmmm, actually reading the *markup* source code doesn't feel very "graceful" to me. I thought more all along the lines of what lynx or w3m tend to do to web pages if they are reasonably well-crafted. My expectation would be a plain-text representation that makes use of the device at hand as good as possible, including things such as positioning of elements (which works in a terminal as well), text-color, borders, ... . πŸ˜‰

@irl @alcinnz

@z428 @irl @alcinnz
yeah, but my point is, even if your email client doesn't know about markdown, you'll see:

## Heading

- list item
- list item

*emphasis*

etc.

You often use markdown without realizing it.

@Wolf480pl ... by others, and I am convinced e-mail (also all along with instant messaging and the like) could be way better today if we just managed to, at some point, start over from scratch, build something entirely better and then eventually allow for backward-compatibility / graceful degratation layers for "old" protocols (IMAP, SMTP) or clients, rather than considering this to be the common ground and everything else fragile extensions on top. And, the other ...

@alcinnz

@Wolf480pl ... part, talking about the "hypertext" platform: Maybe this also would have to change in this way or the other, but, here, we have caused quite some trouble by essentially accepting a web where everything is "gratis" (=free of charge), leaving tracking- and ad-backed funding the only means at hand for most people to actually even earn the money they need to cover costs. I am convinced the web would be a better place if people were ready to throw some cash for services ...

@alcinnz

@Wolf480pl ... that matter to them. Or spend some time working on things instead of paying (which is more a community-like approach).

@alcinnz

@z428 I'd still argue it's information bringing them to particular social networks, though in this case it's more about who's writing that (usually frivolous) information.

In other words: your friends are there.

Sign in to participate in the conversation
Mastodon

One of the first Mastodon instances, there is no specific topic we're into, just enjoy your time!