I mean the court is ordering them to retain user conversations at least until resolution of the court case (in case there is copyrighted responses being generated?).

So user privacy is definitely implicated.

What do you mean by semantic tokens?

This exact type of functionality has caused a major project a work on to use CSS in JS (for relative colors and contrast colors.

I’m glad to see this type of thing coming around the corner and look forward to it being widely available in a couple years.

With regards to color on the web, semantic tokens refer to css variables that are named in a way that describes their use, ie:

* bg-brand (this would be used whenever you need your brand color as a background)

* text-danger (likely a red text color)

* icon-warning-hover (likely a dark yellow-orange that's slightly different from icon-warning)

Generally speaking, there are three "levels" of tokens: primitive, semantic, and component. Primitive tokens describe the value. In the case of color, this might be a color ramp. IE red/100, red/200, red/300. Semantic tokens reference primitive tokens. IE bg-brand might have its value set to blue/300. This layer is sometimes called a "reference" layer because of this, but I'm not a fan of that nomenclature since the component layer also references the semantic layer. The component layer is one that describes where in a component the token should be used, ie button-bg or button-text. I highly, HIGHLY recommend against using a component layer though in all but the most extreme multi-brand situation. If you aren't unilever, you should never use component tokens.

Aren't there many, many schemes for naming tokens in design systems? Aren't you being a bit forward in presenting this as a general practice?

https://medium.com/eightshapes-llc/naming-tokens-in-design-s...

Nathan is talking about naming schemes within each tier I mentioned, not different tiers. That blog is detailing naming schemes for the semantic and component layer.

The primitive/semantic/component set of tiers are a general practice. Naming within them heavily differs (and should!). The names you use for the individual tokens depend on goals and intent - ie Google’s material’s semantic layer uses a naming schema that’s designed for colorful variety of themes (albeit at the expense of clarity of how they should be used), whereas Apple uses a far more simplified naming schema since the design of their apps has far fewer design differences.

Not parent, but the generalization is true. There’s usually a base layer (red/300, etc) and a more semantic layer (.text-danger).

As your link covers, there’s then a million different ways to implement/extend that based on whatever theming and systems you’re implementing on top.

This only works if you don’t let users theme your site. If you do, then OPs approach works better.

The worst part of frames is scrolling.

You have to give an iframe a specific height in pixels. There is no “make this iframe the height its content wants to be (like normal HTML).

This leads to two options:

- your page has nested vertical scroll bars (awful UX) - you have to write JavaScript inside and outside the frame to constantly measure and communicate how tall the frame wants to be.

Or you could just not use frames.

I guess, the best you could do is emulating a frameset layout with a fixed navigation and a display frame for the actual content. (By setting the overflow to `hidden` you can get rid of the outer scrollbars.)

In what way is for different than an iterator?

In PHP you loop through an iterator with the foreach control structure.

In JavaScript you use for of.

In rust it’s for in.

What am I missing?

You're missing that I am an idiot and was mixing up iterators with functional style programming :D

Apple TVs have a mode that compresses dynamic range in sound and boosts dialogue.

Alternatively you could get a 3.1 audio setup and just boost the heck out of your center channel.

I can also second the usage PHPStorm over VSCode for PHP work. On a team of 10 PHP devs we have just one that prefers VSCode.

Isn’t yaml a strict superset of JSON? Any compliant YAML parser should be able to ingest a JSON document.

> I have been pressured multiple times by Brian Ingerson (one of the authors of the YAML specification) to remove this paragraph, despite him acknowledging that the actual incompatibilities exist. As I was personally bitten by this "JSON is YAML" lie, I refused and said I will continue to educate people about these issues, so others do not run into the same problem again and again. After this, Brian called me a (quote)complete and worthless idiot(unquote).

> In my opinion, instead of pressuring and insulting people who actually clarify issues with YAML and the wrong statements of some of its proponents, I would kindly suggest reading the JSON spec (which is not that difficult or long) and finally make YAML compatible to it, and educating users about the changes, instead of spreading lies about the real compatibility for many years and trying to silence people who point out that it isn't true.

> Addendum/2009: the YAML 1.2 spec is still incompatible with JSON, even though the incompatibilities have been documented (and are known to Brian) for many years and the spec makes explicit claims that YAML is a superset of JSON. It would be so easy to fix, but apparently, bullying people and corrupting userdata is so much easier.

Well that’s disappointing.

This explains some things on, like, a mythic level, that I’ve felt about yaml practically since the first time I saw it.

I guess software are human texts after all.

Are there no cases where well-formed JSON could be subject to the problems covered in the article, when parsed by a compliant YAML parser? I'm asking because I know nothing about YAML and not much more about JSON.

Not that I know. JSON requires strings to be quoted which is basically the problem here. Of course it’s not a great human writable configuration format (no comments being a huge problem).

I’m just pointing out that it should be very simple to swap a YAML file for a JSON file in any system that accepts YAML

JSON is stricter than YAML so that class of issues is avoided.

Yes. Rewriting a YAML file into strict JSON won't have any impact on the ingestion or the processing of it.

Write that tiny of bit of JS inline in the head and put the class/attribute on the html element.

I will note that at least for our GitHub enterprise setup permissions are all granular, tokens are managed by the org and require an approval process.

I’m not sure how much of this is “standard” for an org though.

I went and loaded up the flutter web demo on my iPhone 15 Pro https://flutter.github.io/samples/web/material_3_demo/

In addition to the pitfalls mentioned like being unable to select text, every interaction including scrolling is noticeably laggy and dropping frames.

> unable to select text

Because of this alone I would not use.

It's just not the default. As the developer, it's trivial to make text selectable.

You can make text selectable, but it still won’t behave at all like normal text. Selection word boundary things won’t match the local platform behaviour, touch behaviour cannot possibly work properly, things like context menus won’t work properly, and more.

The only way you can get the proper behaviour for these things on the web is to use actual DOM text. Some parts of it could in theory be made possible, but I doubt that anything meaningful will ever change—it’s too antithetical to the nature of the web.

"Proper behavior"... You've defined this term as the precise behavior of the technology that Flutter aims to supplant.

Indeed, Flutter will never do everything "properly". But that's not its selling point. It doesn't need to, as long as the number of users reached from a multi-platform release outweighs the users lost because they were offended by a missing native feature. (Assuming you're not some massive company developing a parallel app for each platform)

I meant it as an user.

If the developer has decided you are not allowed to, then you can’t really blame the tool he’s using…

I do not blame the tool, but I will avoid using it as long as I am unable to select text.

Additionally, see: https://news.ycombinator.com/item?id=43215065

Fair. If that's the deciding factor on whether you use a computer program, that's your prerogative. I assume, then, that every app on your phone allows you to select every bit of text in it?

Wow, you weren't kidding: same phone and it feels like I'm using a 15-year-old Android. That's rough.