And this is the power of MDX (and some great focus from the author of course). I’m having a hard time trying to understand why some people seem to dislike MDX, it is the holy grail of web authoring imho.
I spent some time exploring how to improve the UX of code blocks on the web
51–60 of 68 posts
Re: I spent some time exploring how to improve the UX of code blocks on the web
#52And this is the power of MDX (and some great focus from the author of course). I’m having a hard time trying to understand why some people seem to dislike MDX, it is the holy grail of web authoring imho.
It's because "standard" Markdown and many other formats already support HTML. If these kind of components were vended as standard web components, they could work in existing Markdown files and workflows.
My team is also working on code sample editor and preview components, but as web components for this reason: https://polymerlabs.github.io/playground-elements/
Re: I spent some time exploring how to improve the UX of code blocks on the web
#53Excellent work, although the "hover me" doesn't do anything in Firefox 88 on Linux.
or on FF 88 on Mac
Re: I spent some time exploring how to improve the UX of code blocks on the web
#54I'm curious why you avoided using mdx-prism in favor of re-implementing much of it yourself. If only because I just used it in my own project and spent time patching a minor Firefox-specific bug, and now I have FOMO because I like your implementation here :) Were your features impossible without huge changes?
I do like that you use the `line=1-3` syntax for highlighting instead of mdx-prism's `lang{1-3}`. Do you have any appetite for upstreaming that change?
Re: I spent some time exploring how to improve the UX of code blocks on the web
#55TIL I like turquoise themes.
Re: I spent some time exploring how to improve the UX of code blocks on the web
#56For the highlighted code, you’ve made unhighlighted lines look more like comments than merely deemphasised lines. One alternative style that I’ve found effective in such situations is to reduce the opacity and partially desaturate: -.sx5jq50 .highlight-line[data-highlighted="false"], .sx5jq50 .highlight-line[data-highlighted="false"] * { - color: var(---fadedLines); -} +.sx5jq50 .highlight-line[data-highlighted="fals…
Agreed on highlighting with a different background color. Unfortunately, it can be difficult to find a background color that is different-enough from the usual background while maintaining a high enough contrast with the text sitting on top of it. This is especially true if your syntax highlighting color palette covers all the hues you could use.
So here's another protip: Make the highlight pop with a brighter left-border, so your background color doesn't have to pop so much on its own and you have more wiggle room to maintain contrast. Something like what mdx-prism has in their readme image [1], though I don't like the specific blue-on-blue colors. This blog article [2] has an example in the middle with nicer colors.
Re: I spent some time exploring how to improve the UX of code blocks on the web
#57Earlier quoted context omitted.
It might also be worth having those links opening in new tabs as an option. Right now, at least on iOS, following a link and then going back leaves you at the top of the original page again, not where you were up to before you clicked the link.
In general, it's better for sites to not take away from the user the choice of opening a link in a new tab or not. When I follow a link on my iPhone, when I use the Back button, the page is still scrolled to where it was before, which is my typical experience in mobile Safari.
In general, I agree. But if the link is a surprise because the styling isn't obvious and it might easily be tapped while trying to scroll content on a small touchscreen and it breaks normal back button behaviour, I disagree in this specific instance. All of those things were true in iOS Safari on my iPhone at the time I wrote that comment.
Re: I spent some time exploring how to improve the UX of code blocks on the web
#58It's looks great. I think for me biggest problem with code snippets is that I encounter them with mobile device. Lines are quite long, like who uses 80 character line limits these days, more like 160. This combined with reality that most websites don't allow mobile device to zoom out. I wish I could read full lines of code instead of trying to scroll back and forth.
I consider 80 a soft limit, and 128 (nice round number) a hard limit. I find that even 80 is seldom reached, since I tend to use sane identifier lengths and small indents. The longest lines in my code are usually comments.
Re: I spent some time exploring how to improve the UX of code blocks on the web
#59It's looks great. I think for me biggest problem with code snippets is that I encounter them with mobile device. Lines are quite long, like who uses 80 character line limits these days, more like 160. This combined with reality that most websites don't allow mobile device to zoom out. I wish I could read full lines of code instead of trying to scroll back and forth.
I have the same problem. I've taken to reformatting code that I post on my blog to fit in something like 60 columns, with a modified code style that takes less horizontal space (using clang-format & prettier to do the work for me).
Re: I spent some time exploring how to improve the UX of code blocks on the web
#60It's looks great. I think for me biggest problem with code snippets is that I encounter them with mobile device. Lines are quite long, like who uses 80 character line limits these days, more like 160. This combined with reality that most websites don't allow mobile device to zoom out. I wish I could read full lines of code instead of trying to scroll back and forth.
I use 80 character limits, and suggest corrections to that effect during code reviews. I feel it helps readability. Is it becoming a tend to have longer limits?
I loath having 80 char limits. Nothing worse than you end up 3 characters over on a condition and need to try format it nicely across 2 lines. More often it’s less readable splitting it than just having it on 1 line.
If 80 char is a warning it’s ok. Because obviously if every line is super long that’s not readable either. Needs to be a balance.