Doug Parker 🕸️

Overly opinionated software developer on the Angular team at Google. Web development is hard, so I build tooling that makes it easier. I love forcing web tools to do things they were never supposed to do.

Blog: https://blog.dwac.dev/
GitHub: https://github.com/dgp1130/
Bluesky: https://bsky.app/profile/develwithoutacause.bsky.social

Last Notes

2025-07-26 00:45:32 UTC

- reply

It's not my fault commas are overused in the English language!

2024-11-03 19:27:02 UTC

- reply

`requestAnimationFrame` is tied to the refresh rate of the display (typically 16ms, but that does vary).
I'd suggest immediately reacting to a mouse event in your `addEventListener` callback (or scheduling a separate "physics" update with `setTimeout`) and then updating the DOM accordingly in your `requestAnimationFrame`.
Even `setTimeout` isn't super reliable timing, so make sure to measure the actual elapsed time rather than the requested timeout.

2024-10-15 20:10:33 UTC

- reply

I can maybe see CSS modules kind of gives a browser primitive for CSS in a way which aligns more with this model. Though it kind of requires #ShadowDOM for scoping to work in any reasonable fashion, and without a clear scoping story I don't think it's quite there yet.

2024-10-15 20:05:04 UTC

- reply

Of course frameworks could define "component" based on it's interaction or participation models (ex. a thing which can be rendered or adheres to a particular lifecycle).
My point is more that this vertical slicing of the three web languages is a critically important aspect of most frameworks' interpretation of components, and that's just not how web components work today.

2024-10-14 19:00:09 UTC

- reply

I don't think I have any problem with `::before` / `content` (provided the content is stylistic in nature like an emoji or arrow character).
My concern is more with the fact that #CSS styles alter the way whitespace processing works in #HTML. It literally changes the core text content the browser displays in ways which affect the semantic meaning of that content.

2024-08-28 14:13:06 UTC

- reply

I'm not entirely sure I understand the question here, but based on the.whitespace handling I discovered in https://techhub.social/@develwithoutacause/113038091169177536, I don't think it really works as a purely CSR feature given that ranges need to count whitespace which is not observable in the DOM.
I can see an argument to just SSR-ing `<span>` elements with the highlight style, though I think it's tricky to set that up for this use case, when a highlight might cross multiple elements at weird points. Consider highlighting "llo Wor" in:
```html
<div>Hello</div><div>World</div>
```
You can't trivially SSR that with an additional `<span>`. So you still need the highlight API anyways.
I'm not clear on the #a11y behavior though. Can screen readers observe highligt at all? Presumably highlighted text is pretty important to the meaning of it. I guess that might depend a bit on context.

2024-08-25 20:14:20 UTC

- reply

Personally, I attribute a lot of this to a lack of build systems. Web developers are used to a single CLI tool that "does all the things" (build, serve, test, scaffold, etc.). So moving away from one piece moves away from all of it.
If developers were comfortable using a build system to orchestrate these tools independently, you'd be able to much more easily pick and choose the tools which matter for you.
This would allow workflows like TypeScript -> bundler -> devserver / test runner without having to pull in an entire framework or buy into a plugin ecosystem where everything is coupled together.
Just pick the tool you want and stick it in your build system where you want to use it. No weird setups, plugins, or integrations.