141–150 of 283 posts
Earlier quoted context omitted.
Nah, google paved the way forward with vital developments like WebGPU und import maps. I stopped using and supporting Firefox because they refused to improve the internet.
Not everyone is using their browser to mine dogecoin.
Earlier quoted context omitted.
Your statement here amounts to “you can serve JPEG XL to other browsers, just not Chrome”. Yeah, that’s what I said.
This is the way of web. Sites don't get to dictate what the user agent does. The clue is in the name: user agent.
If the user agent does not support JPEG XL, then you cannot use it.
“Nobody is stopping you from using jpegxl” except Google.
Earlier quoted context omitted.
>and my experience is that PDF >> any other system for ebooks. Are you speaking just about technical books? Because I can’t imagine anyone trying to read a novel in epub vs pdf on a phone or epub reader and going with the latter.
I am mostly reading on a tablet, not a phone. I think if you are reading on a phone you are already screwed —- if people are “reading” on phones I think 80% of it is that you just read less.
As for phones, screens nowadays are almost the same size as readers and with more resolution. E-ink is more comfortable for longer sessions, but if you find such a size unusable you might just have poor eyesight.
Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface? I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation. I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we'…
libjxl is is <112,888 lines of code, about 3 orders of magnitude less than you're 100M+ claim.
Earlier quoted context omitted.
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.
Didn't Mozilla basically say they would support it if Google does? Mozilla doesn't have the resources to maintain a feature that no one can actually use; they're barely managing to keep up with the latest standards as it is.
If only there was a way to detect which features a browser supports. Something maybe in the html, the css, javascript or the user agent. If only there was a way to do that, we would not be stuck in a world pretending that everything runs on IE6. /s
Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.
That's why both Mozilla and Google have predicated their JXL support on a memory-safe implementation. There's a Rust one in the works. I think Google are aiming to replace all of Chromiums decoders with memory-safe ones anyway, even for relatively simple formats.
Earlier quoted context omitted.
>> 100M+ is a bit more than i would expect for an image format. have i not been paying attention > So at least if GP was talking about libjxl "100K+" would be more accurate. M can mean thousands and I think it's common to use it used that way in finance and finance-adjacent areas: https://www.chicagomanualofstyle.org/qanda/data/faq/topics/A... : > A. You’ve identified two commonly used conventions in finance, one der…
I assume this is regional... I work in accounting and finance in New Zealand (generally following ordinary Western/Commonwealth standards) and I've never heard of using M for thousands. If I used that I would confuse the hell out of everyone around me.
Earlier quoted context omitted.
libjxl is is <112,888 lines of code, about 3 orders of magnitude less than you're 100M+ claim.
Do people really not know what a hyperbole is?
Maybe it was hyperbole. But if it was it wasn't obvious to me, unfortunately.
Earlier quoted context omitted.
According to tokei, the lib/ directory from the reference implementation [0] has 93821 lines of C++ code and 22164 lines of "C Header" (which seems to be a mix of C++ headers, C headers, and headers that are compatible with both C and C++). The tools/ directory adds 16314 lines of C++ code and 1952 lines of "C Header". So at least if GP was talking about libjxl "100K+" would be more accurate. [0]: https://github.com/…
>> 100M+ is a bit more than i would expect for an image format. have i not been paying attention > So at least if GP was talking about libjxl "100K+" would be more accurate. M can mean thousands and I think it's common to use it used that way in finance and finance-adjacent areas: https://www.chicagomanualofstyle.org/qanda/data/faq/topics/A... : > A. You’ve identified two commonly used conventions in finance, one der…
Earlier quoted context omitted.
> WHATWG was created specifically because W3C wasn’t really listening to web authors though. Rather: WHATWG was founded because the companies developing browsers (in particular Google) believed that what the W3C was working on for XHTML 2.0 was too academic, and went into a different direction than their (i.e. in particular Google's) vision for the web.
Literally the WHATWG founders wanted to focus on web applications, which they said web authors were asking for, and they got voted down. Google was not involved in the founding of WHATWG, though certainly the WHATWG vision was better aligned with Google than with what the W3C was doing.
But that's not very relevant actually. The WHATWG is more like a private arbitrator, not like a court or parliament.
Their mission is to document browser features and coordinate them in such a way that implementation between browsers doesn't diverge too much. It's NOT their mission to decide which features will or will not be implemented or even to design new features. That's left to the browser vendors.
And the most powerful browser vendor is Google.