If you’re talking browsers it’s poor. But HDR on displays is very much figured out and none of the randomness that you get with SDR with user varied gamma, colorspace, and brightness. (That doesn’t stop manufacturers still borking things with Vivid Mode though).

You can pack HDR in JPG/PNG/WebP or anything that supports a ICC and Chrome will display it. The actual formats that support HDR directly are PNG (with cICP) and AVIF and JpegXL.

Your best bet is use avifenc and translate your HDR file. But note that servers may take your image and break it when rescaling.

Best single source for this info is probably: https://gregbenzphotography.com/hdr/

The point is to show it’s uncapped, since SDR is just up to 200 not. It’s not tonemapped in the image.

But, please, continue to argue in bad faith and complete ignorance.

This is a trash take.

I just wrote the ability to take a DX9 game, stealthy convert it to DX9Ex, remap all the incompatibility commands so it works, proxy the swapchain texture, setup a shared handle for that proxy texture, create a DX11 swapchain, read that proxy into DX11, and output it in true, native HDR.

All with the assistance of CoPilot chat to help make sense of the documentation and CoPilot generation and autocomplete to help setup the code.

All in one day.

Definitely not. NoJS is not better for accessibility. It’s worse.

You need to set the ARIA states over JS. Believe me, I’ve written an entire component library with this in mind. I thought that NoJS would be better, having a HTML and CSS core and adding on JS after. Then for my second rewrite, I made it JS first and it’s all around better for accessibility. Without JS you’d be leaning into a slew of hacks that just make accessibility suffer. It’s neat to make those NoJS components, but you have to hijack checkbox or radio buttons in ways not intended to work.

The needs of those with disabilities far outweigh the needs of those who want a no script environment.

While with WAI ARIA you can just quickly assert that the page is compliant with a checker before pushing it to live.

Also no. You cannot check accessibility with HTML tags alone. Full stop. You need to check the ARIA tags manually. You need to ensure states are updated. You need to add custom JS to handle key events to ensure your components work as suggested by the ARIA Practices page. Relying on native components is not enough. They get you somewhere there, but you’ll also run into incomplete native components that don’t work as expected (eg: Safari and touch events don’t work the same as Chrome and Firefox).

The sad thing is that accessibility testing is still rather poor. Chrome has the best way to automate testing against the accessibility tree, but it’s still hit or miss at times. It’s worse with Firefox and Safari. You need to doubly confirm with manual testing to ensure the ARIA states are reported correctly. Even with attributes set correctly there’s no guarantee it’ll be handled properly by browsers.

I have a list of bugs still not fixed by browsers but at least have written my workarounds for them and they are required JS to work as expected and have proper accessibility.

Good news is that we were able to stop the Playwright devs from adopting this poor approach of relying on HTML only for ARIA testing and now can take accessibility tree snapshots based on realtime JS values.

• https://bugs.webkit.org/show_bug.cgi?id=260772
• https://www.w3.org/WAI/ARIA/apg/patterns/combobox/#keyboardinteraction
• https://github.com/microsoft/playwright/issues/16159#issuecomment-1609677393

Created by Charlie Brooker of Black Mirror fame? Okay, I’m in.

Exactly. Is it really loyalty when you only have one option?

Rip iPhone.

scrape.maxDepth = 5

Seriously. They probably sell real dry pizza. Pineapple without enough tomato sauce on “pizza” is trash.

Imagine the world we would have lived in if there were oil rigs there instead.

I have just dumped code into a Chrome console and saved a cert while in a pinch. It’s not best practices of course, but when you need something fast for one-time use, it’s nice to have something immediately available.

You could make your own webpage that works in the browser (no backend) and make a cert. I haven’t published anything publicly because you really shouldn’t dump private keys in unknown websites, but nothing is stopping you from making your own.

That’s what NodeJS and Deno are.

