Finally, the web has a way of authoring and publishing documents.

What's wrong with converting markdown to html on the server side and caching that html? Why is so much stuff done on the front end these days? Makes my browser slow.

Because we're currently in the "do it all on the client side" phase of the eternal "do it on the front end" <-> "do it on the back end" ouroboros.

Or people want to edit MD in the browser?

Just gonna say it as I always do; I love web components.

I'm curious how this would work with SSR. I noticed that nothing appears in the spaces where these elements are used when I have NoScript blocking scripts on the page. Obviously this would prevent execution of web components, but are these written in such a way that it would be practical to prerender the content and the client-side code to replace or rehydrate them?

Web Components need JS - which makes them a no-go for many use-cases. There should have been a way to permit plain web-components with just CSS+HTML and no JS

> I'm curious how this would work with SSR.

Web Components can't be SSR'ed. (The libs that claim to do so, cheat).

This just looks like applying the boy scouts rule to me. She had a reason to update an old library to modern standards, and she did it. That's great! Let's get rid of that tech debt.

The source of the documentation site is a good example of it being used:

view-source:https://md-block.verou.me/

Nice and clean.

That being said I've never used web components and haven't really planned on. Not sure what their status has been in terms of adoption.

> Not sure what their status has been in terms of adoption.

Chrome teams and WC proponents will have you believe the adoption is huge, in the tens of percents of webviews. Of which most are Google's Youtube...

There have also been high profile adoptions at GitHub and Salesforce.

Beyond that, they have an issue list as long as my hand (and busy adding new issues), and can't really be used without a library/framework. So...

I wouldn't call flash-of-uncompiled-markup nice and clean. Please pre-render your markup.

While I think you can compile your markdown in most cases, this is a two line fix: set the style to display: none and remove it after compiling.

I suppose some sort of element that supports various LMLs (Lightweight Markup Languages) could be useful. I don't think Markdown is all that great - there's still room for improvement.

Sounds like lots of self-imposed yak shaving. I really hate the kind that requires deep dives into discovering just the right combination of Linux distro version, std lib versions, python versions, node versions … just to see if the demo of this tool provides the functionality I need…

What about MDX? https://mdxjs.com/

It's fairly well adopted in many tools

That's pretty neat! :D

Though I'm not sure exactly why you're comparing it to a custom element that renders Markdown.

Mixing older and newer slang in the context of a nasty process at the office, I derived:

"Shave enough yak to yeet a yurt".

I don't see how that works because while you may construct parts of a yurt out of yak hair, you wouldn't throw a yurt using yak hair, although maybe you could with the help of the yaks.

If you shave sufficiently many yaks you will eventually come across a yak that is ill tempered. Place the yurt behind the angry yak and watch the yurt get yeeted when the yak kicks with its hind legs.

Snappy yaks yeet yurts yonder.

Obviously, one would felt[1] the yak hair into a yurt-shape prior to launch.

It's either a nice alliterative run, or pedantic completeness, boss.

[1] https://en.wikipedia.org/wiki/Felt

This looks like a great little project, but fails the/my litmus test for use in a professional setting as it has zero tests. What protects this tiny component from regressions? `demo.js` doesn't seem to be sufficient.

Oh dear. Markdown has no standard grammar or standard way of rendering.

This website lags while I scroll on mobile.

I remember when the internet used to be fast and responsive. Probably just getting old.

Every time the user scrolls, this site updates a style attribute on the root <html> element with this a CSS variable: --scrolltop:700 (that appears to be first updating to the actual scrollTop value, THEN re-updating the value rounded to 100 increments). So TWO updates to this variable every scroll event.

There's a media query consuming this variable, and doing a calculation:

--logo-y: calc(3em - var(--scrolltop, 0) * 1px);

So every time the user scrolls, TWO variable updates take place, TWO redraws, and TWO of these calculations take place, TWO more redraws, just to center the sunburst background on the logo.

Doesn't even work right on Firefox mobile. The sunburst just stays in the same spot for me ¯\_(ツ)_/¯. What a waste of cycles.

I remember when 60 seconds was the target time to finish loading a web page with images over a 14.4.

I remember scrolling on an unaccelerated SVGA card and watching the screen repaint.

I remember being impressed at how gopher would only redraw the parts of the screen that changed, making browsing gopherspace bearable at 1200bps.

I remember queuing downloads of shareware games over zmodem and waiting an hour or more to find out whether they would even run on my hardware, and having to go do something else while I wait because my OS couldn't do multitasking and even if it could it would drop bits because the 8250 UART didn't have a buffer.

But end of the nineties and early to mid 2000s with broadband was peak speed!

Website lags scrolling on my desktop too. How do website even manage to break scrolling..?

By being accidentally quadratic or, more likely, naively.

Seems a bit odd to kick down like that - I'd be more inclined to assume it's accidental rather than naive, given the experience level of the author.

They accidentally didn't notice that scrolling is broken enough to bring a supercomputer to its knees?

...it doesn't bring my laptop to its knees, so no, I would wager accidental.

