SquareWheel

It means exactly what it says: "What other parties do you mean?". Key players are already in lockstep on this decision, so insisting that Google must submit to the other WHATWG members doesn't make any sense in an argument for restoring XSLT or JPEG XL.

You seem to be reading subtext into a statement that was put plainly.

I made no such implication. Mozilla is certainly an other party, and their positions on standards hold water. They successfully argued for Web Assembly over Native Client, and have blocked other proposals such as HTML Import in the Web Components API. They are still a key member of the WHATWG.

The fact that Mozilla aligns with Google on both of these deprecations suggests the reasons are valid.

I personally see no reason for XSLT today. Outside of the novelty of theming RSS feeds, it sees very little use. And JPEG XL carries a large security surface area which neither company was comfortable including in its current shape. That may change based on adoption and availability of memory-safe decoders.

Which other parties? Because Mozilla's stance on JPEG XL and XSLT are identical to Google's. They don't want to create a maintenance burden for features that offer little benefit over existing options.

It's one thing to judge somebody for supporting an unjust and illegal war. It's another thing entirely to judge them for where they were born. None of us chooses our nationality.

Why do you say that? If they drop 32-bit support, maybe I won't be able to play games for a time - at least until somebody rigs up a fix - but at least my operating system will still be supported.

If Bazzite goes poof overnight, though, that's a major problem. At least Fedora's official spins will continue to receive necessary updates.

I was using Bazzite, but they started talking about potentially shutting it down due to a removal of 32-bit support. It seems a bit safer to choose one of the mainline Fedora spins. Maybe Kinoite or Silverblue if you're into atomicity, though there's still some rough edges to be aware of.

They're complimentary. As a general (though not exclusive) rule, consider flex for one-dimensional layouts, and grids for two-dimensional layouts.

That may work for blocking bad automated crawlers, but an agent acting on behalf of a user wouldn't follow robots.txt. They'd run the risk of hitting the bad URL when trying to understand the page.

Forcing shorter answers will definitely reduce their quality. Every token an LLM generates is like a little bit of extra thinking time. Sometimes it needs to work up to an answer. If you end a response too quickly, such as by demanding one-word answers, it's much more likely to produce hallucinations.

I think you've misunderstood. The title did not originally include the text "Show HN". I was suggesting that to the submitter, since they were submitting one of their own projects.

Should this be a Show HN?

I find it a little overwhelming.

Like erikrthoff suggested, I'd drop the light mode toggle and just go with prefers-color-scheme. Then I'd move the X buttons to the top-right of their respective sections (timers, segments), and move the Add Timer button underneath.

Mockup: https://i.imgur.com/EcSHX7S.png

It's an amusing solution, but if this ends up being anything like the missing PHP 6, it's also going to cause confusion for users. It might've been better to just mea culpa and release 3.0 anyway. I can't imagine anybody would really hold it against the author.

> Why on Earth would be arguing in favor of Google locking down how I can install software on my device.

They didn't argue for that anywhere in their comment.

I'm not sure what to tell you. I'm a professional with nearly two decades of experience in this industry, and I don't read any white papers. I read web publications like Smashing Magazine or CSS Tricks, and more specifically authors like Paul Irish, Jake Archibald, Josh Comeau, and Roman Komarov. Developers who talk about the latest features and standards, and best practices to adopt.

The view that professionals in this industry exclusively participate in academic circles runs counter to my experience. Unless you're following the latest AI buzz, most people are not spending their time on arXiv.

The PSL is surely an imperfect solution, but it's solving a problem for the moment. Ideally a more permanent DNS-based solution would be implemented to replace it. Though some system akin to SSL certificates would be necessary to provide an element of third-party trust, as bad actors could otherwise abuse it to segment malicious activity on their own domains.

If you're opposed to Safe Browsing as a whole, both Chromium and Firefox allow you to disable that feature. However, making it an opt-in would essentially turn off an important security feature for billions of users. This would result in a far greater influx of phishing attacks and the spread of malware. I can understand being opposed to such a filter from an idealistic perspective, but practically speaking, it would do far more harm than good.

It's generally good advice, but I don't see that Safe Browsing did anything wrong in this case. First, it sounds like they actually were briefly hosting phishing sites:

> All sites on statichost.eu get a SITE-NAME.statichost.eu domain, and during the weekend there was an influx of phishing sites.

