This is very American, The Green Book guided Black travelers to safe businesses during Jim Crow. The Underground Railroad was literally an information network to help enslaved people reach freedom. During WWII, communities helped hide Japanese Americans from internment. LGBTQ+ people created networks to find safe spaces during decades of criminalization. Native communities have long shared information about safe passage and resources.
Well said. A few days ago I made a response to a comment in a thread, where I laid out a list of some aspects of American Culture [1]. And, 2 of the BIG ones in the Beliefs category were, "fundamental distrust in government and a shared collective identity in those against it, free-speech absolutism"
Except they don't believe in free-speech absolutism. They say they do, but they obviously don't, because every time one of them gets in control of speech, they make it substantially less free.
They don't believe in fundamental distrust of government either, they're a little more forgiving of interpretation and purpose of policy when they're in charge - nonetheless, these virtues are in the American zeitgeist for better or for worse.
I think that’s kinda misleading, isn’t it? You make it sound like it’s making good progress towards standardisation. They asked for feedback from other browser vendors, everybody said no, and they are shipping it anyway. Is “incubation happened, now on to origin trials before standardisation” really a suitable summary of that?
> “incubation happened (and we don't care what anyone said), now on to origin trials before standardisation (in chrome, and good luck if you use another browser)”
That's exactly how google would describe it with some missing context added.
Technically, it’s not two browsers shipping it, it’s two independent implementations. Otherwise everything that Google ships as part of Blink would become a standard as soon as any one of the other Blink-based browsers (e.g. Edge) includes it.
Well, they moved on despite both other major engine vendors having a negative position on this spec, so is the standards process really doing anything?
Sickle cell disease is caused by a mutation in the HBB gene, not by belonging to a specific race. Race is a social construct, meaning it's defined by social factors rather than strictly biological ones. Since someone who is Black in the US often has about 20% European ancestry, how does this compare to someone who is directly from an African country? Where is the line?
>Race is a social construct, meaning it's defined by social factors rather than strictly biological ones.
that sounds like if a child grows in different social environment it may have different skin color, eye shape and other attributes ascribed to the race. Btw, in USSR in 194x-195x similar theory was a prevalent biological theory (professor Lysenko) greatly supported by the Communist Party against the "bourgeois theory of genetics", and the people who dared to challenge that theory were ostracized, fired, sent to GULAG.
You are just putting to much wieght on skin color. You can't tell someone's race by looking at them. Australia aboriginal people are not really related* the Africans for example.
It’s more like “people with similar genetics tend to grow up in the same locations for many generations” and out of that comes skin coloration, genetically linked diseases, etc. Race is still a social construct based on factors our imperfect brains have associated with the different races we’ve made up for ourselves.
Mostly correct. Radio, satellite, and internet all pay different kinds of royalties at different levels (or used to, last I checked). I believe radio only pays the songwriters/publishers, whereas [streamer] might’ve also paid the performers.
This is also different than how individual companies - say Spotify - pay for content via direct deals.
I’m also confused because Pandora is ad-supported and generated ~1B per year, but the numbers here are low. But that may be captured in some other metric.
Not quite, Ionic Stencil is library to helps build webcomponents. Since fast.design are webcomponents, they can be used in any with any framework, no wrapping required.
Handling data
React passes all data to Custom Elements in the form of HTML attributes. For primitive data this is fine, but the system breaks down when passing rich data, like objects or arrays. In these instances you end up with stringified values like some-attr="[object Object]" which can't actually be used.
Handling events
Because React implements its own synthetic event system, it cannot listen for DOM events coming from Custom Elements without the use of a workaround. Developers will need to reference their Custom Elements using a ref and manually attach event listeners with addEventListener. This makes working with Custom Elements cumbersome.
This is a pain point of React + web components, but I’ve heard they’re trying to solve it in the next major version. In the meantime, I built a wrapper that lets you use custom elements as if they were React components. [1]
Ah, thanks for the clarification. I know the developer of Framework7.io has a tool to take his components (not webcomponents though) and make them into React/Svelte/Vue native ones. So I kinda mixed the two tools together in my head.
> they can be used in any with any framework, no wrapping required.
That's the selling point, but is not quite true. At least a while ago there was still some ceremony needed at least in React. You could say that that's React's fault, but it doesn't really matter whose fault it is - Web Components are different from standard DOM elements, and thus need special treatment from frameworks that interact with standard DOM elements.
They're not different from built-in elements and don't need special treatment.
The way that frameworks that work well with web components do it is be not giving special treatment to things. Vue, Angular, and lit-html all treat built-ins and custom elements then same, and they have different syntax for setting attributes and properties.
React treats elements different from components and sets properties on React components and attributes on HTML elements, with no syntax to set properties on elements. Then it special cases a list of attributes so that things like `class` map to `classList`.
So... remove special cases, add general abilities, and it all just works.
They're different from built-in elements at least in the fact that they're not built-in - that is the problem with React, which works with a list of built-in components that are treated differently from React components. Which means React needs special treatment for Web Components.
Whether React should or should not be doing that is irrelevant; what's relevant is that as a developer, you need to be aware that you can't "just" use Web Components in any framework.
That seems a rather silly distinction to me: "They're a special case because they're not on React's list of special cases".
You've correctly pointed out that the special cases are the problem, but are putting the blame on the things that are not special cases instead of the thing doing the special casing.
This is fundamentally React's problem. It's the only major framework to even have issues here.
Sure, but if your standard is "it can work in React, just with some more work and downsides", then technically you can use Angular components in React as well.
tl;dr you'll still be doing the wrapping in practice.
I'm really eager to see availability of some extra features via this new pathway.
But I am less excited about projects containing TypeScript plus the large number of transitive dependencies from a typical Babel set up; I've been greatly enjoying TypeScript instead of that.
Edit: wait it looks like they’ve changed to all Rust with C++ for the libraries. I haven’t looked at the codebase since the spring. Am I crazy that i could have sworn it was written in Go previously?
100% agreed. It was incredibly liberating to move from Babel with its byzantine level of configuration and plugins to "just run tsc". So much easier to reckon with - Typescript is Typescript is Typescript.
For my part, my web projects have generally ended up with both Typescript and Babel because of old-browser-support reasons, so integrated parsing simplifies things for me.
I don't have that extension, I do have Comcast, and I don't see injected Comcast content. Either uBO or another blocker (belt and suspenders) is blocking that, or they don't do it in my region, or my block, or whatever.
Not true. They've been injecting ads to my android phone which is served by a wireless device I own. And I haven't pirated anything. I had to switch to Firefox with ublock to fix it.
Unfortunately when hitting a data limit that causes these Comcast pop ups it breaks HTTPS connections. The only way to regain internet access is to visit a HTTP site such as example.com to get the pop up.
I've had this experience too. I complained to the FCC about it, and for my efforts got a likely-cookie-cutter mail response from comcast explaining that they provide these "rare, important messages" "for my own good".
edit: to clarify, I was complaining about the fact it broke all my connections, not that it was going on in the first place (which i'm also livid about)
