cjpearson

I still don't think there's any significant difference. You can create popover elements without JavaScript, but you can also create divs with a high z-index without JavaScript. You can toggle popover visibility via CSS or click without JavaScript, but you can also do that with divs and a checkbox.

It's a different agency, but Matt Levine has written a fair amount on the SEC making a killing by fining banks when their employees use SMS or WhatsApp. It's a similar story where conversations that might have been held at the water cooler, lunch, after-work beers or the golf course are now often done through text which according to SEC means different regulation applies.

> From the perspective of the banks, I have argued, this is a novel expansion of the SEC’s authority. When the SEC created its rules on recordkeeping, it required banks to retain copies of their “inter-office memoranda,” but it was 1948 and those memoranda were produced with carbon paper; they were formal business records memorializing serious policies. In the 2020s, WhatsApp chats are, in large part, substitutes not for formal memoranda but for talking to someone in person. When I was a banker, I have written, “There were some mornings when I sent more than 100 inter-office memoranda, though like 20 of them would be ‘lol’ or ‘fml.’” In 1948, the SEC would not have dreamed of demanding a searchable archive of all of the informal chats held at a brokerage: That was not technologically feasible, and also did not seem to be the point of its rules. In 2022, it was feasible, and the SEC did demand it, and when the brokers were missing some chats they paid a billion dollars in fines.

Typically, yes I agree. But if you're evaluating someone's expertise in open source contributing, looking at their open source contributions is fair game.

This is a good point and thanks for sharing.

I would add that in my experience the bar for "reasonably popular" is much lower than people would typically expect. One or two issues a month may not be much if you're actively using and maintaining the project, but it can easily become a burden if you've moved on from the project. You either spend a few hours a month keeping it up to date, or feel like you're letting someone down.

There isn't really a good solution to escape. Someone may submit patches on their own or offer to take over maintenance, but I'm not willing to ship code that I haven't reviewed or tested and would not risk transferring it to someone unknown. (We've seen what can happen there.) Deleting the project is an option, but that also negatively impacts existing users in a drastic way. The best approach I think is to clearly indicate that the project is no longer maintained and suggest creating a fork if they need to make changes.

This statement does seem a little ironic coming from a browser which is Chrome with a different design.

I can see how it causes problems, but I don't really see any alternatives for certain properties. Would you want to set the color property on every element that contains text? Or do something with the universal selector?

CSS does actually call it inheritance[0], but it's commonly mixed up with the cascade. Inheritance applies to certain properties, so that when they are not specified on an element, an element inherits the value of the parent.

The cascade[1] determines how rules from multiple sources are merged.

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance [1]: https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade

Very few students will pay that price. Even those above financial aid thresholds will typically be offered a ~~sale price~~ merit scholarship. Also, if they have other offers they can try and price match. The sticker price is so high because it feels nice to get something for 50% off. Much more so if it was due to your "merit" rather than your coupon clipping prowess.

College tuition is expensive, much more than it should be, but the obsession over a sticker price that is almost never relevant is silly. People should be more concerned about the actual cost of attendance.

The standard argument for office work is that there are some intangible benefits to in-person work and communication that can't be effectively replicated over zoom and slack. The cynical argument is that managers like being able to walk around the room and count their worker bees. The conspiratorial argument is that corporations are in cahoots with commercial real estate developers.

There are debates on all these arguments, but your coffee pot standard is the opinion of most hn users.

I find the situation is similar to right-to-work laws. If you find the walled-garden/closed-shop beneficial, you will not want it to be forcibly cracked open. Even though an individual can opt to remain with the App Store (or union), the influence of Apple (or the union) has diminished relative to the employer (or Facebook, Epic etc).

In the end, despite all the marketing, neither issue is about user or worker freedom. It's about which entity has more power.

I don't disagree with the main point here, but the dev-dependencies won't be installed or run on your machine unless you're building Tailwind or Panda itself. They're not necessary for processing the CSS.

The idea of a simpler, less bloated Slack is definitely appealing to me as a user, but I'm not sure there's much of a market. What kind of companies are they targeting here? Small enough that user access dialog is usable and the lack of features/integrations is acceptable, but also willing to pay $300 and take on the trouble of self-hosting.

My biggest issue is with the UI though. Without watching the video I wouldn't know what half the buttons do. Many of them have multiple actions/states and there are no labels or tooltips for buttons.

Forms do have labels, but you have to click an icon to read them. It seems the only benefit of this is that you can also see what the label is in French, but unless you're translating the app, most users would prefer to just see the label in the language of their choice. And there are some dialogs where just English text is shown, so this isn't entirely consistent. Maybe I'm totally missing something here, but I think simply having a user select their preferred language isn't something that needed to be innovated away.

Originally, the project had a goal of zero dependencies. [1] I assume that was considered infeasible with the migration to Rust, but part of the philosophy remained.

[1]: http://web.archive.org/web/20201101030019/https://rome.tools...

"Accident" is the official terminology, not an attempt to downplay the severity.

> Native oxide is stripped off the wafer with a quick dilute HF dip and then they are extensively cleaned in Piranha solution (H2SO4:H2O2), RCA 1 (H2O:NH3:H2O2), RCA 2 (H2O:HCL:H2O2), followed by another dilute HF dip.

Fascinating project, but I'm not going to try this one at home

