Dropping a new web component today:
Unencumbered <line-numbers> will add line numbers alongside a `<pre>` or `<textarea>` (and updates when input value changes)
README: github.com/zachleat/lin...
Demo: zachleat.github.io/line-numbers...
Zach Leatherman 3737 replies 130130 likes3434 reposts Original on MastodonOriginal on BlueskyAlso posted to Mastodon.
37 replies
Sick!
Thanks! 🙌🏻
hey nice. I like how the element name definition is part of a static method. I forget, did you write anything up on that pattern yet?
thanks! the last thing I wrote about custom element definition was this one www.zachleat.com/web/nodefine/
nice! thanks friend
This is cool. I may just use this for something I am building
hey, thanks!! 🙌
decoupled this one right out of 11ty’s new demo/playground component: https://neighborhood.11ty.dev/@11ty/114519676689929120
Decoupled this one right out of @11ty.dev’s new demo/playground component: bsky.app/profile/11ty...
@zachleat FYI: I tested the demo on Safari for iOS and two things that look kinda weird:
1. The line numbers are kinda laggy (almost looks like they are on a different framerate).
2. It doesn't work well with the "overscroll" behavior.Here's a recording: https://i.imgur.com/BWASSxj.mp4
@loucyx thanks for testing! fair point about overscroll, I don’t think there is an `overscroll-behavior` value that makes sense for the component to add though — this seems more like an app-level option
@zachleat yup. That's why I pointed it out as "odd", mainly because I would expect the line numbers to always be aligned with the lines. Those two things makes it feel "disconnected", but I'm guessing that's because the component is non-intrusive, so it adds the line numbers "next to" the lines, not "into" the lines.
@loucyx yeah — tradeoffs!
Clicking on the demo I don't see it working! What happened? (Chrome on Android)
it’s working, the demo just clips when the behavior is unobtrusive. Sorry that isn’t more clear!
Got it. Carry on
I did push something to make it more obvious on small viewports! Has me thinking that maybe obtrusive should be the default, not sure
-
@zachleat I wondered if this was going to just * display inline and do a generated content "1" :)
@bkardell look, our line-based code coverage metrics have never been better!!
This is really cool and super easy to implement. Thanks! Perfect thing for when you want a textarea, not a contenteditable div
ooh — nice use case!
@zachleat This is timely because I've been looking into a challenge with a similar thing, the challenge being that screen readers can't/don't read the line numbers.
Using your demos:
https://www.dropbox.com/scl/fi/m0mo1daul01audkpssrly/Responses-to-questions.md?rlkey=3bbh9jiczxgndkp41lorm13lj&dl=0I *think your component may have the same challenge. Any ideas on how it might be solved?
Full disclosure, I've been stumped so far!
@tink yeah, you’re right — the numbers are aria-hidden. I could modify the component to have the line content embedded in the `<ul>` (but not visible) and hide the primary element from screen readers — that would be better for `<pre>` maybe but not textarea!
@zachleat That'd do nicely for the pre, you're right. I'm not even sure there is a solution for textareas though?
@tink if content duplication isn’t an issue, it could be solved the same way but it would have some live region complexity to it!
@zachleat I wondered about a live region but kept introducing issues as fast as removing them 🥴
If the line num is in the notification, the problem is timing and not having the notification and the s/reader speaking the line of code overspeak each other.
If the line num and the line of code is in the notification, then duplication is the problem like you mentioned.
...
@zachleat
AFAIK there's no way to temporarily stop the s/reader reading the line of code in the textarea when first navigated to (leaving the notification to do the job), and even if there was it'd likely make interacting with the textarea content after that too brittle to be viable.@tink just to brainstorm, I wonder if it would be better to have a pre->textarea toggle that requires an opt-in for editing. that way the Viewer mode would be a <pre> (easier problem) and editing could re-sync the `<pre>` content
@zachleat Can you explain that a bit more? Not sure I quite understand.
@tink well, there are two separate problems here right? One is a scenario in which the textarea is readonly-esque and you want to report the value with line numbers outside of editing. The other is reporting line numbers while a user is editing? I’m not even sure what the latter might look like? e.g. “Your cursor is on line 4, which has the following code:”?
@zachleat Yes, I think so. I'm guessing the readonly scenario is where the pre comes in? So could be fixed, perhaps, by unhiding the line numbers?
@zachleat The other scenario (when editing inside the textarea) is what the k'board shortcut to report the current line number *might be able to solve?
Lots of "ifs", "buts", and "maybes" in there though!
@zachleat Chatted about this with Craig and Joe (also from TetraLogical) and the idea of a shortcut that triggered a live region notification with the line number in came up.
No idea if the given line number could be determined in this case. The chosen shortcut would need to be exposed to s/reader users too, perhaps using aria-describedby on the textarea, and it'd need not to conflict with existing shortcuts (easier said than done), but it might just work... 🧐
Composition of web components. ✨
*excellent demo* yes!!
do one thing and do one thing well 🏆