Markdown card headings h1, h2, h3

just silently shipped markdown h1, h2,h3 support in cards (use with # text)

This uses the font (recoleta) from the about/help pages. Overall in a space with both h1s and h2s this adds 80kb which isn’t the best but no way around that with current technology, and I think it’s a net win (especially because it caches between reloads).

as always, let me know how it goes

1 Like

:heart_eyes::heart_eyes::heart_eyes: love this

2 Likes

This small addition is going to bring an explosion of expression. This typeface is much more readable, and I will def be using that when dealing with longer prose passages. Look how beautiful this is:

image

I can’t wait to see how others use these headers…people have been asking for a while :wink:

I found two classes of bugs. The first is that tags are not in the font, nor any characters after the tag:

image

I would love for tags in headers to also use recoleta. Especially if you have a tag between other text, I’d think you’d have to, unless you didn’t allow tags at all :frowning:

Secondly, no other formatting works in headers:

According to gruber’s dingus and the GitHub one I found, the formatting “should” be there. For example

# Hello [world](kinopio.club) should become <h1>Hello <a href="kinopio.club">world</a></h1>.

et cetera.

cheers!

2 Likes

The kinopio markdown parser is custom , it’s much faster but also isn’t deeply recursive. So not supporting code blocks in an h1 is just gonna have to be a known limitation for now.

Will think about h1 in tags but the special sizing complicates a lot

1 Like

Re h1 after a tag. The ‘#’ for the h1 has to be the first character in the line

1 Like

That’s not exactly what I was saying. I meant, if you have a tag in a header line, all the text after the tag is not styled properly.

# h1 [[line]] no longer h1

Setting aside tag rendering, I would expect “h1” and “no longer h1” to all be recoleta. but it’s not:

image

It’s not just code blocks, but any kind of formatting (bold, italics, links, strikethrough). But I understand the limitation, and I’m okay with it.

Maybe for now, tags shouldn’t be activated in headers at all so that the formatting is not weird. In other words:

image

instead of

image

Until you decide to do otherwise?

1 Like

I get the logic but I think typing [[ in some contexts not generating tags would be net confusing. Irl I wonder how many ppl want to put tags in the middle of a header. Certainly it’s not something I’ve seen ppl often do on other platforms w md

1 Like

Yeah, it’s not common on other platforms, and maybe not here either. Although since tags are one way you can emphasize text, I think it might be slightly more common.

The main thing I wanted to avoid is this:

image

which looks really bad. Maybe people will see that and then remove the tag so it’s not something to prevent?

1 Like

Firstly, I love it! As you may remember, I love the usage of this font on the help page.

Secondly, I have a beef with Azure DevOps wiki editor because when you embed inline code in a heading, it does this (makes the inline code tiny compared to the heading):

So I tested the similar thing in Kinopio and you got away with it by ignoring backticks in headings:

image

And I’m happy with this! :blush:

I think, all respect to Ben, tags in headings are probably more niche?

2 Likes

I think so too

1 Like

https://twitter.com/w3c/status/1438130233002106885

maybe when this gets implemented.

Agreed. Still would it be possible to not allow this?

image

And instead,

image

2 Likes

Ideally , but I think the work to benefit ratio doesn’t justify it at this pt (it’s a surprising amt of work based on how the parser works )

2 Likes