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.
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
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.
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…
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.
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.
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.
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.
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.
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.
> 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.
> 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
> 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.
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.
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.
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
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.
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.
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