The point of the browser support means it runs on modern Web technologies and doesn’t need external binaries (eg: OpenSSL). It can literally run on any JS, even a browser.

Just going to mention my zero-dependency ACME (Let’s Encrypt) library: https://github.com/clshortfuse/acmejs

It runs on Chrome, Safari, FireFox, Deno, and NodeJS.

I use it to spin up my wildcard and HTTP certificates. I’ve personally automated it by having the certificate upload to S3 buckets and AWS Certificates. I wrote a helper for Name.com for DNS validation. For HTTP validation, I use HTTP PUT.

I can spend 2 minutes scanning a page for a certain word every time I need to search for something.

But I’m very happy somebody spent the time to code Ctrl+F.

Don’t use JSON for the response unless you include the response header to specify it’s application/json. You’re better off with regular plaintext unless the request header Accept asked for JSON and you respond with the right header.

That also means you can send a response based on what the request asked for.

403 Forbidden (not Unauthorized) is usually enough most of the time. Most of those errors are not meant for consumption by an application because it’s rare for 4xx codes to have a contract. They tend to go to a log and output for human readers later, so I’d lean on text as default.

Even line-height in CSS3 is draft. Saying no drafts should be implemented is a ridiculous standpoint: a standpoint not even Firefox aligns with:

Standardization requirements for shipping features

What evidence is necessary will vary, but generally this will be:

W3C - the specification is at the Candidate Recommendation maturity level or more advanced; shipping from a Working Draft or a less advanced specification requires evidence of agreement within the working group that shipping is acceptable

https://wiki.mozilla.org/ExposureGuidelines

But keep moving those goal posts.

What? They all have W3C specs. Firefox just chose not to implement them.

• https://www.w3.org/Graphics/Color/Workshop/talks.html
• https://www.w3.org/TR/appmanifest/
• https://wicg.github.io/shape-detection-api/#barcode-detection-api
• https://www.w3.org/TR/nfc/
• https://www.w3.org/TR/accname-1.2/#computation-steps
• https://drafts.fxtf.org/css-masking/#the-mask-border

You think you’re trashing Chrome, but you’re trashing Firefox instead.

Firefox, unfortunately, has been lagging behind. Safari is close to surpassing Firefox if they haven’t already. Safari really made a big shift for actually implementing web standards around 16.4.

• No HDR - relevant for me because I mod PC games for HDR
• Dropped PWA on desktop - even Apple went full 180° and embraced it now on Mac OS X. Chrome really gets a good push from this from Microsoft constantly helping push more app manifest stuff since it appears one of their goals is to render more things over Edge PWAs (eg: like the title bar), and resort less to having to use electron.
• No masked borders - can’t do custom element borders like corner cutting or perfect squircles. Rounded edges only

Chrome is still the absolute best for accessibility. Neither Firefox nor Safari properly parse the aria labels when it comes to how things are rendered. Chrome will actually render text in accessibility nodes as presented on screen (ie: with spacing). Safari and Firefox only use .textContent which can have words beingmergedwhentheyshouldn’t.

Chrome also has Barcode and NFC scanning built right in. I’ve had to use fake keyboard emulators for iOS. Though, Chrome on Mac OS X also supports it. Safari has native support for Barcode behind a flag, so it’ll likely come in the future. Barcode scanning is still possible with Firefox through direct reading of the camera bitmap, which is slower but still good. There’s no solution for NFC for Safari, but if Chrome ever comes iOS, that would possibly be solved. I believe Face Detection is similar, but I’ve never used it.

I’ve also used .local but .local could imply a local neighborhood. The word itself is based on “location”. Maybe a campus could be .local but the smaller networks would be .internal

Or, maybe they want to not confuse it with link-local or unique local addresses. Though, maybe all .internal networks should be using local (private) addresses?

I’ve been using uBOLite for about a year and I’m pretty happy with it. You don’t have to give the extension access to the content on the page and all the filtering on the browser engine, not over JavaScript.