I like this more than you’d think; my whole website is an extended exercise of Doing Cool Stuff with CSS and HTML generated from Markdown, but I always feel a little uncomfortable doing anything too fun when userstyles are not common practice. I could totally create a style switcher with Javascript, but… wouldn’t it be better if that were built into the client?
Reader mode in Firefox is what I’d like to fall back to, but it doesn’t handle my footnotes right now. :(
Great article. The continuing bloat of browsers is making google pretty much own the web, because no one else has enough money to pay for developers to support such a massive feature-set that its basically an operating system. Everyone else has dropped out.
Half the time when I see an article on medium or something anyway, I’m just clicking the firefox reader mode, so why can’t there be a web of sites that just serves plain markdown, and a simple markdown browser that renders em?
For dynamic sites tho, that work as comms platforms, and don’t just serve static content, markdown isn’t a possiblity tho. You need http frameworks, websockets, forms… all the stuff javascript and programming languages can do, and an engine to run them on.
yeah, I think the interest of the piece primarily lies in its insistence of a strict dichotomy between document and application usecases. I’m sure we can all think of examples that lie somewhere in the middle; the ordinary view is that websites exhibit a smooth continuum of interactivity necessitating a more and more app-like approach. Being forced to consider each use as strictly one or the other sparks some interesting ideas.
Because ordinary users wouldn’t want to use a separate browser to view them. They want to use a single web browser. Also, like @kixiQu@lemmy.ml said, there are a lot of sites that provide something between a document and an app. Lemmy itself is a good example of this. Which browser would you view it in, the document browser or web browser?
Well tbh I think this wouldn’t be for normal users. At least not at first, maybe not ever. I can see wanting a read-only version of Lemmy in Markdown, though. It has nice potential to limit formatting to what can easily be shoved onto an e-reader for offline perusal, too.
So the current web would be for normal users and a special, document web for techies?
Don’t e-readers support rendering HTML; epubs are based on HTML, right? And they let you customize the rendering with preset settings (font, line-height, colors) and even custom CSS. So I’m not sure I see the difference in serving a raw Markdown document and an HTML document.
I don’t see how a separate web would help. Sites that are bloated on the current web just wouldn’t be available on a document web and any sites that were on the document web could already do the same thing on the current web.
If you’re curious about the mindset behind this kind of thing and the article itself wasn’t particularly convincing to you, I recommend the FAQ about the gemini protocol. Particularly under 2.5
Thanks. I’ve been following Gemini since it was proposed on one of the tildes and I don’t find it convincing either. All of these fork the web proposals leave out non-technical users who aren’t going to care or know about the difference in these protocols and why their browser can’t view that page. I don’t think their argument in 2.5 is adequate. The only people who host Gemini pages are technical people within the fediverse/open web space and its unlikely to ever grow beyond that. If the only people posting there are people you know by handle, you could just as easily only surf their urls on the web.
I get the creative freedom and excitement that comes from building something from scratch, but these proposals are about building siloed niches instead of improving things for everybody.
I think most of what you’re saying is accurate, but you’re judging these projects by a goal they haven’t claimed for themselves. A backyard garden isn’t trying to fix the food supply chain.