hey Chris :) I'll email you!
3,377 karma · joined March 7, 2007
Web: https://brianbeck.com/
Mastodon: https://hachyderm.io/@exogen
I also don't just mean outages like this... it's clear that Microsoft GitHub has been cramming a bunch of new stuff into the UI and not really treating it with care. I notice very amateur UI bugs, misalignment, bad spacing, overlapping elements, etc. all the time now. It was clear that old GitHub passed through a professional designer's eye quite carefully (or maybe just a developer with extreme attention to detail).
Years ago I was hosting a movie night and we were watching a dark, stylish black & white film that required subtitles. This was either in iTunes or TV.app, whichever was Apple's flagship movie watching app at the time. Every time a subtitle appeared on the screen, the gamma (or something affecting brightness) would change ever so slightly, affecting the whole scene in a barely perceptible way. It drove me nuts. This wasn't some kind of adaptive dimming from the screen; I confirmed that the actual image (even when watching just on the laptop screen) was changing.
After some searching, a really wacky solution popped up: if you go into the Accessibility settings and bump up the size of the cursor ever so slightly, it'll fix it.
Supposedly, the reason was that macOS's cursor drawing is heavily optimized (potentially in the firmware?) and thus uses a different drawing path (maybe with GPU acceleration vs. without?) depending on whether the default cursor is being used or not. So, whatever drawing routine was used to render subtitles causing the gamma to shift was also triggered by having a different default cursor, making it the same whether or not subtitles were on the screen.
Even though I found a fix, to this today I'm still furious that Apple – supposedly known for their quality, attention to detail, and good multimedia experience – could overlook this in their flagship app. And now it's something I always do when setting up a new Mac: bump the cursor size.
But no. One day I realized it's just that my toilet always started from a flushed state... like a normal person. But they knew somewhere out there, someone would try to clean their toilet still full of piss and shit.
A subtle feature of OS X since its early days (but possibly not anymore) is that if you had something like a window title or a filename in Finder's column view, and you made the window or column smaller, before cutting off the text, OS X would shrink the letter spacing (and possibly other metrics) by a barely perceptible amount, so that the text could still fit. I always thought that was brilliant.
One day I was working on a very design-forward web project and wanted the same thing. Occasionally, text would wrap when it really only needed a few pixels of wiggle room to stay on one line. Thus, react-typesetting and a <TightenText> component were born: https://exogen.github.io/react-typesetting/
Eventually I realized it would be neat to make work with variable fonts (and their arbitrary axes) as well. Check out this demo: https://react-typesetting-alpha.surge.sh
I haven't touched or thought about this in a while, but I still think there's an interesting blog post to be made there about how it's done!
An interesting fact I learned about professional typesetting (and justification) is that, in order to justify lines, books don't just shrink the letter and word spacing: they also squish the characters themselves (in CSS this can be done with a scaleX transform). I guess my eyes have actually noticed this when reading books before, but I found it surprising because I always thought of the letterforms themselves as sacrosanct, and any distortion would be unacceptable. But it turns out, in almost every book you've ever read, 2–3% squishiness is perfectly acceptable.
By example, a request comes into my app's web server at `/posts/123`: how would htmx be involved at all in (1) understanding the request, and (2) generating the response? Remix isn't just client-side, it's also a server with routing and SSR.
Many of my friends still refuse to do it, but I'm not sure if that's still well-founded. My thought process is: well, the lawyers let 'em explicitly print "safe" on there... so they must be pretty damn sure.
If you mean how they work, like command line arguments and such (and not just speed), that's because macOS is based on BSD and thus using the BSD and not GNU versions. That's not really a "not right" thing, it's just different, and would be the same if you used any other BSD like OpenBSD, FreeBSD, etc.
I rode my bike across the country and my favorite city for cycling is still Cleveland. Not a whole lot of bike lanes, but wide enough roads and flat terrain. And the only time I was ever struck by a vehicle was when I was riding in a bike lane (because they were trying to turn right).
But, in nearly all cases I would trust a bespoke Wikipedia scraper over using the output of Wikidata or DBpedia. Not to disparage either project, because they're great ideas and good efforts. I have a firm grasp of RDF and SPARQL queries (used to work with them professionally), which also makes them tempting to use.
One issue is that Wikidata tends to only report facts whose subjects or objects themselves have articles (and thus Wikidata entities).
For example, compare the "Track listing" section of Carly Rae Jepsen's Curiosity EP on Wikipedia vs. the "track listing" property on Wikidata.
Wikipedia has:
1. Call Me Maybe (link)
2. Curiosity (link)
3. Picture
4. Talk to Me
5. Just a Step Away
6. Both Sides Now (link)
1. Call Me Maybe
2. Curiosity
> Others asked about the data quality of Wikidata, and complained about the huge amount of bad data, duplicates, and the bad ontology in Wikidata (as if Wikipedia wouldn’t have these problems. I mean how do you figure out what a Wikipedia article is about? How do you get a list of all bridges or events from Wikipedia?)
Often the problem isn't that Wikipedia is wrong, it's that Wikidata's own parser (however it works) doesn't account for the many ways people format things on Wikipedia. With a bespoke parser, you can improve it over time as you encounter edge cases. With Wikidata, you can't really fix anything... the data is already extracted (right or wrong) and all the original context lost.
However, the div button is still wrong because it shows the text selection cursor in the button.
As an example, if your goal is for the button to appear over the right-side inner box ("hero content") here:
+-------------------------------------------+
|+----------+ +---------------------------+|
|| nav | | hero ||
|| | | (x) ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|+----------+ +---------------------------+|
+-------------------------------------------+
Otherwise, if you just let the outer container be the offset parent because it happens to place the button in the same spot in the moment, then later when more content gets added to that container, you'll end up with this:
+-------------------------------------------+
|+----------+ +---------------------------+|
|| nav | | header ||
|| | +----------------------(x)--+|
|| | +---------------------------+|
|| | | hero ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|+----------+ +---------------------------+|
+-------------------------------------------+
The reason the animation appears to work in the example you link to doesn't actually have anything to do with the form elements or semantics – rather, it's cheating by animating the `max-height` of the tab content from `0` to `100vh`.
This can be done just as easily without all the form stuff, but it's a bad solution to the accordion animation problem, because (1) it assumes that accordion content will never exceed the height of the viewport (what about on phones in landscape mode? you're only talking a few hundred pixels there), and (2) CSS will ease between the actual minimum and maximum values without regard for where the element's true height actually stops changing, i.e. it will animate from 0 to 100vh in the duration requested even if the height only ended up being like 20px and thus visually stops changing 5% of the way into the transition – so whatever duration and easing you specified isn't actually being rendered in the way that you wanted. If you specified an `ease-out` for example (starts fast, slows down at the end), you'd just get a super fast linear-looking transition that ends much quicker than you planned and never has the slow easing at the end (because CSS is actually still transitioning the `max-height` property which is no longer having any effect on your element that's much shorter than the max-height).
You a moment ago:
> half the stuff things like React are used to do could be accomplished much better with a small amount of CSS
you now:
> yeah, you can't do it in pure CSS because you can't do most things in pure CSS
As an example, one of the most basic components I can think of is an accordion. You simply can't make one that works in a visually pleasing way (the way most people would expect!) in CSS because you can't animate to or from `height: auto`. The best you can do is some cop-out technique of fading out or squishing the content with `transform` and then having the content that follows it do an immediate jump up/down.
Instead, animating an accordion that actually animates the layout around it smoothly absolutely does require JavaScript, to tell CSS what non-auto values it needs to animate to and from.
And that's just the most basic component I can think of!
Another example: anchoring one element to another, when those elements don't have a parent-child relationship. Think tooltips. This requires JavaScript to measure the anchor element's position on every goddamn frame and keep the other one in sync, when the layout engine already has all the necessary information and could easily be built into CSS.
Developers (especially junior) think that if it looks right, that it is right, and they're done. But CSS is not just specifying how something looks, you are also very much specifying visual behavior, not just appearance. Content is dynamic, layouts change at different breakpoints, new elements come and go, another dev comes in and adds something later... you need to account for all of these things.
For example, a developer rotated an element using CSS transform because the library we were using only supported a horizontal layout and not a vertical one. Sure, everything looked right in isolation, but now this element doesn't play nicely with others, because transform only affects the visual position, not the offset position of the element, so all its siblings still think it's horizontal, and they're getting all jumbled together.
Or, using absolute position to, say, anchor a close button to the top right of an element. Sure, the way you did it happened to put it visually in the right spot, but it's not actually in the right spot according to the layout engine because its offset parent is not the element you're trying to anchor it to, so if other content gets put in there eventually, it will be in the wrong spot.
Or, they'll use `line-height` to add space around some copy, without thinking about how that text will now look when wrapped.
So in my opinion, any CSS tutorial worth a damn needs to hammer home that (1) just because it looks right doesn't mean it is right, (2) you can't really ever style an element in isolation, you need to think about how it interacts with its parent and sibling elements, and (3) elements actually have two different positions, one that you see, and a potentially different one for layout.
Knowing those things is key to understanding whether you've designed things "correctly" vs. something that just happens to look right in the moment.
(I've only skimmed this course so far, so I'm not sure whether it satisfies what I want. But I'm hopeful!)
One huge benefit of Jest though is the built-in mocking, including module mocking. This stuff is BYO in AVA. Module mocks in particular can be quite annoying to set up, so it's really nice that Jest pulls them all together in one cohesive package.