sheept

It doesn't seem like a pleasant, bilateral collaboration since Russian developers do not seem pleased about the Euro-Office initiative.[0]

[0]: https://github.com/ONLYOFFICE#%EF%B8%8F-legal-note

It's interesting that it renders Chinese in a TUI. I wonder if that breaks anything that assumes a character is always a column wide.

Language support was probably an afterthought since their target audience all read Chinese

It feels quite choppy on mobile, but I think it could be fixed by adding touch-action: none

This is bad advice. You should only use rem for text, e.g. font sizes and paragraph margins.

If the user is on a phone and has a larger default font size due to vision difficulties, making padding scale with the font size takes screen real estate away from the larger text the user needs.

It's not that it's unreliable, it's just lazy research. Wikipedia, like all encyclopedias, is a tertiary source, but ideally your essay should be a mix of primary and secondary sources, while Wikipedia discourages original research and prefers only secondary sources. Wikipedia itself recommends against citing it as research[0] for this reason.

[0]: https://en.wikipedia.org/wiki/Wikipedia:Citing_Wikipedia

The changelog design has been like that since last year,[0] which predates today's slop design of small caps and monospace text (probably because they both are based on the same design trend). A year ago, vibe coded websites leaned more on sans serif and gradient text.

[0]: https://github.blog/changelog/2025-05-05-improvements-to-cha...

UTF-8 is not locale independent. You cannot correctly render multilingual UTF-8 text without also specifying its locale, and some transformations like uppercase/lowercase also depend on the locale.

If you're applying a replacer, then you'd supply a reviver when parsing:

    const json = '{ "a": 9007199254740993 }'
    JSON.parse(json, (_key, value, context) => /^\d+$/.test(context.source) ? BigInt(context.source) : value)

No you don't? The example I gave produces

    {"a":9007199254740993}

not

    {"a":"9007199254740993"}

You can serialize a BigInt by specifying a replacer:

    const obj = { a: 9007199254740993n }
    JSON.stringify(obj, (_key, value) => typeof value === 'bigint' ? JSON.rawJSON(value.toString()) : value)

This can be avoided by supplying a reviver:

    const json = '{ "a": 9007199254740993 }'
    JSON.parse(json, (_key, value, context) => /^\d+$/.test(context.source) ? BigInt(context.source) : value)

A parallax effect has also long been possible with CSS 3D transforms. Here's a demo,[0][1] from the same person who made that CSS 3D FPS a while ago.[2]

[0]: https://www.keithclark.co.uk/articles/pure-css-parallax-webs...

[1]: blog: https://www.keithclark.co.uk/articles/pure-css-parallax-webs...

[2]: https://www.keithclark.co.uk/labs/css-fps/

Floats are better for calculating lighting. I would think some GPUs are probably also more optimized for float processing than ints.

That sounds like a lot of work. If you rebase A on main then B on main, you end up having to resolve A's conflicts on main twice. But if you stick with merge commits, A's conflicts are handled once in the merge from main.

The list is pretty small, so I wonder if this just drives users to other, smaller platforms. That said, the list of platforms includes all the biggest offenders of engagement optimization, so it feels more like a ban of addictive social media than all social media in general. But it's also interesting they ban messaging apps, which I assume parents use to keep contact with their kids.

It'd be nice to see screenshots from real mobile browsers.

Currently, it is not possible to use viewport-fit=cover to show content under the status or address bars in iOS 26 Safari,[0] even though ironically Apple introduced it for the iPhone X.[1] viewport-fit=cover only has an effect when the site is added to the home screen, where like Android it determines whether the site can render under the home bar, but the status bar remains black.

[0]: Try this in iOS Safari: https://sheeptester.github.io/hello-world/test/100vh-cover.h... [1]: https://webkit.org/blog/7929/designing-websites-for-iphone-x...

Is this surprising? Websites have long been silently writing to disk, for cache, cookies, and blobs. OPFS just provides a file-system-like API for ultimately the same functionality

As the article notes, effects (at least as described in the article) are already possible in JavaScript using generators, as long as every calling function is a generator, which I assume the author finds problematic because generators are cumbersome.

I was wondering how well TypeScript can type generator-based effects. My hypothesis is that TypeScript can let you compose functions with effects, but it is not possible for it to narrow down that the result from an effect corresponds to the effect (i.e. the result of an effect will be any possible effect result used by the function).

My incomplete, untested attempt in TypeScript[0] tries to implement `enumerateFiles` and `withMyLoggingLibrary`. The type errors demonstrate TypeScript's limitation that it can't associate an effect call with its result.

[0]: https://www.typescriptlang.org/play/?#code/C4TwDgpgBAMg9gcwK...

probably intended to be a signature for the preface, since Christian is the repo owner's name, that turned into a list because of markdown syntax

Context? Without it, it would be like starting a new session for each follow-up prompt

I'm curious about that "magic doc" feature. Is that meant to go in CLAUDE.md or a project file? Does the file need to be mentioned during the session or does Claude automatically search for all mentions of the "magic doc" header in the project?

It's an option that individual channels can disable. Granted, it's opt-out, but YouTube emailed creators several times about it well before:

> Effective today, you can turn off automatic dubbing for your entire channel in your Channel settings > Upload defaults > Advanced settings > Automatic dubbing.

> Once auto-dubbing is enabled for your channel, while uploading a new video, you will also have the option to turn off automatic dubbing for that video.

So if you're seeing auto dubbing on a video by a creator who clearly pays attention to YouTube's algorithm and should be aware of the feature, then they deliberately opted to leave the option on, probably thinking that it can't hurt.

Why does it need plugins/skills for a code review? Claude will just "review it" if you ask it to, and if you have particular preferences, they can go in CLAUDE.md

WhatsApp is not universally used. Line, WeChat, and KakaoTalk are more common in East Asia

I think you got it backwards: JavaScript has the coloring problem while other languages don't.

"Red functions are more painful to call" alludes to async functions. Every await yields back to the event loop, which adds overhead. Making every function red/async adds a performance cost (and makes it harder to reason about race conditions), which is why JavaScript has a mix of blue and red functions.

Other languages can escape the "red functions can only be called by red functions" trap, like Python asyncio.run or Tokio block_on. JavaScript has no such alternative, not even in Node. Therefore, Python and Rust don't have function coloring, but JavaScript does.

Painfulness isn't the main issue with colored functions, it only explains why we don't make every function red (async).

The main issue is that sync functions can't call async functions, but in Python, you can bypass that restriction with asyncio.run.

#3 is not satisfied, as you noted in #2. You can call `throws` methods from non-`throws` methods by wrapping the call in a try catch, and `throws` methods can call non-`throws`. There isn't an exclusivity asymmetry like there is for JavaScript async.

The Photoshop comparison doesn't make sense. Co-Authored-By doesn't show up in the final product, just as we don't say an image was exported from Photoshop.

Would you consider the .psd and .indd file extensions to be advertising? It's important to know what program the file came from so you can open it again, because MS Paint and Photoshop produce different files. Similarly, it's important to know whether and which LLM was used, because while all IDEs find and replace the same, each LLM generates code differently from each other and from humans.

Find and replace behaves the same in most IDEs, but for large changes, the specific LLM can affect the generated code for the same prompt