chrismorgan

In 2004, when they were working on 0.40, it was on the roadmap for 0.49 <https://wiki.inkscape.org/wiki/index.php?title=Roadmap&oldid...>. Unfortunately it never happened, though they invite people interested in implementing it to join the development team <https://inkscape.org/learn/animation/>.

Printing is a good constraint against getting too long, both the physical and cost constraints. Though the Harry Potter series in full still managed to reach a million words.

For another comparison, the Bible is around three quarters of a million words, and tends to use special paper (20–40gsm/30–50 micron) so it works in one volume.

Handwriting is also a good idea for encouraging keeping lengths down; typing and dictation make verbosity too easy; and as for LLMs, words are clearly far too cheap there.

And the entire analogy is incoherent.

And how all six people links are to LinkedIn, when most of them have websites. (Wouldn’t surprise me if some of the LinkedIn profiles were incorrect, but since you can no longer view anything on LinkedIn without having an account…)

I see no connection whatsoever with the CSS Zen Garden dream. CSS Zen Garden was about applying radically different styles to the same markup. This is about newer CSS features like Custom Properties, Flex and Grid making maintenance of a single stylesheet for a single completely typical website.

Genuine question: why wouldn’t they have been doing this already? It feels like obvious low-hanging fruit on a critical path, so I presume there’s something more to it than I’m imagining.

Not much is actually UCS-2; almost all things like that are rather unvalidated UTF-16, also known as sequences of UTF-16 code units.

Approximately nothing that uses UTF-16 validates it (I can’t think of a single thing that does), so surrogates will work fine. At least until a UTF-8 system touches it, because they normally do validate (Go is an uncommon exception in not validating).

> Rust also has UB, btw

Not at all the same. C and C++ are full of hazards and I get the impression it’s genuinely difficult to avoid entirely in normal code bases, and typically impossible to avoid statically. Whereas in Rust it’s all gated behind the unsafe keyword, and if you don’t use it (and most code bases never need to use it), you cannot encounter UB; and that scoping makes it far easier to control and handle correctly.

Yeah, I was responding to the new micros post here rather than the earlier Lobsters list.

I’ve never used any of these tools. Please tell me that this is a grossly exaggerated parody, and that the tools don’t write like this, or do so many ridiculous things. For my sanity.

(I am genuinely uncertain, though I presume it’s at least somewhat exaggerated.)

When you brought these arguments up on Lobsters <https://lobste.rs/c/dsm1up> I said it wasn’t cut and dried but that my general feeling was of disagreeing with you. I’ve thought about it more since then, and firmed my position up: you should make sure that the presence of initial-scale=1 won’t affect anything (we agree on this point), but that if you make a mistake in this area, it’s much better to have it than not to (we disagree on this part). Of your five points:

Your first point is correct. It could be reasonable to omit initial-scale=1 during development, or have something that complains on width overflow.

Your second is unavoidable: omitting initial-scale introduces a worse failure (excessively small text).

Your third I disagree with: when overflow occurs it will almost always be obvious that you could scroll, because you’ll have text or image that runs to the inline-end edge of the viewport rather than being contained by a page margin as is universally practised.

Your fourth isn’t useful—by that argument all documents should be zoomed out until the entire thing fits on screen; but we don’t do that in general because having to manage the zoom to get a useful result is unpleasant, yet that’s what you’re advocating for.

Your fifth is irrelevant, I think entirely unrelated to initial-scale.

Which was premature because most people have missed that initial-scale doesn’t actually default to 1: https://github.com/mdn/content/issues/45570

I have seen people click on ads before—by accident, due to a terrible close button or UI shift.

> and had no reasonable belief it was possible

The broad concept has been well-known for half a century at least, and the very specific concept for several years at least. It’s clear that they didn’t take reasonable precautions against it. And it’s not even the first time this sort of thing has happened, though it’s higher-profile and -impact than before.

If it only took 59 minutes to process millions of records, it was nowhere near as bad as it could have been. At around one millisecond per record, it sounds like you probably don’t even have any accidental quadratic time complexity on the number of records! What are you complaining about?

Not particularly well-considered opinion I’ve mulled over for a few years: Git on macOS should ignore .DS_Store and ._* by default. Would this cause any problems?

> Despite spending hours a day looking at her phone, she literally had to check it to find out what her default color theme is; it’s that invisible to her. (Interestingly: she herself was surprised to find out she’s actually been looking at dark mode this whole time without even realizing it).

My wife’s phone has been in dark mode since before I married her, but most of the apps she cares about either don’t support dark mode (at least on her version of Android, older Samsung) or she has manually chosen light mode. The system preference and ability to swap it at night time or whatever is thus a bit of a mockery. (I mentioned it once, but didn’t change anything.)

My mother tells much the same from when we Australians were in Denver for five months in 1996 about walking a kilometre to school. Also mild astonishment at ideas like baking cakes not from a packet mix.

Mind you, there weren’t many who would walk to school like that in Australia, and the number has continued to dwindle. But there were some.

I want to hear you justify, with perfect gravity, “N/A.” being the exact same length as “None.” Pictures of handwriting or specific fonts accepted. :D

I think you’re misreading it: there are two parts to the question, “No.” answers the first part, and because of that the second part is “Not applicable.” They should have just written “No.”

I think the “not applicable” is to the elided second sentence of the question:

> 3.6. Have you communicated with any of the entities whose products or services might be affected by the introduction of your proposed service? [→ No.] If so, please describe the communications. [→ Not applicable.]

Gotta say that the entire form feels not applicable. The proposed service is the discontinuation of an existing service. I see from their website that other similar things do the same, but it feels broken when so many of the questions become nonsense.

A handful of comments on an otherwise fairly reasonable article.