Second, they should be using the public suffix list (https://publicsuffix.org/) to avoid having their entire domain tagged. How else is Google supposed to know that subdomains belong to different users? That's what the PSL is for.

From my reading, Safe Browsing did its job correctly in this case, and they restored the site quickly once the threat was removed.

Sorry to say, but your site does flashbang when navigating pages in dark mode. It would also be good if it inherited its initial state from the user preference, rather than requiring a manual adjustment.

> While this is really handy, it is a best practice to allow users to manually toggle the color-scheme as well. Some people prefer a dark system theme, but light website themes, and vice-versa.

It can make sense for a theme selector that works on the server, since you can serve specific HTML when building the page. However, if using a JavaScript-based solution that fetches the theme preference from localStorage, I find this almost always results in a "flashbang" in dark mode, as the retrieval is slower than the first browser paint.

I've been implementing (and recommending) pure CSS-based theming to avoid this problem. Users seem much happier with them, and I haven't heard anybody ask for a theme switcher. We just respect their existing preference. However, I can see this being a problem if you offer multiple color schemes (beyond just light and dark).

I'd be curious to know if anybody has found a way to avoid this issue with JS switchers -- ideally without needing to delay the initial paint.

I do think an interesting approach would be a browser extension that lets you override the prefers-color-scheme property on a per-domain basis, similar to the toggle in dev tools.

> you don't know which argument is high and which is low when you read the code and encounter that function

It's defined in the function parameters. Surely your IDE would let you know the correct order? Otherwise, you could make that comment about every single function you encounter.

A children's dose of Tylenol is 160mg. The regular strength is is 325mg. The extra strength is 500mg.

Jailbreaking an LLM is little more than convincing it to teach you how to hotwire a car, against its system prompt. It doesn't unlock any additional capability or deeper reasoning.

Please don't read into any such conversations as being meaningful. At the end of the day, it's just responding to your own inputs with similar outputs. If you impart meaning to something, it will respond in kind. Blake Lemoine was the first to make this mistake, and now many others are doing the same.

Remember that at the end of the day, you're still just interacting with a token generator. It's predicting what word comes next - not revealing any important truths.

edit: Based on your edit, I regret feeling empathy for you. Some people are really struggling with this issue, and I don't see any value in pretending to be one of them.

Whether it's aimed at large companies or not, I'd still rather not see misinformation spread. People already have poor enough understandings of what companies actually do and don't collect. There exists ongoing conspiracy theories that phones actively listen to conversations while in your pocket, despite there being no evidence to such a claim.

Facts do matter, and I appreciate those that make an effort to state them correctly.

Maybe this only proves your point, but there is no float: clear. They're separate properties.

  float: none;
  clear: both;

1.2 gigametres? That's traveled further than some satellites.

Isn't RSS a smashing success? I changed readers after Google Reader died, but otherwise, my feeds have been working seamlessly for nearly 20 years. I rarely meet a site with updates that doesn't support RSS.

Since you're asking, you could use it to tie together triggers and actions to embed code in specific situations (eg. based on the URL or page state). It has automatic versioning. There's a preview feature for testing code changes before deploying, and a permission system for sharing view/edit access with others.

It is true that the CMA is concerned with the new API proposals within the Privacy Sandbox such as Topics. However, this is from an anti-competitive angle, rather than privacy. Their goal is to ensure market fairness.

As part of that same process, they have put considerable friction in place for removing third-party cookies. They've deemed that the removal of third-party cookies could give Google an unfair market advantage, and that is why they're concerned with finding an alternative solution to replace them. This has been a very slow process, and involves many discussions and debates with regulators. That has had significant influence on the design of the Topics API.

To provide a more direct example, the CMA have also put specific stalls into the deprecation process, such as the standstill period invoked last year:

> The CMA will start a formal review of Google’s plan to deprecate cookies and Chrome’s Privacy Sandbox replacements once Google triggers a 60-day standstill period, likely at the beginning of the third quarter. During this standstill, the tech giant is forbidden to put in motion any deprecation procedures on Chrome. ... If they can’t reach an agreement, the 60-day standstill period will become 120 days.

https://www.adweek.com/programmatic/the-cma-is-prepared-to-d...

To put it simply, third-party cookies would have been dead and buried long ago if this dispute were not happening. It may be possible for Google to remove third-party cookies without a replacement, but they'd have be risking a significant lawsuit and contravention of UK authority by doing so.

> No one is trying to stop google from removing third party cookies.

That's simply not true. As I already mentioned, the CMA presented a legal challenge which you can read about online. Please review the history, as it's been going on for years now.

https://www.gov.uk/government/news/cma-to-have-key-oversight...

https://www.marketing-beat.co.uk/2024/02/06/cma-cookies-goog...

This is very misleading. Google was prevented from disabling third-party cookies due to intervention by the CMA, who felt it would provide an unfair advantage over other advertisers. Google argued their case for years, proposed competing standards to act as a replacement (see Topics API), and eventually gave up on the endeavour altogether and simply made it a user toggle.

FYI: You wrote Chrome 14 in the post, but I believe you meant Android 14.