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. :(
My gripe with Markdown is that it doesn’t have enough features which is why so many flavours of it exist. But it’s still very usable in most cases.
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.
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?
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.
That’s a very interesting idea! Federation already kinda attempted that and honestly Diaspora is a much better idea than Mastodon in regard that it encouraged web of documents rather than web of sentences.
However is markdown the right format? Isn’t it basically the worst format that won the human/machine document format wars? For example asciidoc is widely regarded as being superior to markdown.
Not everyone agrees with you so I’d kinda need to see a citation there. Even if the original markdown was deeply inadequate, the ecosystem these days seems to have patched up the holes in the walls, whether as a cause or consequence of its overwhelming victory in the aforementioned war.
As someone who has written books in markdown I can surely say it’s not good enough while alternatives like rst and asciidoc etc. are good enough.
Main problem with markdown is that it doesn’t support many of basic styling issues like imagine alignments, footnotes, image captions that are vital for anything that is slightly bigger than a web comment. There are glaring issues with markdown like double spaces for newlines and so on that are just bad design.
Unfortunately it seems like the ship has sailed and markdown “won” for the most part. Now let the patching commence and we’ll end up with a Frankenstein’s monster sooner or later.
I mean, I’m not just playing devil’s advocate here–your personal-experience-driven sense of what’s crucial and what’s peripheral in terms of “good enough” is valid for you, but other people clearly think differently or they wouldn’t be making a direct asciidoc v. markdown comparison in the markdown spec intro.
Anything short of LaTeX makes trade-offs to increase readability at the expense of other stuff. Extensive familiarity with a markup language decreases our ability to perceive whether it’s approachable enough for new non-technical folks. Because of that, and because of the relative greater important of their experience (I who Care about these things and am decent with installs have a million options available to me, but does my manager’s manager’s manager? Does my aunt?) I kinda have to look at the flaws (significant trailing whitespace is an abomination, you are correct) like… “well, obviously this doesn’t matter as much as my instincts would suggest.”
Footnotes are IMO a great example of something that should only be supported via plugin because boy do people have different ideas about how they should work (cf. LaTeX’s options)
glaring issues with markdown like double spaces for newlines and so on that are just bad design.
this one drives me nuts. I read an issue on this and the markdown people were insistent on letting text flow through newlines
FYI you can force newline with backslash like
Once upon a time\ there was a underwhelming text formatting standardHowever it’s not always supported.
For example
lemmy supports it (you can check comment’s source)
Github however, does not.thanks, true. my peeve is with disregarding normal newlines. from a utilitarian point of view it probably makes sense, just a personal pet peeve.
No, I definitely agree with you. Markdown is a human format so readability newlines should be soft-wrapped rather than hardcoded. It should respect newline as it was intended.
I think it makes sense if you’re imagining a workflow where something is going from terminal type display, where line width is to be enforced with rigor and no mercy, to a display format, where it’s really the CSS’s problem. That said, it has killed my old habits about distinguishing soft and hard breaks, so …
yep, as long as a main target is an html display, it makes sense. in my case, I take notes in a way that restrains my syllable count to about 10-15 per line to encourage conciseness and my target is pdf—not a use case I expect markdown to accomodate, but it would be nice if I could tell pandoc to preserve new line but pandoc defers to md rules
I think it makes sense if you’re imagining a workflow where something is going from terminal type display
Not sure what you mean by that. Terminals do soft-wrapping and any human formatting should rely on soft-wrapping rather than hard-coding paragraph formatting.
I could totally create a style switcher with Javascript, but… wouldn’t it be better if that were built into the client?
I mean, you can actually switch between different CSS stylesheets for webpages. In Firefox, this is under View -> Page Style. It’s just that essentially no webpages actually offer multiple stylesheets.
Right, but there are reasons why everyone who wanted it ended up installing extensions to facilitate this functionality.