> When we run into jank like this as developers, the usual reaction is to wonder “is my code slow?” and start picking apart algorithms or looking for wasted computation. In most cases, though, the speed of the code is not the problem. The code isn’t slow. It just happens to be the code that’s holding the main thread.

Eh, most of the time it is slow, because you chose to use React. React used naively scales very badly. You have to jump through lots of sometimes-fiery hoops to make React… not much slower than some of the alternatives. Memoisation (possibly now via React Compiler) and things like that.

> [Diagram with rAF, Style, Layout and Paint attributed to the main thread]

Paint hasn’t been on the main thread in Firefox since 2017: https://mozillagfx.wordpress.com/2017/12/05/off-main-thread-...

Not sure about other browsers. Firefox has generally been the leader in these areas.

> [steering cost demo]

The demo is deeply unsatisfying because the simulations are quite different in a very problematic way: in “all at once” mode, it loses most mouse movements, which radically affects the simulation which is attuned to movement events rather than simulating physics based on a constant tick rate. Without examining it closely, my guess is it’s using pointer events and the browser is coalescing the events because of the blockage and it’s only taking the final state rather than going through all of getCoalescedEvents(). In a simulation like that, if you can’t run it at full speed, you have to decide what to do, and you should do it deliberately, because it may be disastrously wrong. Should you fall over, simplify the simulation by dropping some of the calculations, reduce the tick rate, something else?

> The demo below is a markdown editor with a long CHANGELOG open. Building the preview means parsing the entire document (about 2,000 lines) and rebuilding its DOM from scratch, which is far too expensive to run on every keystroke.

No it doesn’t. This is a clear example of your code being slow, because you’re doing the wrong thing. You want an incremental parser of some kind. Markdown is tolerably well-suited to this kind of thing because for most edits you can just render the current paragraph.

The suggestion is bad. “Debounce 300ms” behaviour is obviously worse for small documents.

> DOM writes can be batched as well. Appending a hundred nodes in one operation instead of one at a time, or toggling a single class instead of changing style properties individually, turns many changes into one and helps performance. The old technique of assembling an HTML string and assigning it to innerHTML in one shot has the same essence. You gather the writes so the rendering pipeline’s fixed cost is paid once.

This is simplified far beyond accuracy. parent.append(one_hundred_nodes) and one_hundred_nodes.forEach(node => parent.appendChild(node)) are unlikely to perform particularly differently. Changing style properties individually isn’t that* much worse than toggling a single class (it amounts to rewriting the style attribute a bunch of times, and the CSS parser and serialiser aren’t particularly slow). Building an HTML string and assigning it to innerHTML is better than constructing children manually in some cases, worse in others. The real thing that matters is avoiding triggering layout unnecessarily by things like accessing clientWidth between changes.

> Deferring

The lazy rendering trick used here is very problematic because you still need to know how tall each item is. Plenty has been written about hazards of infinite scrolling, that’s what’s being dealt with here. Now if you can have each item be a fixed height, then progressive rendering has far fewer side-effects. I would also say that switching from Notifications back to Feed and having it take an extra few hundred milliseconds is really not that bad. And that I’m not convinced the approach taken was right anyway, you could often just leave the feed rendered and avoid affecting the gross layout.

—⁂—

On the presentation of the site itself: this makes no sense:

  .post-content ul {
    word-break: break-all;
  }

> /* UNCOMMENT BELOW to force a boring system font (might break some web icons) *

Firefox already includes a better version of this: Settings → Fonts → Advanced settings → untick Allow pages to choose their own fonts, instead of your selections above.

It makes the web much better. Firefox even includes a list of icon font names that will be permitted (pref browser.display.use_document_fonts.icon_font_allowlist) to minimise icon font breakage, though I chose to block font loading altogether and there’s not often much trouble from it (and most of it is Google’s, and Material Icons’ ligation technique is in practice so dumb, achieving results quite the opposite of the original reason for the technique in an entirely predictable way).

> I need colors for code

Quite honestly, try doing without it for a while and see how it goes. Make a new theme that’s limited to just black on white, with regular/bold/italic font styles (me, I did keywords bold and comments and macro stuff italic and that was all), and use it for a week. Then consider if you want colours, and how to add them. Me, I went to strings red and comments green and numbers blue and not much else, though it’s grown a little over time. Others add greys, and perhaps background shading.

Please reread.

No, it’s loading the font in JS for some reason (rather than a regular @font-face) and going out of its way to break the page if that fails, rather than ignoring it as it should. `font-family: dg` is fine, it’ll fall back to the user’s default font (which will typically be serif).

Fortunately it’s easy to collapse the tree. And the mods do often override trees like this to default to collapsed.

From the code, it looks like it’s only broken if you have a browser more than about two and a half years old, JavaScript disabled, or fonts disabled. Even on HN, I would expect that to be under 5% of viewers, surely under 10%, and people that turn off JS are used to the occasional page not working (though it’s happily less common than it was five years ago).

That message is triggered by checking for support of the CSS light-dark() function and :has() selector:

  window.CSS&&CSS.supports&&CSS.supports('color','light-dark(#000, #fff)')&&CSS.supports('selector(:has(a))')

Are you sure your browser is fully functional and updated? Chromium shipped the last part of that incantation two and a half years ago.

The only reason I commented this was because the specific breakage was novel. And it’s rare for this specific type of comment to rank highly. Apparently this one is unusually interesting to others, or something? Beats me.

It’s currently at +39. I did not expect that! I expected it to settle at the bottom like something that settles at the bottom—I dunno, detritus, lees, Titanic, something like that.

Still, I’ll take the opportunity to advocate for turning off fonts. Firefox: Settings → Fonts → Advanced settings → Allow pages to choose their own fonts, instead of your selections above. I’ve been using the web so for 6½ years and it makes it so much better.