The existing Postgres license already has an "as is" disclaimer, so adding this clause means you want to _punitively_ punish companies that sue you for reasons outside of this software. The interpretation then is you want to punish users of your software that find themselves in a (potentially legitimate) situation to sue you over unrelated matters.
For example, if Supabase failed to pay a vendor that happened to use OrioleDB they wouldn't be able to sue you for damages without compromising their stack. That's uncool.
My take-away from the Facebook/React license issue was that the community agrees this violates the spirit of FOSS and invalidates claiming to be open source (at least OSI-approved), with many taking offense to the punitive nature of the clause.
Granted Facebook was in a position to see litigation over a lot more reasons.
> brand throwing away the thing it's marketed itself for
I don't see what you see. It's a single product, not a realignment of their business model. They saw an opportunity and brought to market a product that will likely sell out, which tells us that customers are happy to make the trade-off of modularity and repairability for what the Strix Halo brings to the table. I think your interpretation of their mission is a bit uncharitable, maybe naive, and leaves the company little room to be a company.
I disagree, the framework name has been intertwined with repairability since the inception. That is their USP and has been their marketing angle from day 1, not only that but the fact they are supposedly championing repairability due to their 'ethos' as a company.
Fair enough that a company might bring out products which differ from their core market, but in this instance I have to agree that releasing a desktop PC with soldered on RAM very much goes against the place they have positioned themselves in the market.
Perhaps a better solution would be to start releasing a newly branded product line of not so repairable machines, but keeping the name 'Framwork' for their main offerings.
All three comments to this thread have missed the point that OP said installable SPA, not website SPA. This means the primary bundle is downloaded offline and only API network requests are necessary.
But at what cost? If it’s not a CSS builtin, it’s going to use JS - it may not be something you care about, but it will be there. There’s no other way.
Tailwind compiles all the inline stuff to CSS, and this works in plain CSS. It’s just allowing you to define that inline, which you wouldn’t be able to do with inline styles.
It’s the same as how they enable media queries for example, they’re not using JS just plain CSS, but they’re making it available with these inline classes.
It's not even :has, it's just how child selectors in CSS have always worked.
// Not actually needed, here
// for competition
.group {}
// Child selector
.group:hover group\/hover\:bg-black {
background-color: black;
}
// Which is essentially the same as
.group:hover child {
background-color: black;
}
Based on other replies, I believe they understood CSS well enough, but didn't understand the exact behaviour of the `group` class in Tailwind. Given neither of your comments seem to have made much sense given the context of the discussion, I wonder if you're just looking for confirmation of things you already 'know'.
EDIT: I'm sorry, I mixed you up with the other user who was replying criticising other people's CSS knowledge.
Baseline 2023 meaning all major browsers supported it in their latest versions sometime in 2023.. Like all new CSS stuff it's probably been a very long time coming. Everyone can't pay attention to everything though, regardless of their beard color.
No need to apologize, it just does not make sense to belittle other people's work when you lack the knowledge to judge it. Nobody told you it used JS for the effect, you conjured that up yourself.
No, but `group` doesn't affect the parent in Tailwind. You put `group` in the parent to mark it, and then use the `group/...` syntax to apply different properties to the child, depending on the different states of the parent. This doesn't require `:has`.
I don't think Tailwind has a built-in `:has` tool, but I suspect it would be easy to add one as a custom class.
What do you mean? It's possible to apply attributes to any element in an arbitrary state: `hover:bg-black` would give an element a black background on hover. It's also apparently possible to apply attributes based on whether a state is fulfilled for a child element (i.e. the :has selector). E.g. `has-[:hover]:bg-black` would give an element a black background if any child is hovered.
This is a classic car salesman tactic. The idea is that a buyer that's completed paperwork will be more likely to agree to a last minute price increase "because my manager won't let me sell it for $X". It's a total bullshit move. It's so common it's even mentioned in the book Influence: The Psychology of Persuasion.
Because he's prolific writer on the subject with a history of thoughtful content and contributions, including datasette and the useful Python llm CLI package.
For example, if Supabase failed to pay a vendor that happened to use OrioleDB they wouldn't be able to sue you for damages without compromising their stack. That's uncool.
My take-away from the Facebook/React license issue was that the community agrees this violates the spirit of FOSS and invalidates claiming to be open source (at least OSI-approved), with many taking offense to the punitive nature of the clause.
Granted Facebook was in a position to see litigation over a lot more reasons.