[HN Gopher] We should have Markdown-rendered websites
___________________________________________________________________
We should have Markdown-rendered websites
Author : timdaub
Score : 198 points
Date : 2022-11-10 15:46 UTC (7 hours ago)
(HTM) web link (ipfs.io)
(TXT) w3m dump (ipfs.io)
| indymike wrote:
| Adding a markdown handler to a web browser should be pretty
| trivial, and that's probably why it makes little sense to do it.
| lolive wrote:
| Me buying the domain name react-markdown.com and the github repo
| "react-markdown"
|
| ...
|
| PROFIT !!!
| lolive wrote:
| Damn! Already too late !
| danielvaughn wrote:
| There's prose.io which basically does this
|
| http://prose.io/
| satvikpendem wrote:
| See also https://prose.sh (I guess `prose` is a popular name in
| this space) and https://bearblog.dev.
| forgotmypw17 wrote:
| Markdown results in unintentional formatting more frequently than
| not in my experience, and it is this reason alone that I avoid it
| anywhere I have a choice to, including any software I implement.
| thih9 wrote:
| Functionally this seems like reinventing RSS.
|
| And I'd say it's about time.
| rchaud wrote:
| Just use a Markdown-based CMS like Pico. Free, open-source, and
| uses Twig templating.
| rroot wrote:
| The majority of the content you read on the web is there to lure
| your retinas so the website can shove sponsored photons into
| them.
|
| The goal of de-cluttered web is nice. But if clutter is even just
| a notch more profitable, that ain't going to happen.
| PedroBatista wrote:
| We already have HTML
|
| What we have done to it it's a different matter.
|
| Btw, which flavor of Markdown?
|
| "and if I want to do..?"(tm) Don't we'll end up with an HTML
| without angle brackets?
| donatj wrote:
| You could presumably just add a single line of JS to a markdown
| file that would render it as HTML.
| yasenn wrote:
| There is strapdown: https://github.com/chaitin/strapdown-
| zeta/blob/master/README...
|
| ``` <!DOCTYPE html> <html> <title>Hello, Strapdown</title>
| <meta charset="utf-8"> <xmp theme="cerulean"
| style="display:none;"> # title your awesome markdown content
| goes here... </xmp> <script
| src="http://cdn.ztx.io/strapdown/strapdown.min.js"></script>
| </html> ```
| donatj wrote:
| Interesting, but I feel like ven this is over built.
| <script src="imaginary-script"># Hello World
| aliqot wrote:
| YES THIS IS MY MOMENT!!
|
| https://news.ycombinator.com/item?id=33505339
| err4nt wrote:
| With modern HTML it's actually pretty easy to use markdown
| wherever you like. Though there is no built-in markdown element,
| they have built in the ability for authors to define custom
| elements. You can define your own custom <mark-down> element and
| put your mark down syntax inside and as it is, as source code
| it's nice and human readable even if we didn't do anything
| further. But we can also define how this element should render,
| and so it's very straightforward work to wire up any existing
| "markdown to HTML" library in JavaScript to consume the markdown
| contents of the tag and display rendered HTML.
|
| This is so easy to do, not just for markdown, but almost anything
| you could want to embed or work with in HTML.
| bonestamp2 wrote:
| Something pretty similar already exists, and it's free... Github
| pages can turn your markdown into a website, hosted for free:
| https://www.markdownguide.org/tools/github-pages/
| timdaub wrote:
| markdown is not a markup
| [deleted]
| innocentoldguy wrote:
| I like Markdown and use it at work, but I think Asciidoc is a
| better markup language because it is more consistent and has
| support for more things than Markdown does (e.g., better table
| support, callouts, tips, etc.).
|
| I currently use 11ty with the Asciidoc plugin for building
| websites. This setup is nice because I only have to fiddle with
| HTML and CSS during the design phase. Once that's done, nearly
| all my website maintenance is done in Asciidoc. Easy!
|
| I don't think I'd want to directly write an entire website in
| either Markdown or Asciidoc. I think, eventually, doing so would
| result in these markup languages becoming as cluttered and weird
| as the HTML/DOM/JavaScript/CSS mess is now.
|
| I think a better step to improving HTML and CSS would be to have
| the browsers support Slim (https://github.com/deepin-
| community/ruby-slim) and Sass out of the box instead. That would
| make my design phase less wordy and redundant while keeping my
| Asciidoc experience nice and tidy.
| fleddr wrote:
| It most certainly would not be a bad idea to have .md files
| render natively in a browser. Browsers also natively render
| images, videos, PDFs.
|
| That said, the idea that this somehow changes any dynamic on the
| web are mere fantasies. The masses self-publish on social
| networks. On their phones. And not even that, as most largely
| lure.
| VancouverMan wrote:
| Aside from perhaps images, I wish that browsers didn't try to
| render more complex content. I'd much rather be able to easily
| watch YouTube and embedded videos, for example, in an external
| player. And I've almost always ended up reopening PDFs in an
| external viewer, or configured the browser to do that by
| default where that option exists.
|
| Maybe Markdown isn't as much of an issue as the videos and PDFs
| are, but it seems to me like it's better handled externally
| from the browser, or perhaps by an optional browser extension.
| falcolas wrote:
| OK. Which flavor of markdown should we get every browser
| manufacturer to use?
| euroderf wrote:
| Many Markdown dialects are adopting YAML metadata, so why not
| start a file with (for example) ---
| Dialect: GFM ---
| rcarmo wrote:
| That's what I do at taoofmac.com internally. The whole thing
| is a mix of Textile, Markdown and HTML
| BiteCode_dev wrote:
| myst
| jerf wrote:
| CommonMark seems like the obvious choice:
| https://commonmark.org/
|
| It isn't as supported as I'd like, but it does exist and I've
| encountered it "in the wild" a few times, so it's not just some
| guy typing away on a website either.
| bachmeier wrote:
| After all these years, I still haven't found an important
| argument in favor of CommonMark. As I point out every time
| someone presents it as the answer, it doesn't handle things
| like math, so you still need to use unstandardized
| extensions, making the whole thing pointless.
| jerf wrote:
| The argument is that if you disqualify everything for not
| having $FEATURE, where $FEATURE varies from person to
| person, you have also essentially disqualified markdown
| entirely. As the saying goes, everyone uses only 10% of
| Microsoft Word, but everyone uses a _different_ 10% of
| Microsoft Word. Much the same thing applies to this case
| for much the same reasons. If your standard is going to be
| "I want everything in any variant of Markdown ever and also
| any plugin ever", you will end up with something that is
| just as complicated as HTML, only different this time.
| (Possibly even more complicated than HTML.) CommonMark is a
| decent solution to "I want to use Markdown", if you're
| willing to take the simplification.
|
| Note in this case I don't think there's anything wrong with
| refusing the simplification. It's just that if that _is_
| your set of your requirements, you 've disqualified
| Markdown entirely. Personally, I think that _is_ the state
| of the situation; Markdown can 't do this. Markdown and all
| of its family members and close friends _intrinsically_
| work by reducing the problem. If you refuse to reduce the
| problem, you 've refused to use Markdown. That is not a
| moral judgment; that's an engineering judgment. From the
| position the major browsers operate in, they will never
| attain anywhere near enough agreement on this to ever
| implement it without it simply becoming another monster of
| its own as everybody piles in with all their favorite
| extensions.
|
| I have some websites that run with Hugo, which is in
| principle based on Markdown, but if necessary you can have
| raw HTML pages or other things too. This is actually the
| ideal; use Markdown when it makes sense, use other things
| when it doesn't, and thus, neither of those two things has
| to carry the burdens of the other side. This is the real
| and best solution, honestly, and it also has the advantage
| that it's here now. Use whatever flavor you want, where
| ever you want, whenever you want, today. I'm doing this and
| I don't see any advantage to trying to convince the browser
| to do this. I have a deploy step regardless of what I do,
| so it's no skin off my nose whether that step deploys my
| pages raw or there's a render step in addition to the
| deploy.
| bachmeier wrote:
| > CommonMark is a decent solution to "I want to use
| Markdown", if you're willing to take the simplification.
|
| It would be very hard to make a case for CommonMark over
| something like Pandoc markdown, given that it does so
| much more than CommonMark.
|
| Note that the discussion here is markdown inside a
| browser. That's not a good place to go with a dramatic
| simplification.
| jerf wrote:
| I feel like you read the quoted sentence and stopped. I
| talk about both the browser and simplification further
| on, _literally_ the next sentence.
| The_Colonel wrote:
| Forget math, CommonMark doesn't even handle tables.
| reichardt wrote:
| HTML
| djbusby wrote:
| Asciidoc.
| GartzenDeHaes wrote:
| > AsciiDoc is a plain text markup language for writing
| technical content. It's packed with semantic elements and
| equipped with features to modularize and reuse content.
|
| Isn't that the opposite of Markdown?
| maximus-decimus wrote:
| It's basically a dsl to generate markdown.
|
| People who propose replacing markdown with AsciiDoc
| completely miss the point of Markdown in my opinion.
| pessimizer wrote:
| Asciidoc is not in any way a dsl to generate markdown.
| Being far more expressive than markdown would obviously
| prevent that.
| Ideabile wrote:
| This is the reason why Markdown isn't a good specification for
| this. But I do agree with the sentiment.
| BeefWellington wrote:
| I made a comment about how to do this as my very first HN post
| on this account[1] in a code-golf-y sort of thread:
|
| Here's the example: # Markdown header
| ## Subheader ### Section header 1.
| Numbered 1. List - Unordered -
| List [//]: # (<html><body></body><script src=
| "https://cdn.jsdelivr.net/npm/marked/marked.min.js"></script><s
| cript>var doc = document.children[0].textContent.split('\n');
| md = doc.slice(0, doc.length - 1).join("\n");
| document.body.innerHTML = marked(md);</script></html><!--)
|
| Now, whether this is wise to encourage or not I can't speak to.
|
| It would be great if browsers parsed markdown as text-only
|
| [1]: https://news.ycombinator.com/item?id=25352385#25355751
| lake_vincent wrote:
| Let's just embrace the chaos and develop a new flavor for
| _every_ browser until there are precisely 31 different flavors
| of Markdown. We cap it there, Baskin Robbins style, and then
| watch the world burn.
| thih9 wrote:
| We could have a higher level language and tooling that
| transpiles everything to all known markdown flavors and
| bundles them all. But I guess one of these 31 flavors already
| does that.
| ihatepython wrote:
| I would be on-board with this as long as we compile
| everything into WebAssembly with Emscripten first
| [deleted]
| [deleted]
| ohgodplsno wrote:
| Make a World Wide Markdown Consortium, release v1 of Markdown
| based on a randomly picked flavor, let it stagnate for decades,
| then let Google implement shadowMarkdown in Google Chrome,
| which renders at 300FPS for them, and unluckily falls back to a
| JS polyfill that ends up solving a rubik's cube before every
| character it renders. Once that has gone for long enough, let
| Google form their own MHATWG and pretend it's open while they
| keep a majority of the seats, to steer the evolution of
| WebMarkdown.
|
| Also Safari still doesn't support headings for some reason.
| falcolas wrote:
| My personal preference would be GitHub flavored markdown, since
| as a coder it includes a lot of very useful non-standard
| markups. The compromises it makes on the non-deterministic
| markup elements are acceptable as well.
| acomjean wrote:
| I think this makes sense.
|
| Many of the GitHub readmes are in markdown already, so people
| are quite familiar with it and there might already be an open
| source package that renders it out...
| bonestamp2 wrote:
| In fact, github itself can already render it out. Markdown
| based websites hosted for free on github:
| https://www.markdownguide.org/tools/github-pages/
| acomjean wrote:
| I guess it wasn't clear, but I meant those markdowns are
| rendered on everyones github page.. But the whole github
| pages thing is new to me. Very cool and seems like what
| the blog post was asking for.
|
| Its using "Jekyll" to render those "github-pages" sites
| https://github.com/jekyll/jekyll
| miroljub wrote:
| Why not use org-mode format, which is a much saner markup
| language?
|
| Being there, why not just implement full org-mode in browsers
| natively, and use it instead of html?
| RajT88 wrote:
| Agree with many folks here:
|
| Markdown is not sufficient for the task of expressing the modern
| web.
|
| All that said... We shouldn't stop thinking of ways to reimagine
| what the WWW actually is.
|
| Why not create a new web-browsery thing which uses a totally
| different language, totally different paradigm for composition,
| heck why not a totally different network transport?
|
| If you think that sounds dumb...I just described the current
| state of Netflix.
| colmmacc wrote:
| This reminded me that a long time ago I used S3 website's error
| handling feature so that S3 could render simple markdown files as
| HTML natively: http://composedit.net/
|
| http://composedit.net/dickens is actually a 404 error that
| fetches http://composedit.net/text/dickens.md and uses Javascript
| to render it. Unbelievably dumb but works. Serverless before
| there was serverless!
| 2OEH8eoCRo0 wrote:
| I hate markdown. Try to find a list of supported syntax
| highlighting for code blocks.
| malkosta wrote:
| One line website renderer with pandoc. Apply template.html to all
| _.md files in current folder. find . -maxdepth 1
| -name \*md -exec sh -c 'pandoc --quiet --template template.html
| "$0" -o ${0%.*}.html' {} \;
|
| _
| Kalanos wrote:
| i made https://aiqc.io with readthedocs/sphinx, but wound up
| doing most pages in html anyways
| robocat wrote:
| If Google upranked "documents" (simple HTML content without
| JavaScript), then there would be an incentive to publish simple
| content.
|
| Instead Google goes to insane lengths to parse JavaScript
| generated abominations, and otherwise allow/encourage shitty
| content.
| zzo38computer wrote:
| Which search engines do not execute JavaScript codes?
| [deleted]
| peter_retief wrote:
| I love using vitepress, https://vitepress.vuejs.org/
| Simplification of web development letting the main focus be on
| content and style.
| rubyist5eva wrote:
| Screw that I want C++ rendered websites.
| JW_00000 wrote:
| What happens currently if you send a file with content type
| text/plain to a browser? If the browser would just render it
| (maybe in a monospace font), you're already halfway there,
| without needing to embed a Markdown renderer in the browser.
| groffee wrote:
| I thought the real purpose of markdown was to let your users use
| HTML on your site but without the security risks of letting them
| use 'pure' HTML.
| hinkley wrote:
| There are some of us that think Markdown should be like this
| but it isn't. There are implementations in some languages that
| auto-escape any embedded HTML in a Markdown document, but for
| others they pass through.
|
| That makes Markdown great for content when the authors and
| system owners are the same people. Not so great for content
| submissions from anonymous and potentially hostile third
| parties.
|
| The project I originally had in mind for learning Elixir would
| have been Markdown based but there is no flag for disabling
| inline HTML in the current parsers and writing my own seemed
| like a bridge too far.
| blipmusic wrote:
| Markdown came to be as input for generating HTML, so I don't see
| why the suggestion is so controversial to some?
| https://daringfireball.net/projects/markdown/
|
| Also, as already mentioned, Gemini protocol does exist.
| littlecranky67 wrote:
| I had similar idea and created MDwiki in 2013 (now unmaintained):
| https://dynalon.github.io/mdwiki/#!index.md
| fedeb95 wrote:
| The article should probably read: we should write more simple
| websites. A few lines of css does the trick, usually. That's what
| I do in my tiny website http://scriptkid.it I learned from
| someone who posted here on HN the <p> trick.
| therobot24 wrote:
| isn't this why HTML was invented?
|
| agree that it'd be nice to have a markdown file be rendered
| inherently within the browser so i don't have to use haroopad on
| my windows machine, but it feels like we're just going to
| reinvent HTML
| jrochkind1 wrote:
| Agreed, original HTML was not too different than markdown
| really. (But more standard, and slightly more powerful with
| things like tables, code blocks, and definition lists, all of
| which are only non-standard extensions to markdown!)
|
| Maybe what OP really wants is a lot more people to write HTML
| without _any_ CSS or Javascript. But that's already more or
| less available, so there are reasons people don't do it to
| grapple with.
|
| Perhaps a mode where you tell the browser to ignore any CSS or
| Javascript; possibly also in this mode the browser could use
| better more readable standard html rendering, similar to what
| most markdown renderers choose by default (bigger font sizes
| and line-height, more and more even whitspace around headings,
| maximum page width, etc), instead of the legacy choices they
| are now sticking with for backwards compat.
| xigoi wrote:
| > Perhaps a mode where you tell the browser to ignore any CSS
| or Javascript; possibly also in this mode the browser could
| use better more readable standard html rendering, similar to
| what most markdown renderers choose by default (bigger font
| sizes and line-height, more and more even whitspace around
| headings, maximum page width, etc), instead of the legacy
| choices they are now sticking with for backwards compat.
|
| Isn't that just Reader Mode?
| jrochkind1 wrote:
| Oh, I was thinking of a mode that the _page source code_
| would trigger somehow, instead of the client triggering on
| a page that was possibly written to be full of complex CSS
| and JS. But also, maybe? It does seem related to OP. I am
| just brainstorming, don't have anything particularly
| thought out.
|
| I don't personally use any "reader mode" much.
| xigoi wrote:
| Such a mode would be... a CSS stylesheet.
| jrochkind1 wrote:
| Well, that's one possibility.
|
| I am imagining instead a mode that tells the user-agent
| "Use your own standard HTML stylesheet, and it's allowed
| to change and be updated over the years, to fix bugs and
| improve design, you don't have to stick with your default
| styles from 30 years ago,' but "use the same stylesheet
| you are using for other pages in this mode, I don't want
| to have to come up with it, and I don't want it to be
| fixed in time to what I come up with today either or
| require my maintenance"
|
| That is, i suppose, more like "reader/readability mode"
| in all those aspects--but triggered by the source instead
| of by the user.
|
| But, sure, a CSS stylesheet is another thing. I'm just
| thinking around the use cases I think OP is setting out;
| you can do so too, with other suggestions, you don't have
| to try telling me I mean something other than I mean to
| do so!
| xigoi wrote:
| Gemini. You're describing Gemini.
|
| https://gemini.circumlunar.space/
| LAC-Tech wrote:
| Gemtext is a bit less capable than markdown, isn't it? IE
| there's no inline images.
| rcarmo wrote:
| There are, but the markup is too simple and too "pure" to be
| useful in any meaningful way.
| xigoi wrote:
| The whole point is that the client decides the presentation.
| If it wants to display images as inline, it will, if not, it
| won't.
| LAC-Tech wrote:
| Right, I guess the gemini browsers I tried did not display
| them inline.
| xigoi wrote:
| I think Lagrange (the fanciest Gemini browser I know of)
| has the option to do that.
| eurasiantiger wrote:
| One could use Apache2 .htaccess to set up a directory
| header/footer which load a script (hidden from listing in
| .htaccess) which parses a .md file listing into a list of
| articles, and fetches a couple of the first ones as a front page.
| Then just use a URL fragment to track which article is open, and
| fetch & render that article's markdown fully onto the page.
|
| Disable JS and you have a list of markdown files. Enable JS and
| get a website.
| ape4 wrote:
| That page has <link rel="stylesheet"
| href="/katex.min.css"> <script
| src="http://localhost:8888"></script>
|
| The .css file doesn't exist and what's with the localhost access?
| steve_john wrote:
| pie_flavor wrote:
| > We really need a new publishing tool for everyone that doesn't
| require intricate knowledge of how the entire web computing stack
| functions.
|
| That tool is called HTML. It is usually supplemented by CSS.
| Every Markdown element has a one-to-one translation to it. This
| webpage is a particular stylesheet, plus basic HTML elements that
| you could write in <> style just as easily as you could write
| them in *_# style. If HTML requires particular defaults to look
| right, then that is a really great reason to fix the defaults,
| but not a really great reason to junk the whole thing and start
| over.
|
| Markdown isn't particularly good, it isn't particularly
| standardized, and it isn't even compatible with reader mode (e.g.
| images). Just write HTML. Browser standards have not _degraded_
| to the point that you need to write a web page differently than
| people wrote them fifteen years ago for it to look the same; a
| toolbox with a million complicated tools and one obvious
| screwdriver is not a toolbox that makes it very hard to unscrew
| screws.
|
| https://xkcd.com/927/
| jrm4 wrote:
| People are "big-picture" missing why this is an important idea. I
| had a prof put it like this once: The great tragedy of the web is
| the following:
|
| HTML made the web easy to read.
|
| But you know what made the web easy to write? Facebook. Facebook
| was undeniably the technology that made it so that roughly
| _everybody_ could write things on the web to be read by everyone.
|
| I really like the direction of this, because it points toward the
| possibility of a "web that is easy to write."
| greenthrow wrote:
| This is nonsense. There were tons of things that made the web
| easy to write before FB. That is not what made FB successful.
| It was a combination of a lot of little features plus the big
| innovation that your profile had to be your real life identity
| early on. That was the thing prior social networks didn't do.
| It enabled the uniquely Facebook experience of being able to
| find past friends and more distant family.
| richardfey wrote:
| > It enabled the uniquely Facebook experience of being able
| to find past friends and more distant family.
|
| This came _afterwards_. In the beginning it was just a
| showcase of life moments to share with others. Lots of fun
| and lots of cringe.
| pessimizer wrote:
| > the big innovation that your profile had to be your real
| life identity early on.
|
| This came after facebook was wildly successful, so not early
| on. I also have never met a single person who was attracted
| by it, or was confused as to who their friends were before it
| existed. That being said, tying real names to online identity
| allowed facebook to buy data from brokers to fill out the
| sliced up audiences they sell to advertisers, so maybe it was
| important to their profitability.
|
| What made FB successful was that it was a platform that other
| developers could program for, so it filled up with games and
| quizzes. Farmville, "Which Harry Potter Friends Spice Girl
| Are You?" etc. was all the edge that it took to kill myspace,
| a site which seemed to stop any sort of development about 10
| minutes after launch.
|
| But, as you say, even myspace made it very easy to write on
| the web. You could scribble on other people's "walls", put
| whatever you wanted on your own page, and every profile came
| with a blog.
|
| Against what you say, however, is the timeline where you
| could just post random crap and all of your friends would see
| it and comment on it; the dopamine stream. There's no easier
| way to write than to spit out a random sentence or upload a
| random picture, and broadcast that instantly to hundreds of
| people.
| jrm4 wrote:
| What technology IN REALITY, raw numbers, got more people to
| "type something into their computer for the purpose of
| multiple other people to read?"
|
| Facebook, and nothing else much comes close.
|
| (Again, I say this as someone who mostly hates it)
| greenthrow wrote:
| Now you're moving the goalpost. You originally implied FB
| making the web easy to write was the major innovation that
| lead to its success. I pointed out that simply giving
| people a dirt simple text box had been done many times
| before. There was nothing special about that part of FB.
|
| I am not dumb enough to argue that FB wasn't hugely
| successful, so your attempt to shift the argument away from
| your original point is silly.
| jrm4 wrote:
| No, you're misunderstanding the difference between "what
| you believe to be easy" and "what actually was easy."
|
| Popularity is better _objective proof._ You _believe_
| that a text box was easy, but still, people weren 't
| using it.
|
| Facebook is actually what got used.
| ozim wrote:
| I have to agree with jrm4 - all the things you pointed
| out don't explain why FB groups and markets are so
| popular. There is also bunch of businesses that don't
| have their own website, just FB page - which is not
| comparable to "giving people simple text box".
|
| It is simplified web experience from point of business
| owner, just drop logo, type in your company name and you
| have web presence - which happens to be where people are
| because they had friends/family there anyway.
| Dylan16807 wrote:
| Getting people to do something is very different from
| making it easy. There's overlap but that overlap is just a
| fraction.
| ludwigvan wrote:
| This is a great idea. First browser that implements this natively
| gets my vote!
| paxys wrote:
| This misses the real point of Markdown, which isn't to be simple
| or opinionated but to be _readable_ by the end user in both forms
| (raw or rendered).
|
| In case of a web site there is never the expectation of the
| source being easy to read for the end user. If you want to create
| a simple page - great, go for it. The only minor change will be
| replacing markdown tags with HTML ones. And there's plenty of
| tooling which does that trivially.
| zzo38computer wrote:
| I get a 429 error.
| bccdee wrote:
| Markdown is a convenient but deeply limited markup language with
| only a small subset of html's features. And yes, limitations are
| good because we want documents not web apps, etc, etc, but I mean
| "images can't have captions" limited, "navigation bars don't
| exist" limited. Actual important features of html don't exist in
| markdown, which is why almost every markdown platform ends up
| adding extensions and shortcodes. Why use markdown at all? Just
| use html.
|
| "But html isn't style-agnostic" yes it is. _CSS_ isn 't style-
| agnostic. Instead of a markdown browser, how about a browser with
| a fixed stylesheet and no js? You don't even need a browser for
| that, that could just be a userscript that gets plugged into an
| existing browser. It'd break non-compliant websites that require
| javascript or custom css, but so would a markdown browser. Most
| people wouldn't write content for it, but most people wouldn't
| write content for a markdown browser either.
|
| "But html is cluttered" it doesn't have to be. This is a valid
| webpage: <!doctype html> <title>Page
| Title</title> <h1>Page Title</h1> <p>Lorem
| ipsum dolor sit amet, consectetur adipiscing elit. Ut ac
| lorem ut massa euismod vestibulum. <p>Nullam rutrum
| blandit eleifend. Aenean a varius diam. Morbi sodales
| velit nunc, vel vestibulum lorem tempus sodales.
|
| Personally, I prefer writing in markdown, but that's no reason to
| insert a markdown renderer into browsers. HTML can already be as
| sleek and readable as you want. If we added a new type of markup
| for anybody with a personal preference, we'd never stop.
| SPBS wrote:
| Exactly what I was thinking, by omitting the <html> <head> and
| <body> HTML can be quite concise [1]. Additionally the closing
| </li> can be omitted from lists and <li> barely a step over
| using - for bullet points.
|
| The worst part about HTML is the links, though. Anchor tags are
| awful. Having to repeatedly type <a href="..."> and closing
| with </a> is wayyy too boilerplate much for for something that
| is simply surrounded with [square](brackets) in markdown.
|
| [1] I go to https://meiert.com/en/blog/optional-html/ for
| reference.
| fiedzia wrote:
| Plain HTML would be great, its just browsers holding it back.
| Without CSS, it looks unacceptably ugly.
| nwienert wrote:
| just hit reader mode
| fiedzia wrote:
| My browser doesn't have one, and even if it did the point
| is that it should look good without any effort.
| robinsonb5 wrote:
| The fatal flaw of HTML (and XML for that matter) is that the
| tags have the same visual weight as the text they're
| delimiting, which makes for a sense of clutter even in your
| minimal example.
|
| Markdown really scores here, by having a pleasing plain text
| representation as a goal from the outset, and I've love to see
| it used more widely for web pages.
|
| I'd also love to see it more widely used for offline reading,
| too - the help files in an application really shouldn't need to
| invoke a web browser to view them when a lightweight markdown
| viewer would do the job. Not that there _is_ a lightweight
| markdown viewer, mind you!
| 5560675260 wrote:
| > tags have the same visual weight as the text they're
| delimiting
|
| IMO this issue should and can be easily solved by
| editor/viewer by rendering tags with lower contrast.
| robinsonb5 wrote:
| Yes, that's a perfectly viable workaround, but it's still a
| band-aid that requires expending resources that wouldn't
| need to be spent if the markup method had been better
| chosen for readability. (To be specific, I believe the
| angle-brackets are the main culprit.)
| tannhaeuser wrote:
| HTML is based on SGML, and SGML has _short references_ to
| handle lightweight custom syntaxes. For example, you can
| define that an asterisk appearing in your content within a
| <p> element is replaced by <em>, and moreover define that an
| asterisk appearing within <em> content is replaced by </em>,
| toggling emphasized text tags. So SGML very much acknowledges
| the need for lightweight markup, but the SHORTREF feature,
| like everything else requiring markup declarations, didn't
| make it into the XML subset of SGML.
|
| HTML itself doesn't have these and other features (such as
| basic text macros) because SGML was understood to be
| available at least at authoring time.
| ElemenoPicuares wrote:
| Markdown is undoubtedly more readable, but HTML can be more
| readable than most people make it. And considering that the
| ultimate goal is to wind up with a layed-out, styled
| document, its capabilities in that regard are just plain-old
| more important, especially since markdown isn't going to
| replace WYSIWYG editors any time soon, and almost everybody
| who needs to know HTML can learn it relatively easily.
| Browsers collapse white space by default, so you've got a lot
| of flexibility with its formatting:
| <!doctype html> <title> Page Title
| </title> <h1> Page Title
| </h1> <p> Lorem ipsum dolor sit
| amet, consectetur adipiscing elit. Ut ac lorem
| ut massa euismod vestibulum.
| <p> Nullam rutrum blandit eleifend. Aenean a
| varius diam. Morbi sodales velit nunc, vel
| vestibulum lorem tempus sodales.
|
| --or-- <!doctype html> <title>
| Page Title </title> <h1> Page Title </h1>
| <p> Lorem ipsum dolor sit amet, consectetur
| adipiscing elit. Ut ac lorem ut massa
| euismod vestibulum. <p> Nullam rutrum blandit
| eleifend. Aenean a varius diam. Morbi sodales
| velit nunc, vel vestibulum lorem tempus
| sodales.
|
| I get why many developers like this idea... Web developers
| are responsible for implementing the complex user-facing
| parts, and their primary weapon is text: doing extra work
| sucks, and when you're a hammer, everything looks like a
| nail. But developers are not designers, and design not being
| left to developers in mature organizations is no accident.
| Absolute, deliberate, limiting simplicity is always an
| attractive argument if you dismiss the value of, or maybe
| don't even understand the reason for the complexity. I won't
| deny the advantages of reader-view-level simplicity in web
| design: it's easier to visually parse, more performant, and
| easier to navigate compared to most web pages, similar to how
| books compare to magazines-- but about 225 million people per
| year in the US read magazines and I assure you most of them
| would not choose to have textural printouts in lieu of their
| current form. While people like having the option of a
| uniform, grey, easily visually parseable mode to view
| webpages, that's probably not what they want even _most_ of
| the time, let alone as a deliberate limitation.
| robinsonb5 wrote:
| I may be that rare exception - a hobbyist developer who
| does design work as part of $dayjob.
| ElemenoPicuares wrote:
| I don't think that's as rare as people say, especially in
| smaller organizations.
|
| Having an art school design education and a bit over a
| decade in (mostly back-end) web development, I've had
| plenty of _deseloper_ type roles. If they fall under a
| design or marketing department, they 'll spend 80% of the
| time doing design work and try to throw it together on
| some shitty wysiwyg monstrosity, ignoring performance,
| stability, maintainability, etc. If they fall under
| technical departments, design, ahem, _decoration and
| polish_ is something to be applied at the end, if there
| 's time, after the _real work_ is done. Either way,
| having the same group of people responsible for two
| halves of that coin rarely yields a good balance, and
| they almost never pay any real attention to usability ...
| at least not for use cases that don 't exactly mirror
| their own. Seems to me that replacing the flexibility of
| current markup and styling tools with simple markdown and
| reader-type layouts is just trying to apply the tech-
| focused solution to the entire problem the way Flash
| tried to do the opposite.
| kridsdale2 wrote:
| IMO the main issue with writing HTML is it takes a two-armed
| key-chord to do a < or > char.
| iso1631 wrote:
| Not entirely sure what you mean by "two-armed key-chord".
| It's shift-, or shift-. -- my keyboard's bottom line goes
| <shift>\ZXCVBNM,./<shift>. < is right-index and right-
| pinky, and > is right-index and right-pinky (as shift is so
| much wider)
|
| Now sure, some are home row afficiandos, and having # on
| the home row is certainly beneficial to those as your
| right-index can stay on J as god intended
|
| Or do you have a different keyboard layout to me. Keyboard
| layouts - especially the location of things like
| ,./<>?@;'#:@~[]{} vary a lot depending on the country you
| are in.
| douglaswlance wrote:
| You already can render markdown. It shows as what it is: text.
|
| If you want to render markdown as something else, you need to
| define what that other thing is. If you're suggesting we render
| it as a webpage, well webpages are made of HTML and CSS--so
| you're saying you want to render markdown as HTML/CSS.
|
| We can already do that. There are a plethora of tools available
| to do that.
| [deleted]
| timdaub wrote:
| HTML is also plain text. The blog posts defines it. Pretty
| render md to a perfectly readable text like reader mode on all
| browers and aspect ratios.
| karaterobot wrote:
| Two problems:
|
| Most people don't want the simple websites you could render in
| basic Markdown, that's why we don't have more of them already.
| How many of the top 1000 websites are a column of text and
| nothing else?
|
| If most people wanted simple websites, they would write them with
| a WYSIWYG editor, they would not learn Markdown.
| notriddle wrote:
| I've seen a few people on here recommending everything from "just
| use HTML" (which misses the point) to "just use Gemini" (which
| misses the point even more).
|
| Why not HTML? Why not Markdown? They aren't self-contained.
|
| * A web page written in either format can leak your IP address to
| external bad actors because of the way inline images work.
|
| * Loading resources from more than one server is a reliability
| and security problem, and it performs bad on initial load (it's
| great for subsequent loads, since external resources can be
| cached, but initial load time is bad and tech designers should
| really spend more time thinking about worst-case perf than about
| average-case).
|
| * Downloading a web page is overly complicated. I should be able
| to download a page to my computer and never have to worry about
| the origin server going away, and that's not possible on the
| HTML5 web. This is one of the main reasons for the enduring
| popularity of PDF. IPFS, in particular, would benefit from a
| self-contained document format, because it needs to know the full
| set of dependencies in order to pin a page as a whole, and ensure
| that you don't accidentally pin an HTML file without pinning its
| images and wind up with a broken site.
|
| Sure, you can make HTML pages that are self-contained, but
| because they aren't always, people don't build workflows around
| them.
|
| Why not Gemtext/Gemini?
|
| * Nobody but nostalgic nerds cares about simplicity of
| implementation. I mean, come on, Markdown is even harder to parse
| than HTML is! Nostalgic nerds might be a worthwhile demographic
| to appeal to, but I think IPFS wants a wider audience than that.
|
| * Inline images are not optional. Too many great creators with a
| lot of worthwhile things to say are either _creative artists_ or
| _technical artists_. In the BBS era before inline images were
| practical, it didn 't stop people from drawing; they just relied
| in ANSI and ASCII art, and "let's go back to typewriter art" only
| appeals to nostalgic nerds.
|
| * And once you have inline images, you have to offer rich text
| layout features like tables, otherwise people will start posting
| pictures of text to work around your missing features (which
| _sucks_ for either accessibility, because blind people can 't
| read them, or it sucks for simplicity, because deploying OCR is
| even more complicated than just offering decent text layout).
|
| If I had to pick something? https://en.wikipedia.org/wiki/EPUB
|
| * You can download an EPUB, and when the original host goes away,
| it still works! Pinning an EPUB in something like IPFS can work
| without requiring the CDN to know anything about the file format,
| since EPUBs are self-contained.
|
| * Tooling already exists. It's just XHTML in a ZIP file anyway,
| but there's also EPUB-specific tooling (for example, the Texinfo
| release announcement a few days ago mentioned that you can export
| EPUBs from GNU info manuals).
|
| * It supports text and image layouts that writers demand.
|
| * There is one standard.
| willi59549879 wrote:
| Edge (the version that was killed) was able to read epubs. I
| quite liked that feature. Now I just use an e-reader or pdf
| fiedzia wrote:
| Self-containment is entirely unrelated to a format. You could
| do self-contained markdown, HTML or anything else if you wanted
| to.
| notriddle wrote:
| Of course it's related to the format. Many formats, like PNG
| and Gemtext, are inherently self-contained, while other
| formats, like HTML and SVG, are not.
|
| Annoyingly, EPUB isn't inherently self-contained [1], but
| external access is explicitly optional [2], and it does make
| self-containment easier, because you can reuse resources
| across multiple pages, whereas HTML requires you to either
| duplicate the resources across multiple pages, or you have to
| build your thing as a single massive HTML page.
|
| [1]: https://www.w3.org/TR/epub/#sec-resource-locations
|
| [2]: https://www.w3.org/TR/epub-rs/#sec-epub-rs-network-
| access
| fiedzia wrote:
| > other formats, like HTML and SVG, are not.
|
| You can mandate them to be if you are building something
| that uses them. If you don't have control, than its up to
| someone else to decide, and people wanted to be able to
| link remote resources.
| tomp wrote:
| The author is lying. The source isn't actually a markdown
| document, the source is HTML (you can easily verify this by
| right-clicking and selecting "View Source")
|
| It's actually quite easy to _actually_ render markdown pages in a
| browser. Start with this: <!doctype html><meta
| charset="utf-8"><script src="notes-all.js"></script><textarea>
| ## MarkDown *HERE*!!!!!
|
| and "notes-all.js" contains something like this:
| document.write('<link rel="stylesheet" href="css/style.css">'));
| document.addEventListener('DOMContentLoaded', (event) => {
| var m = markdownIt({'html': true, 'linkify': true});
| var t = document.querySelector('textarea'); var d =
| document.createElement('div'); d.setAttribute('id',
| 'content'); d.innerHTML = m.render(t.value);
| t.replaceWith(d); });
|
| followed by markdown-it source code
| harryvederci wrote:
| I think the author means that they wrote a markdown document,
| which then was transformed (by a CI/CD pipeline, for example)
| to the html you see when you inspect the source.
|
| I like your "Serve markdown, transform through a client-side
| script" approach though, so upvoting nonetheless.
| graypegg wrote:
| HTML is already a markup language. You could just as easily make
| basic websites using HTML and some basic inline CSS.
|
| (They'd even have some extra features missing from Markdown that
| I'd consider still part of a basic content formatting suite like
| floating or multi-column layouts. They'd even have a defined
| standard for machine readable metadata!)
|
| The problem is that people don't make websites like that very
| often, even though they can. This is trying to solve a problem
| that doesn't currently exist.
| buro9 wrote:
| HTML is a subset of Markdown.
|
| You can include in Markdown any and all HTML.
|
| What Markdown provides here is an even lower barrier to entry
| for the majority of people... they just write text, learn a
| fraction more Markdown to so more... and if they want total
| control they eventually learn HTML too.
|
| It's not mutually exclusive... Markdown includes HTML.
| rchaud wrote:
| Markup is not the barrier to entry. Nobody in 2022 is
| building HTML-only websites. Even 20 years ago CMSes let
| hundreds of thousands of people write blogs online.
|
| Let's say somebody takes the time to learn Markdown. Then
| what?
|
| Are they going to then also learn how to select a web host,
| how to set up SSL, how to use CSS to make the website look
| the way they want?
|
| They won't. That's why Wordpress, and later Facebook, won the
| online publishing wars.
| ravenstine wrote:
| So are Markdown rendering libraries entirely pointless? I'm
| not sure where you'd get the impression that HTML is a subset
| of HTML rather than Markdown being a _superset_ of HTML.
| (even that is very reductive, though)
| isitmadeofglass wrote:
| > HTML is a subset of Markdown.
|
| Yes, so all websites are already written in markdown. Its
| just tjat No browsers support the typical header/list
| shorthands, but that doesn't matter because even if they did
| you'd still need more tages to get interactivity and styling
| working.
|
| People aren't imagining a world where markdown makes anything
| simpler they are imagino by that a format change would make
| people build less complex websites. But why would they? It's
| not HTML that makes the Twitter front end or Facebook
| complicated, it's the desisted functionality, which wouldn't
| change even if the spice code looked more like markdown and
| less like html.
| graypegg wrote:
| --I'd say it's the other way around isn't it? Wouldn't
| Markdown be a subset of HTML, since all markdown can be
| expressed in HTML but not all HTML can be expressed in
| Markdown?--
|
| Edit: Markdown can contain HTML that gets meaningfully
| interpreted as markup as well.
|
| I'd also say HTML is not difficult to write, even for someone
| new to the concept. I don't think anyone making their
| GeoCities homepage was too strained learning HTML, and those
| were leagues more advanced than what's possible with only
| Markdown!
|
| If you want people to be excited about self-publishing online
| again, it's probably best to start with the markup language
| that allows for some fun :)
| ncphillips wrote:
| You've got it backwards. Markdown is a superset of HTML.
|
| Markdown specific syntax is not valid in HTML pages, but
| all HTML is valid in Markdown.
| [deleted]
| enos_feedler wrote:
| If say 10% of the pool of internet users at the time could
| make an HTML page on Geocities, what % of today's pool of
| internet users could do it? The pool has gotten much larger
| and much less tech savvy on average.
| graypegg wrote:
| Well I guess the next logical question is what % would
| not make an HTML page, but would make a Markdown page.
|
| I feel like the Venn diagram is nearly a circle, but I
| don't have anything to back that up.
|
| To most people, symbols and words being "special" in some
| text = coding, I'm still not convinced that the cognitive
| load of:
|
| # my title
|
| Is different than
|
| <h1>my title</h1>
| thih9 wrote:
| Then again, personal content is no longer shared via
| personal homepage but via
| Facebook/YouTube/TikTok/Medium/etc these days.
| pocketarc wrote:
| As far as I'm aware, you can write any HTML in Markdown,
| and it will be rendered normally. So Markdown can indeed
| contain any and all HTML.
|
| HTML can't contain Markdown at all - a ### in HTML does
| nothing but a <strong>hello</strong> in Markdown does
| exactly what you expect it to.
| graypegg wrote:
| Oh I see, my mistake. Thanks!
| masswerk wrote:
| To be fair, you can include Markdown inside script tags
| (assign a custom type like "text/markdown") and render
| this (the script's innerHTML) by another script.
| jbverschoor wrote:
| So you can't create a simple markdown rendered without
| creating a full-blown html/css renderer. So a cli
| renderer doesn't make sense either in that case.
|
| Html 'support' is just a _hack_ for any shortcomings of
| markdown.
| pdpi wrote:
| If you think about it in terms of syntax, then sure.
| Markdown is a superset of HTML. I think it's much more
| meaningful to compare their semantics instead. From that
| point of view, Markdown is a nicer, more human-readable
| syntax for a very small subset of html, plus an escape
| hatch to reach the rest of HTML using conventional
| syntax.
| barrucadu wrote:
| A ### in Markdown doesn't "do" anything either, the
| reader just has to know that it denotes a 3rd level
| heading.
| kuramitropolis wrote:
| Markdown allows you to just write HTML in it. That makes it
| a superset of HTML.
|
| HTML is not difficult to write, it's difficult to edit.
|
| A S-expression-based dialect of HTML (with macros!) would
| be fun.
| ajkjk wrote:
| [deleted]
| tinyspacewizard wrote:
| I would like Markdown encoded as s-expressions... but
| watchagonnado
| Shtirlic wrote:
| It's already done in Gemini protocol with Gemtext format
| (https://gemini.circumlunar.space/docs/gemtext.gmi)
| mdaniel wrote:
| > This is the only supported list syntax. Using - instead of *
| like in Markdown will not do anything. Nested lists are not
| supported.
|
| yeah, no. I can't tell if this is some kind of parody or what
| awinter-py wrote:
| I mean rendering JSX would be incredible from a 'I hate waiting
| for build' perspective
|
| babel has a trick where you load their JS and mark your <script
| type="text/jsx">, but it is slow AF
|
| more generally, pluggable templating / rendering engines would be
| neat
| pclmulqdq wrote:
| We already do. They use static site generators to produce HTML (a
| good interchange format) from a customized form of markdown
| (which is not standardized at all and very customizable). This
| state of the world is totally fine - it works well for both
| viewers and content producers.
| fasteo wrote:
| ... so that in 10 years Markdown will become the same clusterf*ck
| as HTML is today
| gjvc wrote:
| Yes, we should have open standards for content-types and dynamic
| fetching and updating of code from trusted locations on the
| network. Then the browser itself becomes little more than a
| container for executing rendering code, with plugins for every
| content-type under the sun. But we are on a different timeline.
|
| With WASM, this may yet still happen.
| whywhywhywhy wrote:
| Markdown having *italics* _italics_ **bold** __bold__ instead of
| _italics_ *bold* was such a mistake.
|
| No idea how non-technical people were ever supposed to grasp
| that.
| e40 wrote:
| Website is broken, but I infer from the comments that this would
| fit the bill:
|
| https://github.com/DannyBen/madness/
|
| My company uses it internally for a load of things. I love
| writing in MD and pushing to gerrit and when it is submitted the
| change is live.
| corysama wrote:
| So, https://casual-effects.com/markdeep/ ?
| friend_and_foe wrote:
| There's Gopher, Gemini, a myriad of static site generators that
| render markdown...
|
| I like the idea of my browser rendering markdown. But it's not
| going to solve the problem, as long as the same client
| application that renders documents can also render web
| applications, people looking to bait you with a document into
| running software on your machine will just publish web
| applications with some text inside of interest to you. What's
| needed is separate client software for running web applications
| and rendering documents, and a different protocol for each, where
| we fucked up was using http for everything.
| zzo38computer wrote:
| While I believe you, and that the currently state is too messy,
| nevertheless it is possible for some implementations to be more
| limited or to have options for the user to disable some
| features if desired.
|
| It is true, there are other protocols and other file formats
| they are good for different purposes, and you should not try to
| use one for everything. (In my opinion, this is true of Unicode
| as well; it is messy and doesn't work well to use Unicode for
| everything, either, nor HTML or HTTPS for everything, or cell
| phones for everything, or the government for everything, etc.)
|
| It would also be possible to serve text/gemini files with HTTP
| too, and I also have modified my browser to be able to display
| them (also local files too), this is not common.
| nonrandomstring wrote:
| A good summary.
|
| People forget what the M in HTML stood for.
|
| The slow drift of Hypertext from nice separation of document
| markup and presentation to "web applications" and browsers that
| are mini operating systems makes those old jokes about Emacs
| pale in comparison.
|
| The modern bloat-ware browser is a calamity of code, most of
| which I have no use for and no trust in. So I use a text based
| browser without JavaScript - and I love it!
|
| If I want to run your code on my machine I'll install a proper
| application that has at least been through some basic code
| signing, packaging and secure distribution channels.
|
| Gemini seems like one of the few hopes for breaking away from
| the madness of "Web" and restoring some sort of sane, plain
| document publishing for ordinary people to read and share
| information.
| schkolne wrote:
| This convo reminds me of MDX -- https://mdxjs.com/ -- allows you
| to mix JSX with markdown, popular for making documentation pages
| for design systems.
|
| A lot of the limitations of MD mentioned here are alleviated by
| allowing arbitrary JSX, which of course is optional for users who
| want something more basic.
| hit8run wrote:
| Why not simply use text/plain content type when going fully
| minimal?
| 0xbadcafebee wrote:
| I spend a good part of my week writing docs. The docs that come
| out of Markdown are hard to read, hard to maintain, long, ugly,
| and limited, requiring postprocessing for simple things like a
| Table of Contents. Websites need content to be even richer than
| docs (and no, Mr. Developer, what _you_ want is not the sole
| requirement of the rest of the people on the planet). If you want
| to make an entire website out of Markdown, make Markdown suck
| less.
|
| I think we need a configuration format for websites.
| Configuration formats are designed for humans first, and fit to
| purpose. What might that format require? Probably: style, layout,
| macros, emeddable objects, inheritable/overrideable values,
| logic, loops, etc. Basically a DSL. You describe independent
| blocks (layout, style, content, etc) and the browser takes the
| instructions and renders the result. Not insanely different in
| concept than HTML/CSS, but everything could use one common
| format, in a manner more human-friendly than we have now, content
| would be independent of form/function, and none of it would
| inherit some unrelated design principles from some antiquated
| non-human-friendly technology. text "Employees
| table description" | This is a description of the
| employees table. The name and e-mail address are listed
| to the right. table "Employees" @Name ~>
| Frank Suzanne Rahul
| Aman @E-mail address -> frank@me.com
| suzanne@me.com rahul@me.com
| aman@me.com style "table.Employees" @Name
| column bgcolor "green" @"Email address"
| rows bgcolor "gray" layout "main-page"
| panel "1" align: left content
| "text.Employees table description" panel "2"
| align: right-of "layout.main-page.1" content
| "table.Employees"
| jerf wrote:
| You've described a static site generator, which I mean not as
| "hey you should have known that" but more as a "good news, that
| basically exists and you can use it now!"
|
| No, there's no standard with static site generator, but there
| never will be. The combination of the wide variety of needs and
| use cases and the ease of starting one of these up (I can
| literally bash together the skeleton of a useful static site
| generator in 4 hours, and this isn't just "oh I could recreate
| dropbox in a weekend if I wanted to because I am a swaggering
| HN programmer", it is something I've literally done rather than
| sit down and learn someone else's because it was faster to bash
| something together than read docs) means that there will never
| be a shortage of these, and none of them will ever managed to
| capture 99% of the market to become a de facto standard.
|
| I basically have websites that work the way the author
| describes. There's no particular need or benefit from expecting
| the web browsers to do this. There are disadvantages to this
| approach but the web browser directly rendering the markdown
| doesn't really solve any of them.
| shadowgovt wrote:
| I've been using Hugo to translate Markdown into my static site,
| and I've been extremely happy with it.
| thenerdhead wrote:
| Don't forget that markup refers to the document's formatting and
| markdown is a specific markup library that converts text-to-HTML.
| So technically all browsers do support markdown.
|
| We should re-visit the actual term "mark-up" which refers to
| decorating copy during the editing phase. I think many people
| agree that using markdown to "mark-up" copy on websites is
| easier.
|
| https://daringfireball.net/projects/markdown/
| dgan wrote:
| why not OrgMode websites? it handles tables too!
| satvikpendem wrote:
| Recently there was a thread about GitHub Blocks, interactive
| elements within READMEs and Markdown files in general. If we
| could standardize that and support it, that would be cool.
|
| Also, isn't this basically what HTML does anyway?
| toastal wrote:
| You mean stuff that is already standardized and in Asciidoctor?
| That would be easier than trying to wrangle in all of these
| forks/flavors with all their incompatible extensions and tools
| all while have _no_ way to handle metadata?
| robocat wrote:
| Deliver as markdown, but with a single line header:
| <!DOCTYPE html><title>Foo</title><script
| src=mydelayedmarkdownparser.js></script><PLAINTEXT>
| [[insert your markdown here]]
|
| A document delivered as pure markdown, that will get spidered by
| any search engine that renders JavaScript (or that reads the
| document as text), and you don't need to ask anyone to change
| anything. HTML has no closing </plaintext> end tag, so markdown
| can be free-form and securely include any unescaped _< >"'_
| characters (raw HTML code) you need into your markdown and the
| browser will treat it as pure text (unlike the <XMP> tag which
| can be ended with </XMP> - even weirder lexing).
|
| The key is that although the <plaintext> tag is deprecated, every
| browser has to support it (partially because removing support for
| <plaintext> would cause security issues for existing pages!) The
| <plaintext> tag is really very special, quite different from any
| other tag, and it radically interrupts HTML document
| lexing/parsing.
|
| Use something like https://whatismarkdown.com/how-to-have-
| markdown-in-realtime-... to read the content of the <plaintext>
| and dynamically render your markdown into HTML.
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pl...
|
| Edit: and of course there is the HTTP header _Content-Type: text
| /markdown_ which could be used by browsers to render a markdown
| document - see "The text/markdown Media Type" RFC
| https://www.rfc-editor.org/rfc/rfc7763.html and
| https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
| zzo38computer wrote:
| What is needing then, is adding the "type" attribute in
| <plaintext> command, that browsers with their own
| implementation can optionally use it instead in order to render
| with the user's settings if desired.
|
| However, that still forces you to serve HTML, so it is not
| good. My idea is adding a "Interpreter" response header, which
| indicates which files can be used to render files (documents,
| audio, video, pictures, etc) that the client implementation
| does not understand already. The end user can also specify
| their own overrides, if desired.
| [deleted]
| joshmarinacci wrote:
| What you are describing is a technical solution to a business and
| social problem. It won't actually solve what you think it will.
| jaffathecake wrote:
| Completely agree. It's already pretty easy to create a nice
| readable page with an off-the-shelf stylesheet & semantic
| markup.
|
| Sites choose not to do that, for non-technical reasons.
|
| For all it's faults, this is partially what AMP aimed to solve,
| by restricting what developers could do. However,
| developers/businesses didn't adopt AMP because it was a better
| user experience, they adopted it because it got them higher up
| in Google search.
| armchairhacker wrote:
| We should have multiple formats besides HTML. In fact we already
| _do_ have this, in the "Content-Type" response header, we just
| should use it more
|
| Send data with Content-Type text/json and Firefox will display a
| fancy JSON viewer, send data with text/plain and Firefox displays
| plain text, pdf files, downloadable files, etc. Well, we can add
| text/markdown where the browser automatically renders markdown
| files. And when the next HTML replacement comes out we can add
| that as well.
|
| What about backwards compatibility? We already have that too:
| webservers can check the User-Agent request header, and return
| converted data for older browsers. Though we'd need a centralized
| database or fallback solution to support niche browsers...
| sgbeal wrote:
| FWIW, just a couple of weeks ago we started doing that for a new
| sqlite subproject: https://sqlite.org/wasm
|
| With the exception of one page, all of them are markdown,
| rendered on demand by the Fossil SCM. The one exception is an
| HTML file, which we need in order to host a small JS application.
| another_story wrote:
| When you say rendered on demand, you mean by the client, as in
| a page request? Why not just rerender to HTML on developer
| change? Genuinely curious why rendering on demand is preferred
| in this case.
| twobitshifter wrote:
| Maybe they cache the rendered version? This would keep
| rendering to a minimum
| dreadlordbone wrote:
| I would love to use more markdown but I need multidimensional
| layouts decided by the author (variable columns with text and
| images) and I haven't seen anything like this.
| hospadar wrote:
| I mean it _sounds_ good, but how will we cram a million ads down
| user's throats and measure every twitch of their input devices?
| It's almost as though the author is suggesting that web site
| proprietors might be more interested in "serving content" than
| "driving engagement" which I find disturbing and upsetting.
|
| /s
| jayd16 wrote:
| You can do all that in a markdown page just fine, no? Can't you
| throw a tracking pixel in markdown?
| hinkley wrote:
| The cynic in me says you could do this even _easier_ in
| markdown because you 're post-processing all of the content.
| timdaub wrote:
| haha that's definitely a big component of it all.
|
| But the engaged clickable web is anyways dead. This post is a
| static HTML file hosted on IPFS with no back links to my
| carefully curated blog and media presence. No branding. It's
| because I've accepted that people's bullshit-radar is sensitive
| towards overly optimized engagement content. Rather I want my
| text to be read and those that care will anyways online-search
| me. It's not my idea btw. The web has reached peak
| clickability: https://tedgioia.substack.com/p/has-the-internet-
| reached-pea...
| rroot wrote:
| I wasn't going to read that but I did. I kind of agree, but
| it's "social media" that's dying not the internet.
|
| The social media has gone absolutely toxic in an frantic
| attempt to maximize revenue per user.
| emrah wrote:
| Markdown could potentially replace HTML as a more succinct markup
| language but it's not sufficient by itself because it has no way
| to represent styling and layout. You'd need to jam CSS into it
| somehow
| frankus wrote:
| One thing that's always been a source of a tension for me is how
| to handle navigating around a "web of documents".
|
| There are limits to what you can do with "in-band" links in the
| text before they get to be contrived, awkward, and non-
| discoverable.
|
| Users seem to have a revealed preference for on-page links to
| barely-related URLs and want those links to have some spatial
| consistency over time. So that means adding some "fluff"
| (nowadays presumably nested in a <navigation> tag) to every
| document.
|
| One past experiment with out-of-band navigation was framesets,
| but they had some significant issues (not least of which is that
| the URL pointed to a container rather than the contained
| document).
|
| Are there some other interesting experiments with out-of-band
| navigation? Or is adding some semantic tags to HTML as good as it
| gets?
| PainfullyNormal wrote:
| It's been 10 years since Zed Shaw suggested a <markdown/> tag.
|
| clean speech warning: swearing.
| https://youtu.be/_CEBG_s92P8?t=398
| cto_official wrote:
| I think the problem is correct, but the solution of markdown is
| not.
| caseyf wrote:
| er if we are talking about creating documents without CSS and JS,
| HTML is way better than Markdown
| kderbyma wrote:
| My personal website is done similarly. I built it on top of
| markdown and added my own shortcodes so I could add macros and
| custom plugins as I added.
|
| The site code lives separate from the post, media, and general
| 'content' and doesn't care what content is provided.
| [deleted]
| sxp wrote:
| Part of the benefit of Markdown is that you can view the raw
| source and still get useful info out of it. But this site
| prerendered the Markdown and served HTML which defeats part of
| the purpose.
|
| A better option would be to use something like https://casual-
| effects.com/markdeep/ and serve the MD/HTML file. Then you can
| get a client-rendered HTML (https://casual-
| effects.com/markdeep/features.md.html) or view the raw MD
| (https://casual-effects.com/markdeep/features.md.html?noforma...)
| if the browser doesn't support HTML.
|
| Markdeep is good at progressively mixing HTML & MD so you can
| choose how much of each to put in to your page. I use it for
| mostly MD + MathJax notes + some HTML/JS/SVG/Canvas/WebGL for
| when I want dynamic graphics in my notes.
| timdaub wrote:
| If you're interested in the history of why I wrote this article,
| then it originated from this Twitter thread:
| https://nitter.net/timdaub/status/1590731949433573377
| nelsondev wrote:
| I think addressing the concern around Markdown flavors would
| improve the argument.
| timdaub wrote:
| ok thanks I'll inform myself and think about this a bit more.
| I wasn't aware flavors would lead to controversy but it makes
| sense.
| samatman wrote:
| As a compromise, might I suggest: <markdown
| class="commonmark"> <![CDATA[ # It's Markdown!
| Sure _is_ ]]> </markdown>
| jmull wrote:
| This doesn't really make sense, for a couple reasons...
|
| There are many flavors of markdown. We'd need a standards body,
| compatibility suites, etc., and for all the browser vendors to
| adopt it.
|
| Meanwhile, markdown is designed to transform to HTML, which
| browsers already render. Adding a markdown-to-html plugin/step to
| your web server or publishing process is not exactly the most
| burdensome thing, relative to everything else it takes to
| develop, publish, and maintain a site. And it resolves the
| markdown flavors issue.
|
| The thing is, people could _choose_ to publish, simple
| uncomplicated sites now -- it would be cheap and easy, too. The
| HTML is barely more complicated than the equivalent markdown, and
| it would take a few lines of CSS to apply a basic style.
|
| The many sites that choose to be complicated, cluttered, and
| expensive will continue to be so, for the same reasons they are
| now. Markdown would just be another way to build simple sites,
| which they don't want.
| jrm4 wrote:
| I can't meaningfully distinguish any of these criticisms from
| some you could have made about HTML earlier. None of these are
| deal-killers.
| MajimasEyepatch wrote:
| The difference is 30 years of websites and tools being built
| on HTML. There's an opportunity cost to consider: is
| formatting simple websites in Markdown and rendering them
| natively that much more valuable than simply writing them in
| HTML or using a Markdown-to-HTML tool that it's worth the
| cost of creating standards, implementing them in browsers,
| etc. as opposed to putting those efforts elsewhere?
|
| If you were starting from scratch, maybe. But it seems like
| we've already reached a point where existing solutions for
| Markdown-to-HTML get you almost all of the value and none of
| the cost.
| jmull wrote:
| The difference is that HTML already exists and browsers
| support it.
|
| For browsers to _also_ support markdown, there should be some
| use case that isn't already well-supported.
| ajkjk wrote:
| > There are many flavors of markdown. We'd need a standards
| body, compatibility suites, etc., and for all the browser
| vendors to adopt it.
|
| Yes please. Perfect: to want something that can be done; to
| need something that can happen.
| Dylan16807 wrote:
| > There are many flavors of markdown. We'd need a standards
| body, compatibility suites, etc., and for all the browser
| vendors to adopt it.
|
| HTML has had the exact same problems.
|
| You can say "CommonMark spec" and it's solved, isn't it?
| funnymony wrote:
| Part of the reason for standards committees, is that just
| saying "this flavour" is not enough to convince everybody.
|
| Standard is not only specification, but also tacit agreement
| by many parties to use same standard.
|
| People that have skin in the game usually want a say on what
| flavour should it be.
| ElevenLathe wrote:
| I get this, but OTOH it is IMO best to distribute digital
| artifacts in the format that is most useful for editing or
| creating derivative works. This is the free software philosophy
| but also a societal good. Many of us learned HTML and web
| technologies by reading the source code of websites, and we've
| closed that door behind us with all of the build steps that
| turn our actual code into a computer-readable-only mess which
| we send out for consumption by normal users' browsers. It would
| be nice if "view source" showed you something like what the
| author actually wrote in their text editor.
| krono wrote:
| Sourcemaps for HTML essentially.
| madeofpalk wrote:
| you can distribute websites as markdown! Return markdown with
| a plain text content type and it'll show as markdown, which
| was designed to look good as-is and not require rendering to
| HTML
| cxr wrote:
| Markdown is supposed to (be able to) look good as-is. Most
| people's Markdown doesn't look good as-is, though. They
| target the GitHub renderer and come from the GitHub-
| listing-as-a-product-landing-page school of thought, so
| even project READMEs are generally a mess.
| madeofpalk wrote:
| Presumably if you want to "distribute digital artifacts
| in the format that is most useful for editing or creating
| derivative works", like parent said, you would make it
| look good.
| cxr wrote:
| This isn't an unknowable hypothetical. No need to presume
| anything. Markdown found in the wild is a mess. The
| GitHub Flavored Markdown renderer even encourages it.
| Dylan16807 wrote:
| That means you distribute the best you have. It doesn't
| obligate you to use better methods.
| ElevenLathe wrote:
| Exactly this. I was paraphrasing the definition of source
| code from the GPL: "The source code for a work means the
| preferred form of the work for making modifications to
| it."
| jmull wrote:
| This is a really good point. (I should have/wish I had
| brought it up in my original post!
| saurik wrote:
| This is actually horrible for society as it implies that the
| Web Browser will have to implement a billion different
| parsers for all of the separate file formats it supports,
| which not only causes it to have a ridiculously large attack
| surface but pretty much implies there will only be a couple
| serious separate implementations (if even that soon...) as it
| is just too difficult for even a large company now to build a
| browser.
|
| Meanwhile, it doesn't even ensure the property of being able
| to view source, as people can and do obfuscate things they
| don't want you to see, and if people want you to see the
| source code there is nothing preventing them from making that
| entirely pipeline visible, including, but certainly not
| limited to, shipping a trivial markdown parser to the browser
| instead of doing the conversion on a server.
|
| In a perfect world, the browser should have simply provided
| something like canvas hooked up to something like
| WebAssembly, and we should have provided for everyone a
| trivial markup file format rendered that people could include
| by default and a handful of graphic file format
| implementations that could be easily mix-and-matched to pull
| just the ones people wanted into their site.
| gambler wrote:
| _> Many of us learned HTML and web technologies by reading
| the source code of websites_
|
| HTML is an extensible language. Markdown is not.
| divan wrote:
| > markdown is designed to transform to HTML
|
| Is it though?
| minhmeoke wrote:
| For people considering adding Markdown support to web browsers
| or other publishing tools, please consider adopting Djot
| instead: https://github.com/jgm/djot
|
| It's very similar to the Markdown syntax we all know and
| love/hate, but fixes many inconsistencies in the spec, and also
| makes it possible to parse a document in linear time, with no
| backtracking. It is also much fuller-featured than commonmark,
| with support for definition lists, footnotes, tables, several
| new kinds of inline formatting (insert, delete, highlight,
| superscript, subscript), math, smart punctuation, attributes
| that can be applied to any element, and generic containers for
| block-level, inline-level, and raw content.
|
| Some examples, showing how Djot would be rendered into HTML:
| https://htmlpreview.github.io/?https://github.com/jgm/djot/b...
| Arainach wrote:
| The primary goal and appeal of Markdown is that it is easy to
| _write_. Optimizing for parsing is creating a fundamentally
| different product.
|
| Standardization of the spec is good. Requiring quirky
| behavior and blank lines that hurt reading is bad.
| znpy wrote:
| I came to write something similar to this, basically.
|
| If anything we should push for websites to divide content from
| presentation: if html tags were used properly there would be no
| need for markdown.
|
| And on that matter, pushing for proper use of html tags in
| documents is a more achievable goal than asking everybody to
| just drop html and write markdown.
| coldtea wrote:
| > _There are many flavors of markdown. We 'd need a standards
| body, compatibility suites, etc., and for all the browser
| vendors to adopt it._
|
| Well, if it were to be adopted by vendors, the many flavors
| would be a non-problem. They can just agree on a flavor and be
| down with it. There's CommonMark anyway, they can just use
| that.
| seized wrote:
| Except that CommonMark has its own very annoying things. Like
| loose lists. Multiple lists of bullet points ends up an ugly
| mess with CommonMark.
| Beltalowda wrote:
| "I don't like this standard" is not the same as "there is
| no standard".
| v3ss0n wrote:
| Can you give me an example?
| 6502nerdface wrote:
| Interestingly, your comment is very similar to the Gemini FAQ
| "2.9 Why didn't you just use Markdown instead of defining
| text/gemini?" [1]
|
| [1] https://gemini.circumlunar.space/docs/faq.gmi
| merb wrote:
| https://xkcd.com/927/
| harryvederci wrote:
| This xkcd is always posted when anything related to a
| standard is mentioned, but almost never in response to a
| standard that was actually created to unify all standards
| in its space.
| timdaub wrote:
| https://timdaub.github.io/2022/08/28/six-unpopular-
| opinions-...
| anthk wrote:
| Gemini it's the needed standard between Gopher, tied to
| small devices with a 80 column display, and the Web with
| enforced encyption for security but without requiring lots
| of resources.
| timdaub wrote:
| Alphabet is a 1T USD market cap, I'm confident they could
| finance implementing 3-5 flavors.
| jmull wrote:
| I don't think money is the problem.
|
| It's the extra complexity to move markdown rendering from the
| control/responsibility of the server side, where it fits
| naturally, to the user-agent side, where it doesn't -- and
| for something that site publisher can already do (and
| evidently, rarely want to do).
| nine_k wrote:
| Markdown-based web is actually easy to try.
|
| There is a number of browser extensions that render Markdown
| nicely. Install one, and get your friends do the same.
|
| Make your web server serve markdown files with a Content-Type:
| text/markdown or even text/plain header. Put some Markdown
| files there.
|
| Enjoy. It should just work.
| varispeed wrote:
| Can someone explain what is the point of ipfs? I visited the
| homepage and it mostly shows an information about what it is not
| and disadvantages of things that are not ipfs.
|
| But I am struggling to understand why would I want to use it and
| how?
|
| For instance, can I host a website on it? Can I put a wordpress
| on it? How can I share my website with someone? Can I use my own
| domain? Or is it like FTP? I really don't get it and feels like I
| am missing out.
| cryptos wrote:
| While I consider it a bit unrealistic to follow this approach in
| a big style, I like the idea. However, I would suggest to use
| asciidoc instead, since markdown is a bit to constrained. For
| examples image captions or tables are not possible in markdown.
| uses wrote:
| HTML / CSS ended up being extremely granular and hackable while
| missing the big building blocks that would have readily matched
| the structure of the web - things like navigation menus or page
| outlines. We waited over a decade for the layout systems to catch
| up to developer needs while creating buggy float-based grids.
| It's an outlier that media queries were already in widespread
| availability when mobile really started picking up.
| synergy20 wrote:
| Or browser just renders markdown directly.
| Animats wrote:
| We could just go back to HTML 1.0, which is roughly equivalent to
| Markdown.
| Animats wrote:
| The amusing thing is, that's what his Markdown translator is
| doing. Look at the page source. There's a fixed CSS preamble,
| and then there's very basic HTML 1.0: <body>
| <h1>Why We Should Have Markdown Rendered Websites</h1>
| <p>You're viewing this document in your HTML-rendering browser
| but its source is actually a markdown file.
| </p> ... <pre><code>// file: http://home.md
| [home](http://home.md) [about](http://about.md)
| this my homepage // file: http://about.md
| [home](http://home.md) [about](http://about.md)
| this my about page </code></pre> ...
| <p>Best, Tim Daubenschutz <a
| href="mailto:tim@daubenschuetz.de">tim@daubenschuetz.de</a></p>
| <h2>References</h2> <ul> <li>1: https://gis
| t.github.com/JoeyBurzynski/617fb6201335779f8424ad9528b72c41</li
| > </ul> </body>
|
| That's it. That's his HTML. You could write that by hand.
| [deleted]
| ilaksh wrote:
| Reminds me of some related ideas I had:
| https://github.com/runvnc/tersenet
___________________________________________________________________
(page generated 2022-11-10 23:01 UTC)