They can, but they'd have to make those downloads only available to NZ users. This is also why American sites need to block EU users or comply with the GDPR. You can't just pick a server location with the laxest laws.

IIRC, Gutenberg already does this, limiting access from Germany which has a stricter copyright than the US.

In my experience there are almost never issues. Standardization has gotten much better, and as a web developer I appreciate all the effort the various browser teams have put into ensuring common behavior.

The effort of "supporting Firefox" as a developer is basically opening the app in Firefox and confirming that it works, which it basically always does because the app is built on standardized web features. (Other types of support might be different. e.g maybe you have help doc that tells your users how to clear the site cookies. Do you also want to write instructions for Firefox, Safari, Opera etc?)

The bigger concern is that some day Google might not need web standards. If developers target Chrome rather than the web platform, Google has free reign and no longer needs to compromise with Apple and Mozilla. For example, Mozilla's veto of the controversial Topics API would hold little weight if nobody cares about Firefox support. If Chrome gets to a dominant enough position it could move from embracing to extending quite quickly.

People have different opinions on Google, but even those who believe Google has no ill intentions still feel better if there are some checks and balances. Were Firefox to become obsolete, Apple would be the last one standing. And with the DMA, some are predicting that Safari could soon follow Firefox's decline.

I doubt it means anything. The 3rd gen iPad was superseded within 6 months, but it still had 7.5 years of support.

An important factor is knowing your audience. Writing a book review? Go ahead and use "bildungsroman". A scientific paper? Neodymium, amygdala, or ionosphere will probably be understood.

The goal of a writer shouldn't be to confuse their readers or make them feel dumb, but they also shouldn't sacrifice a perfectly fitting word that 90% of the audience understands for a weaker substitute that 100% understand.

I often look up words when reading. Sometimes new words, and sometimes words I have a rough understanding of but am curious about their dictionary definition. I almost never see as the author's failure or mine.

Many of the words in this list I've never seen before, but I don't think that means they should necessarily be discarded. And I wouldn't want writers to avoid words like bowdlerize, vestigial, avuncular, defenestrate, palimpsest or sinecure just because they could be replaced by a more common word or phrase that means almost the same thing.

Apple used to ban advertising push notifications. They began allowing them to avoid claims of anti-competitive behavior.

It seems that nothing is so permanent as a temporary Schengen border control. Some of them have been in place since 2015 and it doesn't look like they'll go away any time soon. In fact Germany is looking to expand them, adding border controls on its Czech and Polish border.

Unless something changed recently, Firefox never dropped support. It's always been behind a feature flag though. Google gave some reasons on their issue tracker.

https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

Using a Google font causes the client to send a request to Google servers. The Google server then receives the client's IP address. Occasionally a judge will consider that a GDPR violation. [0] Sometimes using a CDN will also be considered a GDPR violation under the same logic. [1]

But it seems like it just depends on which judge you get. There are thousands of sites in Europe that use Cloudflare, Google Fonts and Shopify and only a few that have been fined because of it.

[0]: https://www.theregister.com/2022/01/31/website_fine_google_f...

[1]: https://lsww-de.translate.goog/shopify-illegal/?_x_tr_sl=de&...

> What we've seen happen over and over is that product A needs Feature A, and product B needs Feature B, and they both need it tomorrow, and the platform team only has resources for one.

Is this any different from a product team where there's competing demands between Customer A and Customer B?

The last case could be covered by the `dir` pseudo-class.

    .button-icon:dir(rtl) {
      transform: scaleX(-1);
    }

However, it's not yet supported in Chromium browsers, so for now the attribute selector is as close as you can get.

https://developer.mozilla.org/en-US/docs/Web/CSS/:dir

Oh, that could change things.

Although I think it still depends on what Apple means by "associated at any point in time with receiving digital content or services". I think they may be intending to allow something like GoFundMe or Venmo, while disallowing something like Reddit gold where users give gifts based on the digital content created even though that content isn't gated by payment.

Perhaps the developer's use of Bitcoin complicates things as well. Does Apple consider that a "monetary gift" or "digital content" or both?

Yes, I think their phrasing in that sentence is vague. It should be structured like the functionality one to make clear that tipping _may_ be added, but if implemented it _must_ use in-app purchases.

However, since tipping is not listed in the exceptions, one should read it as not being allowed.

It's hard to see this appeal going anywhere. The app store guidelines even explicitly mention this use case as one that requires in-app purchases to be used.

> Apps may use in-app purchase currencies to enable customers to “tip” the developer or digital content providers in the app.

Apple lists the limited scenarios where alternative purchase methods can be used and this one is not included. Since they mention it in the guidelines it's clearly something they are aware of.

You may disagree with Apple's policy, but bigger companies have fought this battle and lost. Intentionally (or unintentionally) misreading the guidelines isn't going to hold water on appeal.

Wouldn't it already be wire fraud?

There's a compelling argument [0] that the biggest driver of homelessness is a shortage of housing. Mental illness and addiction can lead to homelessness, but homelessness can also lead to mental illness and addition. There are lots of places suffering severely from the fentanyl crisis, but where homelessness is less of a problem.

The solution may be simple, but it's not easy. (And it's not the entire solution either) Building large quantities of housing is a difficult problem, especially in California.

[0] https://www.theatlantic.com/magazine/archive/2023/01/homeles...