Sometimes I don't even want to know. I once found a website which messed with the scrolling to make it "smoother" - but it did that only when I scrolled with the keyboard (using a Vim plugin). I have no idea how they managed to do that, but at least it got fixed a couple months later.

Centering the background....

> I remember when the internet used to be fast and responsive. Probably just getting old.

This has got to be the most hackneyed comment on HN, and has been for the 10 years I’ve been on here.

Note that hackneyed doesn't mean wrong: just means trite.

It's better to be right than stylish...

It makes HN really dull if every single thread has someone moaning about how the internet used to be soooooo much better.

But, I mean, it's true. The internet would be a better place if it consisted only of POST/GET and static html/css. Javascript made the web shit.

there is the commonmark specification https://spec.commonmark.org/0.30/

I work a lot with common mark and hoedown for work. There's no formal Grammer for parsing markdown unfortunately. The closest thing to what the parent comment is talking about is pandoc which most people are afraid of because Haskell is scary and the markdown format they use is strange.

Also all of the parsers for md are very complicated.

Jupyter-book depends upon MyST-NB (MyST Notebooks) which depends upon myst-parser which depends upon markdown-it-py (which is a port of markdown-it (TypeScript)) for parsing [MyST] Markdown.

https://github.com/executablebooks/myst-parser :

> MyST is a rich and extensible flavor of Markdown meant for technical documentation and publishing.

> MyST is a flavor of markdown that is designed for simplicity, flexibility, and extensibility. This repository serves as the reference implementation of MyST Markdown, as well as a collection of tools to support working with MyST in Python and Sphinx. It contains an extended CommonMark-compliant parser using markdown-it-py, as well as a Sphinx extension that allows you to write MyST Markdown in Sphinx.

https://github.com/executablebooks/markdown-it-py :

> Follows the CommonMark spec for baseline parsing; Configurable syntax: you can add new rules and even replace existing ones; Pluggable: Adds syntax extensions to extend the parser (see the plugin list), High speed (see our benchmarking tests) ; Safe by default

https://github.com/markdown-it/markdown-it :

> Follows the CommonMark spec + adds syntax extensions & sugar (URL autolinking, typographer), Configurable syntax!; You can add new rules and even replace existing ones; High speed; Safe by default; Community-written plugins and other packages on npm

Hmm, have you tried pulldown-cmark. It's not easy-perse but it's readable and has an awesome interface. Though it's rust so the interface usability might differ for other languages.

Github: https://github.com/raphlinus/pulldown-cmark

I haven't played with too much Rust but any new projects address a lot of the difficulties with dealing with the legacy libraries. Mainly: they're not written in C.

Not sure if it's just me but with Firefox mobile nightly, sometimes when scrolling it instead randomly zooms in a bit.

Wow, I have a bad habit of reading the comments before reading the site, but you aren't kidding. My gaming PC is lagging on this site! It also doesn't help that reader mode (at least for Edge) doesn't seem to work for the site.

>This website lags while I scroll on mobile. I remember when the internet used to be fast and responsive.

Do you remember it being that on mobile?

Because I remember when it used to be a tiny subset of HTML (remember WAP? or early "web" browsers for mobile?) that to add insult to injury still sucked donkeys' balls on mobile, being slow and unresponsive as hell.

Website scrolls just fine (quickly) on my iPhone. I do have ad blockers though.

It scrolls fine on Safari on iPhone without ad block.

It's possible that it's a combination of:

- it's known that iPhone and mobile Safari prioritize user interaction over display fidelity. So Safari prioritizes scrolling over rendering updates, and updates whatever's lagging at more infrequent intervals

- Safari implements CSS var updates differently (see https://news.ycombinator.com/item?id=29353136 on what's going on with the site)

Interestingly Chrome Mobile has issues with it while Firefox mobile does not.

Relevant xkcd: https://xkcd.com/927/

No it's not? It has the word 'standard' but it's a completely different situation.

How many dialects of markdown are there?

A few, but nobody's suggesting a new one.

So, you could say there are competing standards for Markdown, hmm? :)

The comic is about trying to replace competing standards with a new superstandard. It's not relevant.

You're basically pointing to the first panel and saying 'job done'. That's not enough to make it work.

This website renders horribly slow for me on my mobile ... maybe its a SVG in the header, and its fixed to the screen? its still horribly slow when not visible, though.

I thought the point of Markdown was having a style-agnostic markup language that can easily be converted to HTML...?

> be converted to HTML

That’s kinda what’s happening here, isn’t it? Document is shipped in markdown; Component renders it.

In a way I wish websites would ship raw Markdown without the ability to style much: Reader mode by default, that’s what the web should have been. But alas.

This is gemini/gemtext.

The problem is that until that's part of Chrome and offered by Wikipedia, it's niche at best. You know Google is not interested because they can't place flashy ads in it.

Nuts... I thought this was going to be a fun article about people that actually shave yaks and, a little bit about "a New HTML Element for Markdown". :-p