There's definitely some cool stuff here for sure, and I'm happy to see it getting better support.
CSS Nesting is a huge deal for example, since it's one of those features that kinda made SASS and LESS useful to begin with, and (like variables) was always better as a core CSS feature than a preprocessor one. Always super interested in seeing what can be done with custom properties too, since that feels like a lovely next step after things like Shadow DOM and custom elements.
And popover is surprisingly neat too. The fact you can do these popup modals and things without any JavaScript now is super useful, and something that should finally stop developers wasting time with custom modals, dropdown menus, hamburger buttons, etc.
But I do wish that forms got a bit more attention from projects like this. The current status of them (wildly inconsistent in different browsers for many HTML 5 era fields, reliant on proprietary pseudoclasses being styled for display purposes, things being difficult to customise in general) feels surprisingly archaic for a platform that can let you do seemingly anything.
UI designers that are allowed to roam free will often NOT want these new default modals, menus, buttons, etc. even if it was their jam pre-default. This will help, but consistency seems to be seen as a weakness in UI rather than a feature we should all strive for.
Consistency of style in the general sense is what designers wish to avoid. Consistency of browser behaviour and default style, on the other hand, is the grail from which creativity can flourish unbounded on the web.
Again, my point is that there will be requests for features that will still be beyond these new features such as needing Javascript. And again, these are great and useful advancements.
For example, the `@starting-style` allows for a starting value, but if the UI requires that it's conditional, then that's likely JS. It's toward the end of the article. You may not have gotten to it.
Safari has supported CSS nesting since 16.5. The only thing added in 17.2 is the ability to omit the & in some cases, which was a more recent change to the specification.
Looks like JPEG XL didn’t make it in the end. Kind of baffling, considering it’s the first image format bringing solid improvements across the board in a very long time. I was hoping Interop might finally be what forces Google to stop effectively blocking its adoption, but apparently we’ll have to keep waiting as the half-baked replacements for the ubiquitous old formats keep piling on.
AVIF hasn’t been around much longer than JXL, has it? Only a year or so.
Since both of them are image formats, I assume that by ‘video’ you refer to animated images, in which case yes, AVIF (being based on an actual video codec) seems to perform better. Same with very low-quality pictures.
For higher quality JPEG XL still seems to do better, and seems to do much better for lossless encoding. (AVIF struggles to even compete with WebP on that front, if I recall correctly.) Not to mention very useful features like progressive decoding, lossless JPEG recompression, or no practical limit on image size.
Yes, AVIF is a thing, but why? Is it worth missing out on an actual full-fledged replacement by refitting yet another video codec into an image one in a rush? That’s just like acting before thinking and then going on to say “oh well, what’s done is done”. And perhaps there’s nothing we can do about it, but it’s still irritating.
On web. Outside web the situation is more complex. iirc many camera manufacturers push HEIC, some editing software prefer JXL, and AVIF is kinda around too.
I only do some web stuff very casually, so I’m definitely not the target demographic. Having said that, the most glaring WebKit omission for me is lack of SVG favicon support. Really baffling. All those Apple-specific icons with the different dimensions- really a pain for a casual web dev like me.
Haha! Yes, I actually was aware of this specific case where an SVG favicon works. I suppose it was disingenuous of me to say it’s not supported altogether, but I’ve yet to have an opportunity to use it due to the 1-color restriction.
SVGs don't scale the way you want them to. You can't make a (for example) 256px square image, even a vector, look good at 24px just by vector transforms.
Plus anyone with a not-cheap-ass Windows / Linux laptop, and anyone who's bought a desktop monitor in the last several years. I can't remember the last time I had to use a screen that wasn't.
What's "not-cheap-ass"? The standard "developer spec" type laptops from Dell etc. seem to still come with 1080p screens despite costing upwards of 1k credits. If you search for 27" monitor on Amazon you'll find 1080p models coming up, maybe some QHD ones. I can't imagine many offices kitting out with 4K monitors unless they actually need them.
I suppose that makes sense for a professional web dev- but it still feels like an arbitrary feature gap and is the first ‘speed bump’ in standing up a simple website for safari. Just because your pixel-perfect corp might rather have specific image renders for all screen sizes doesn’t really explain why I can’t put a SVG in there and call it a day. I can’t imagine my svg-to-png converter does a much better job of it. It’s all just a hassle. Again, happy to recognize I’m not a front end expert and not the target demographic.
That's a valid reason for non-Apple browsers to prefer or even require raster (non-SVG) image files, such as a 16x16 favicon for a 96dpi display device like a typical office desktop or low-end laptop.
Whereas Safari only runs on macOS + iOS, which in-turn only runs on Apple hardware, and all Apple hardware today is going to run at ~140dpi or above - so pixel-perfect art just isn't required - and if someone plugs a (relatively) low-res TV into a Mac then the OS is going to downsample everything down anyway, and (most) users don't seem to care about that.
They scale well in the sense that they display the same thing at different sizes without loss of quality. But that’s not the only thing that matters. The primary goal of an icon is legibility.
A large text editor icon might have a pad with a pencil, squiggles on the page, rings binding the pages at the top, etc. But if you scale that down, it might lose legibility.
For good icon design, you don’t want the same thing but smaller, you want fewer, simpler elements. So you might drop the rings at the top, then as you get smaller you might drop the squiggles on the page, and if you go small enough, you might want to change to just having the pencil.
Most people don’t bother with this. They just shrink things down. If that’s what you do, then SVG solves that problem. But that’s not great icon design. Great icon design needs to adapt to smaller sizes, not just grow and shrink.
Unfortunately, I tried the demo and even though it’s supposed to work in Chrome, it didn’t for me. Nor with Safari. Have you gotten it working with favicons anywhere?
There is this "Open UI" W3C effort which is supposed to be moving forward styling Select elements. Improved <select> is flagged in Chrome at the moment - it'll be great if this (and the other stuff in Open UI) actually get ratified into standards and ship. https://open-ui.org/components/selectlist/
Historically interop seems to have been focused more on CSS, but that's changed more and more. Even still many of the test areas include tests for workers, ensuring that the state of PWAs will also improve. And in 2023 they had an entire Modules section which heavily tested PWA/worker-specific functionality. Additionally, many of the APIs tested and investigated like OffscreenCanvas and mobile testing are very relevant to many PWA applications.
This year, like the year before, is the least CSS-centric interop. With sections for IndexedDB (which I've only ever seen relied on by PWAs) and Websockets and important accessibility improvements. And the 3 investigation areas (WebAssembly, Accessibility, and Mobile testing) are all very relevant to PWAs.
What (other?) specific APIs are you interested in them focusing on?
Both of those websites include APIs that were implemented unilaterally by Google, while both Mozilla and Apple rejected them – mostly on privacy and security grounds. They aren’t a part of the web platform and aren’t on any standards track, they are Google APIs.
The web platform is not defined as “whatever Google chooses to implement”. It’s a collaborative effort.
All of those browsers use Blink, Google’s rendering engine. It’s one single implementation. Something needs two independent implementations to become a web standard. If you look at the specifications, they will explicitly state that they aren’t standards.
An interoperability project isn’t going to consider working on things that have been explicitly rejected by every implementer but one. That’s not how interoperability happens.
Google need to go back to their specifications and resolve all the security and privacy problems with them so that they can convince at least one other rendering engine to implement them. If they can't do that, there’s no chance they are candidates for interoperability work.
From what I remember, the consortium is maybe a dozen people? And these people also work for the browsers. The goal is to come together and find features that they all can work on or improve over a year, taking into account current roadmaps and workloads. Think of interop like the small extra tickets you can work on in between the main feature development at your day job.
Right now the focus has been very low level details about how browsers render content. These are the biggest areas for improvement as the JavaScript APIs are largely standardized and merged in from “upstream”.
I suspect we will continue to see more work done to patch holes between browsers, before we see a push to simultaneously implement new features across all engines at once.
That said, with Apple finally adding webpush to mobile Safari, we’re getting a lot closer to covering the needs of the vast majority of web apps that would benefit from PWA features. What sort of features are you wanting to take advantage of that are not present cross browser yet?
You link to https://web.dev/learn/pwa/capabilities and https://whatpwacando.today elsewhere, but I think many would consider many of those features to not be inherently PWA features. Many, _many_, of those features have wide usage outside of PWAs, which makes putting them into a "PWA" bucket somewhat meaningless. Constructing buckets like "Storage" or "Media" would probably be more meaningful to web developers.
If you look at the basic definition of PWAs, it's primarily about manifests and service workers, and about using the web platform in combination with these.
Manifests are hard to test automatically — their content is largely shown in differing parts of browser UI, and UI is by-and-large unspecified in web standards (because vendors want freedom to make their own UI decisions) — which makes including them difficult. It's also unclear how much there is in way of interoperability problems.
Service workers are definitely something that could be proposed (though haven't been in recent years); I again don't believe there's been that much in way of interoperability problems there recently.
One of the focus areas for this year is IndexedDB. And many of the other areas contain tests for service workers. I don't think it's accurate to say anyone's dragging their feet. Apple's done a 180 on PWAs in the past year. I also don't know what you mean about Firefox dropping pwa support. They've been hard at work improving the PWA scene for years now. And they're docs are the go-to for anyone working on one
In what way has Firefox dropped PWA support? They continue to support all the major APIs relevant to PWAs. Which you can see a thorough list of on Mozilla's MDN docs here:
It's a problem for both because by tying browser updates to OS releases, you lower adoption, since some people avoid system updates or delay them.
And it's more of a problem for iOS because all browsers have to use system-issued WebKit, and previous releases only receive updates for vulnerabilities that Apple knows are being actively exploited in the wild, not for all vulnerabilities (as if Apple was omniscient and knew for certain what's being actively exploited), and not for features/API/webcompat updates. If there was an IndexedDB bug, you're not getting a fix unless you're on the latest iOS. Meanwhile Android 8.0 Oreo gets the latest Chrome with all bug fixes, new CSS features, etc.
Apple is actively screwing users and webdevs by tying browser and OS updates, and by restricting alternate iOS browser engines outside the EU.
> Meanwhile Android 8.0 Oreo gets the latest Chrome with all bug fixes, new CSS features, etc.
That’s only necessary because of the abysmal upgrade rates for Android. iOS is very different. People upgrade quickly. >70% have upgraded to iOS 17 since it was released in September. >22% are on the previous release. <8% are using something older.
> That’s only necessary because of the abysmal upgrade rates for Android
So what. 30% of iOS users aren't updating for whatever reason (phone too old, or they don't want their phone to slow down), so they have an outdated WebKit with known vulnerabilities. 95% of Android users have the latest Chrome. 99%+ can have the latest Firefox (Android 5.0 minimum). There's no benefit to Apple's rigidness.
> 30% of iOS users aren't updating for whatever reason
That is not what the figures show. The figures show that over 90% of iOS users are upgrading. I believe you’ve mistaken are not on the latest version with aren’t upgrading. Those 22% are upgrading, it just takes them 12–24 months to do so.
> so they have an outdated WebKit with known vulnerabilities.
This is not true. Apple pushes security updates for old versions and includes a setting so that phones can auto-apply security patches even if the user doesn’t want to do a full upgrade to the latest version automatically.
Only people on the latest version get the latest Safari, that's the relevant number.
And I already addressed older versions. They get updates but only for vulnerabilities that Apple "is aware" are being exploited in the wild, not all vulnerabilities Apple has fixed in the newest version (yet Apple isn't omniscient about what gets used in the wild). And no updates for rendering bugs, as far as I'm aware.
In practice it is a problem if your device stops getting iOS updates but you would like to continue using it for web browsing.
Old example, my iPad3 was working perfectly fine as a casual web browser until the day iOS updates stopped just as javascript ES6 spread around the web. Developers everywhere replacing "var" with "let" (Steam website for example). iOS Safari on iPad3 suddenly stopped rendering Steam pages, which up until that day I enjoyed browsing from my couch with the only tablet I owned at the time.
I'm curious whether this is any indication that WebKit is going to start catching up on WebAssembly features: they're currently pretty far behind both Chrome and Firefox, lacking big important ones like multiple memories and garbage collection.
Both of those are in standardization, not yet part of the Wasm spec. Google has more of a "Ready! Fire! Aim! Fire again!" approach and is more readily amenable to releasing implementations of unfinished specs, where Apple has more of a "Ready! Aim! Aim! Fire!" approach and is generally reluctant to do that. (I can't speak for Firefox.)
There's definitely a late adopter/early adopter divide here.
I have found myself wondering what good examples there are of successful (Ready Fire Aim) early-draft-standard adoption on the web. CSS in early Internet Explorer is one of them -- that was a choice that ended a ridiculous, unworkable not-invented-here adventure at Netscape.
But on the flip side, I am reminded of (Google) Gears, which was promoted as a solution but was really only a technology demonstrator for the idea that ultimately surfaced as Web Workers.
I wouldn’t use CSS in early Internet Explorer as a good example. There were quite a few cases where they shipped something prematurely based off an early draft, then the final spec. changed, making Internet Explorer incompatible with the standards and other browsers. That’s how the box model ended up the way that it did, for example. The draft was originally border-box behaviour, Internet Explorer implemented it too soon, then the specification changed to content-box behaviour and all the other browsers implemented it.
Yes. But bad box model is nothing -- absolutely nothing -- compared to where we would be if JSSS had become a de facto standard. It was a total mess, and an arrogant one at that.
I agree that JSSS was a poor choice, but Internet Explorer tried sneaking JScript into CSS in a few different ways, which wasn’t great for security or interoperability.
I don't understand the websocket protocol issue. The connection is not the http(s) protocol beyond the upgrade - allowing the use of http or https here is misleading, no? Is using a turnary or having a value other than what the current page is navigated to so terrible? I'm glad their doing this work at normalizing the browsers. I just find that one a bit low priority if it merits a change at all.
What’s more interesting is how bad Safari fails these tests (and how Firefox is on a negative trend the last few years) … which saddens me given Safari is my primary browser.
I have a gripe with those tests because they include a bunch of non-standard APIs whose status is literally "not on any standard track" (e.g. Background Fetch) and many of whom are opposed by both Safari and Firefox (e.g. WebHID, WebUSB)
Surprised to see no mention of WebGPU here. Sucks to see Apple falling behind on what could drive a lot of potential use cases around WebLLM, on-device cryptography etc.
I proposed WebXR, the rejection reason they gave was they "lacked testing infrastructure." While the WPT tests are run with a mocked XR device, I can maybe understand if they figured they would have to have physical devices to test real-world performance also.
I know that their developer evangelist is earnestly doing all that can and I applaud them for that, but I'd love to know what internal Apple politics around web standards made them focus so much on CSS and a few quality of life things, but completely ignores what developers have been clamoring for in many respects.
The popover support is nice, and I like the new CSS stuff, and focus on making Pointer Events and Mouse Events more consistent is a big win, however
- Most (all?) of these was work that was being done by the Safari team to support anyway
- There is no explanation about why these were chosen over other items
- They're still refusing to look at what developers have been clamoring for and I know most of these things are not on the top of the list of every day developers. Things like the Origin Private FileSystem, Trusted Types, URLPattern, Import Assertions, JSON Module scripts and a host of other things that would really benefit day to day developers in greater numbers are completely ignored
I feel like Interop is a superficial thing, because these are all things that were going to be implemented anyway and aren't the things that developers have been pounding the door over for years prior (except maybe the CSS nesting stuff, lots of people want to ditch sass and that was one of the last things keeping it around for alot of people)
Overall while I appreciate these features, I'm not terribly impressed, it doesn't really solve my day to day concerns in any meaningful way, sans the `popover` attribute (which will take time to roll out across the industry anyway, regardless of browser support).
As much as I hate the chromium engine monopoly, Apple resists standards with little explanation way too often, and doesn't bother introducing alternatives when they do.
Safari’s had that for more than two years. (Chromium, more than three, Firefox, almost one.)
> Import Assertions
An excellent example of why Firefox and Safari tend to be more reserved in what they ship, in contrast to Chromium which is much more fond of shipping immature stuff.
Import assertions are dead, superseded by import attributes. V8 has deprecated import assertions and will remove them soon. See https://v8.dev/features/import-assertions for more info on why.
Chromium shipping immature stuff is, from time to time, a real pain, because it makes it harder to fix problems in the spec as you sometimes have to avoid breaking real usage. Sometimes this basically makes things worse forever, because of naming things. I can’t remember a specific case in browsers, but know they exist; but a similar case is how we have some methods named includes instead of contains like they should have been because of Mootools touching stuff it shouldn’t have, and so now everyone suffers for that mistake.
> V8 shipped the import assertions feature in v9.1. This feature allowed module import statements to include additional information by using the assert keyword. This additional information is currently used to import JSON and CSS modules inside JavaScript modules.
> Since then, import assertions has evolved into import attributes. The point of the feature remains the same: to allow module import statements to include additional information.
> The most important difference is that import assertions had assert-only semantics, while import attributes has more relaxed semantics. Assert-only semantics means that the additional information has no effect on how a module is loaded, only on whether it is loaded.
NB: The above quotes have been edited to just the most relevant notes. See the link above for more information.
Question that is both on and off topic. Is the Origin Private FileSystem permanent on Safari?
Apple released an update a few years ago the cleared the contents of localStorage and indexeddb for an origin if the user hadn't visited in 14 days.
This makes it hard for purely offline PWAs to store data offline.
e.g. I wrote an offline only exercise tracker PWA (akin to "Strong" on Android) that used indexeddb to keep records and required no account. The 14 day policy makes it basically DOA for iOS clients.
It kind of makes sense, given the constraints the browser devs have given themselves. Since there's no way for users to see/manage these OPFS files directly, there is no good alternative except automatically deleting stuff if disk space is low.
What would really be nice would be if we could just create normal files and let users control them, but that doesn't seem to be in the cards. And it sucks. The #1 question I get for my PWA is "how do I stop it from sometimes deleting all my data?" and there's really no good answer.
> no good alternative except automatically deleting stuff if disk space is low
The good alternative is to use navigator.storage.persist(), which requests the user for permission to use persistent storage.
Unlike other browsers, WebKit/Safari ignores this. Instead of asking the user for permission, it automatically grants or refuses permission based on website heuristics.
That is definitely not a good alternative. Three major problems I've had with it:
1. That heuristic is not just in Safari, it's in Chrome too. Firefox is the only one with a normal permission dialog. And the heuristic is really confusing for users! They come to me and say "how can I stop my data from being deleted?" and I have no answer if the heuristic says they can't enable persistent storage.
2. It only helps with eviction (deleting data due to low disk space), not other scenarios where data may be deleted. Such as clearing the "browser cache" without realizing what that implies, which may even be done automatically or through some third party app.
3. I have a place in my app settings page where users can see their persistent storage setting and also enable it if they want. I have many reports of users who enable it, then check back some time later, and somehow it's disabled. So the persistent data setting seems to not be persistent.
I've been working on a local-first web app, and ran into some of the same issues. Good to learn about these other pain points..
All of these make the so-called "persistent" local storage unreliable and impractical. I don't understand how browser vendors expect people to use such a feature where the data can be deleted at any time, where neither the developer nor the user has any control over how that happens.
I don't think there is a real plan, I think it's just the current state of the power struggle between two competing factions. Some browser devs prioritize web apps being as good as native apps. And some browser devs prioritize not causing problems for users (such as using too many resources). Seems like sometimes one faction sneaks something past the other to advance their cause a bit, and in total the result is incoherent.
Yes, but they are both symptoms of the same problem. Ultimately as a PWA developer I'd love to just be able to save a file to disk and be able to rely on it the same as a native app can.
And currently there are also other situations where browsers will delete your data, in addition to low disk space and the weird iOS usage requirements.
Yes, but that is also the difference between it being used as a replacement for tracking cookies. There’s a reason why every browser not made by an ad network is more concerned about privacy.
How would it be used as a replacement for tracking cookies? The data is only accessible from a single origin (hence the name Origin private file system).
This feature can actually benefit privacy, because it allows creating web apps that don't have to send data back to a server to store it.
It’s a potential long-term persistent identifier. Safari already deletes first-party cookies from sites you don’t regularly access so they need to review any other storage mechanism to ensure it doesn’t turn into a replacement with different policies. That’s also why they have a different policy for a PWA, where the user has expressed a stronger intention to use that site regularly.
In this case, they implemented it following the same storage standard for everything to avoid inconsistencies.
> This feature can actually benefit privacy, because it allows creating web apps that don't have to send data back to a server to store it.
It’s more convenient in some cases than the other APIs for doing that, but it’s held to the same privacy policies. If you want persistent storage, you have to ask the user for it.
This is another instance where Apple threw up their rails, and Firefox also seized the opportunity to throw up some rails. I don't think all their concerns were justified because you can control with very fine permissions what is and isn't exposed to the browser, which was the main source of contention.
No alternative was presented. I believe this can be done in a privacy friendly way (the main stay of the objections). These are smart engineers, some of the best and the brightest, who supposedly are good at solving thorny problems. Simply, I think Apple didn't want to do it because it was remotely threatening to their iOS App Store and I wonder if some kind of anti-trust litigation may eventually expose their leadership around webkit like this. Then we'll know once and for all if its a grand conspiracy or not, I suppose
Because for every one PWA app there are dozens of websites who would use the local storage to store re-targeting metadata for advertising.
It has nothing to do with the App Store and everything to do with basic tracking prevention. You can't block cookies and then allow local storage. Developers aren't stupid.
Exactly, requiring installation for long term persistence mitigates usage of the API for tracking and prevents storage usage from slowly snowballing over time as sites store random things the user probably doesn’t even care about.
Should PWA installation be more obvious/straightforward than it is currently? Sure, but that’s a separate issue.
Now we're getting into the fundamental fact that some websites have lots of tracking and such, and some don't.
This is no different than having to send the files to a server owned by the website. I fail to see any meaningful difference here. Should we also not allow HTTP requests? I don't see how this is different.
Storing data with user permissions, not permission-less. Its in no way like local storage or indexdb. Those permissions could be scoped to only allowing explict read/write of certain files (IE, the ones the user initiated) and not allow for arbitrary writing of files to the filesystem, for instance.
In order for a specification to become a web standard, it needs two independent implementations. No single organisation is capable of blocking it – it means that Google couldn’t convince anybody outside of Google to implement it.
> I think Apple didn't want to do it because it was remotely threatening to their iOS App Store and I wonder if some kind of anti-trust litigation may eventually expose their leadership around webkit like this
What actually happened: Mozilla rejected it on security grounds, then Apple agreed with Mozilla. How are you blaming Apple for Google putting together a bad spec. that no other browser vendor can accept?
This happens time and time again. Google publish a specification that is not acceptable, both Mozilla and Apple reject it on privacy or security grounds, Google ships it in Chrome anyway, then people like you complain about Apple being mean.
Idk what happened to it but there was momentum at one point to ship internal modules for browsers like node now has, where you would write the import as “std:lib” (much like the recent “node:fs” etc) which would completely side step these issues
I'm really confused because the import assertions link doesn't say that they're deprecated at all, let alone why. (It's also possible I'm being served something different than you were because I'm on mobile?)
Import Assertions being replaced, thats cool (its replacement perhaps should have made the list if the spec is done)
but OPFS is not widely supported. Its partially supported. Its not on the same interoperable standard as Chrome, for instance. hence for Interop 2024 it would have made sense to include, to close the gaps between the browsers.
I wouldn't really say that I've missed much any of what you've described in my day-to-day work, so it's hard to take this criticism seriously. Meanwhile the things listen in TFA have real practical use cases pretty much across the whole web. Why are those specific items so important to you?
Because they move the frontier of PWAs forward in a big way. They aren't simply quality of life improvements, which the vast majority of these things are (sans the popover attribute, which will make a host of things easier once browser versions are sufficiently updated past the point of worrying about using it or not)
I want to be able to persist to the filesystem of the user, for instance, because the software we make is all about editing files, and currently, the user has to upload their files to us and crucially we then have to store them on a server. I'd like to remove that server requirement, for a multitude of reasons, and be able to have read / write permissions to a sandbox directory that lets me do just that.
Not everyone is making apps that benefit from this, but the ones that do, really do and they tend to be big. Our app has 400K+ users for instance
>I'd love to know what internal Apple politics around web standards made them focus so much on CSS and a few quality of life things, but completely ignores what developers have been clamoring for in many respects.
Is this not just completely on-brand for Apple? Focusing on the sizzle and not the steak?
Ha what. Developers clamor for things that solve actually day-to-day problems like sticky and has, which Safari led the pack on. Not to mention subgrid, color functions, filters, etc.
> Not to mention subgrid, color functions, filters, etc.
Firefox led both subgrid and filters.
Color functions seems a bit weird to bring up since back then Apple were the only ones using higher gamut displays making the color functions useless for everyone but them, while also doing their best to hamper the web making the color functions useless for everyone including them.
To add some context on the rest of the industry... everyone else focused their improvement efforts not on deeper color bit-depth, but on improved framerates to reduce eye-strain, flicker issues and latency discomfort.
It's only going to be over the next few years as QLED/MicroLed/etc... displays get cheap enough to be commercially viable that the color functions (relative color possibly excluded) will start to become useful.
I don't really count Apple's current displays since they have been pasting multiple displays together to try and get desktop resolutions to the detriment of frame rate (which from a health perspective is much more important).
> Color functions seems a bit weird to bring up since back then Apple were the only ones using higher gamut displays making the color functions useless for everyone but them, while also doing their best to hamper the web making the color functions useless for everyone including them.
Totally false.
In Apple's blog post "Wide Gamut Color in CSS with Display-P3" (posted March 2, 2020), Apple includes the fact that non-Apple devices shipped with wide gamut displays:
- Google Pixel 2 XL
- Google Pixel 3
- HTC U11+
- OnePlus 6
They even provided a Wikipedia link [2] that links to an article with addition devices.
The hardware wasn't the issue; Chrome and the other browsers that ran on Android back then didn't support wide gamut displays. That's not Apple's fault; they were going out of their way to promote wide gamut/Display P3 as something good for the web.
Finally, Safari/WebKit has wide gamut support starting in 2016 [3] by implementing web standards that Google, Mozilla, etc. have access to.
The mobile displays we've received in the last few mobile generations have had wider-gamut displays than the displays that came before... but, I wouldn't necessarily call them wide-gamut.
To call it wide-gamut (without a slight wince while doing so), we'd need:
- 1000 nit brightness minimum (some are here and above)
- 99.99% P3 color conformity minimum (although if we're moving color spaces, why not reach for Rec2020)
- No dimming issues (if you've ever tried using a white mouse cursor on a black display, you know how annoying the lighting smear around it can be)
Right now, displays can support those different points and surpass them, but very very few can do all three at the same time.
There are miniLED displays that can support all three, but there's other issues that can pop up that can make them not worth it (e.g. viewing angle, and sometimes still weird dimming).
Then there's the newer microLED displays which avoid those problems, but there's still some production issues.
We're really close to the wide-gamut age, but I still think we need two things before we can cross that threshold and truely say we're in the wide-gamut age.
1. microLED becomes cheap enough to be the norm
2. iOS, and Android remove their "feature" where they oversaturate photos to simulate wide-gamut.
Safari has been absolutely crushing things in terms of standards and general shipping velocity for nearing on 3 years now. Your comment would be 100% true 3 years ago, but today is basically completely incorrect. A sibling comments corrects some of it, but needless to say the endless FUD around this is bad.
Safari is an incredible browser - standards wise - but also way faster and more efficient than Chrome.
I use it for everything except the dev tools and switching to Chrome always feels like I'm using a gas car vs electric - clunky, slower, heavier.
They have done a ton on the CSS side in particular, I agree with that, and its in a better place than it was 3 years ago, no doubt about that either.
My point still stands on interop though: They aren't picking anything where the interop is divergent and tricky for developers to navigate, and most of this was on their roadmap as going to implement soon anyway. They aren't tackling any thorny issues like OPFS, which is where developers want them to figure out interoperability for consistency because it moves the entire platform forward in big meaningful ways (for instance, makes PWAs more potent alternatives to native apps)
I applaud their CSS and HTML work though, that's been nice to see.
> makes PWAs more potent alternatives to native apps
You will need to be specific about what missing API will magically make this true.
Because all I see people on here ask for are things like MIDI support which are nice and all but have been used by companies to track you. Which is why Google who is fully supportive of this has no issues adding it in without any thought to privacy.
Filesystem persistence removes a whole host of complexities from applications
For instance, I would no longer have to store files on a server, I could simply save them locally for the user, which makes it easier for them to have portable files, use it with other apps etc.
It also reduces the startup cost of some apps. If for instance I wanted to make a photo editing app, its going to be cheaper to store edited photos back onto the users device, than it is for me to upload them to a server and store them, especially over time.
It removes alot of developer overhead and it has benefits for the user (IE, the files are more portable, since they're on your machine, not someone elses).
Currently we are perpetually stuck with having to re-create virtual representations of file systems and they aren't the same thing, not by a long shot.
Not by default. It’s not inherent to it at all. I’m honestly not sure how it does, given the idea would be to restrict FS access to only files the user grants permissions to read / write, so they can’t write arbitrary things to the file system. There’s other techniques they can use to make it blind / privacy focused as well
When you ask people about "what PWA standards are you talking about" people inevitably bring up Chrome's half-baked non-standards half of which both Safari and Firefox are in opposition to.
WebMIDI is just one such example. Safari and Firefox were against it. Then Firefox relented and implemented it, and ran into tracking literally the day after they released it.
Others are WebUSB, WebHID, WebSerial etc.
It's refreshing to see people discussing something else like Origin Private Filesystem for a change.
It is Apple throwing up objections to focusing on other things as far as interop goes though. They have alot of weight in the discussion at hand.
I know Google throws some up too (JPEG XL much) but Apple is somewhat notorious for this.
I should also mention, there was an episode of the ShopTalk Show podcast where their developer evangelist was pushing for most of the things in this list when talking about Interop, which makes me believe they had their minds pretty well decided going into the whole thing.
Whenever I see people complain about this, it always seems to be specs. that aren’t on the standards track. Which basically means that it’s a spec. that Google wrote and both Mozilla and Apple rejected.
It takes only two independent implementations to make something a standard. If it’s not on the standards track, it means Google couldn’t convince anybody else to implement it.
This is not Apple throwing up objections. This is Google trying to push bad stuff unilaterally and nobody else going along with it.
Safari has supported OPFS for some time. But Interop isn’t mainly a “please implement this” list, it’s a list of priority areas for browsers to become consistent with each other and with standards. If you think there’s a problematic lack of cross-browser consistency for OPFS, then definitely nominate it as a focus area for Interop 2025. Anyone is welcome to propose work items.
> but I'd love to know what internal Apple politics around web standards made them focus so much on CSS and a few quality of life things, but completely ignores what developers have been clamoring for in many respects.
This is stuff that developers are clamoring for, but maybe just different developers than you.
(-webkit-)backdrop-filter was such a godsend, and a massive pain that it took so long to go through the standards process after Apple was shipping it fine. Even then Google's implementation was still pretty buggy for a while.
CSS Scroll Snap is great, removing the need for weirdo javascript carousels, giving more native scrolling experiences on the web.
The ironic part is that despite the criticism, I think capabiltiies make websites feel more 'native' than JSON Module Scripts. My impression is the Apple focuses on web APIs that impact the user experience, which generally leans more on the CSS side.
Don’t get me wrong I appreciate all of this, but this is Interop, not just shipping standards and I want them to focus on the thorniest problems possible
It's obvious that Apple's incentives around developing more standards (that make PWAs more potent) directly conflict with their walled garden (AppStore) revenues.
In this regard, they are remarkably similar to Microsoft's Internet Explorer situation, only in this case there seems to be little to no interest in pursuing an investigation.
Browser vendors collaborating to mitigate a problem they created by shoving more and more complexity into web standards, resulting in a huge moat when it comes to implementing a browser engine.
This complexity moat is what gives Google control over things like Widevine to force you to watch ads, and Apple control over things like slowing down PWA adoption to force developers to use their app store.
Not saying this is evil, just companies following profit incentives as intended. But it often results in worse outcomes for users.
I would love to see some sort of reboot of the web with simple protocols and real experimentation happening in browsers again.
It is not the complexity of WWW that give you Widevine.
It is the need, or the greed, to monetise every view of your screen that give birth of Widevine. [0] This is because DRM is already applied to IPTV way before company start streaming video over the internet.
Also Widevine doesn't force you to watch ad. Last check Youtube is not doing server side ad insertion yet. meaning even if the main content is DRM protected, the AD is not part of the main content (and protected), and so it is technically possible to download the main content and stitch them back together without the ad.
I agree, but nevertheless Gemini is much better than WWW is many ways.
However, different people (including myself) have different ideas about what it should and shouldn't be.
My idea is that the WWW has way too much messy, bad stuff, complexity, etc; however, there are also some stuff that WWW does not have even though it might be good to do.
(Therefore I made up Scorpion protocol and file format, according to my own criticism of Gemini protocol. There is also Spartan, that someone else did, but I have some criticism of that, too (e.g. why is a user name and password allowed in the URL even though they are not used?).)
(Therefore I made up Scorpion protocol and file format, according to my own criticism of Gemini protocol. There is also Spartan, that someone else did, but I have some criticism of that, too (e.g. why is a user name and password allowed in the URL even though they are not used?).)
I would love to see some sort of reboot of the web with simple protocols and real experimentation happening in browsers again.
A lot of the web is still usable in text-based and simple HTML browsers. The problem is convincing brainwashed developers to NOT adopt the latest trendy features that invariably are only available in Big Browser (and sometimes Firefox.)
Right, they will never stop, there will never be a ceiling at which any browser vendor says "okay this is good, let's just stabilize at this point and refine what we have". There will always be the endless thirst for greater abstraction, deeper access to host hardware/peripherals and I/O, and really just more ways to turn the web into a profitable software-delivery mechanism.
What's wrong with that? It's not like it's ever going to go back to a "web document" only delivery mechanism, so might as well make it very very good at doing what it is already used for
> and Apple control over things like slowing down PWA adoption to force developers to use their app store.
Wait.
You say "browsers have too many complex APIs, and this is bad" and then also "This browser has not enough complex APIs, and this is bad". It sounds like you would agree with Safari if they're creating less complexity into (shipping) web standards?
I didn't say whether I think PWA APIs are too complex. I actually didn't call out any APIs specifically. Not that those aren't important conversations and related to what I'm trying to say.
> Not saying this is evil, just companies following profit incentives as intended.
Love of money is the root of all evil.
> But it often results in worse outcomes for users.
"The sad fact of the matter is that people play politics with standards to gain commercial advantage, and the result is that end users suffer the consequences. This is the case with character encoding for computer systems, and it is even more the case with HDTV." Well, they forgot to mention WWW, too.
> I would love to see some sort of reboot of the web with simple protocols and real experimentation happening in browsers again.
Some people have working on alternative protocols and file formats (and sometimes, variants of existing ones or reusing older ones), including myself.
The newest version of the specification document is also accessible by the Scorpion protocol itself (currently TLS is not implemented on the server side): scorpion://zzo38computer.org/specification.txt
(Some of the other things other people have done are: Gemini, Spartan, and some others. Some of them (e.g. HYDIN, TerseNet) are not defined enough at this time, so it would be difficult to use them.) There are also other existing protocols, e.g. NNTP and IRC for communication between users, and Gopher for files and menus with hypertext.)
Of course, different people have different ideas, and different goals and criticisms (I have some of my own criticisms too, but many other people have other criticisms of Gemini and these other protocols/file-formats, some of which may be found on Hacker News). You are free to make criticisms of Scorpion (including if any part of the document is unclear, or if you think some part is good or is not good), too.
Actually, the repository there also does include a few other things; the "astroget" program (similar than curl) implements Scorpion protocol and also implements Gemini, Gopher, Spartan, NNTP, and HTTP (deliberately not implementing cookies and many other features of HTTP; if you need those features then you can use curl instead, anyways).
Yeah so interesting that with 96 focus areas proposed, scrollbar styling made it to the final set of 16.
Would be curious to know what 80 things were deemed less important than dinking with how scrollbars look. Maybe it was just an easier area to create a win? Maybe there are some benefits of styling a scrollbar that I'm not thinking about? Something that makes it a little easier to emulate native OS behaviors with web technologies, perhaps? Has this ever been a must-have feature on a project anyone has worked on?
> Has this ever been a must-have feature on a project anyone has worked on?
I have a highly interactive web app which simultaneously displays tens of panels each with it's own scrollbar. It's vital that they are thin and match the web app styling.
Good UX demands the correct distribution of visual weight. If a design requires many scrollbars, and those scrollbars have static styles, than those scrollbars dictate the visual weight of the rest of the app. This can make it impossible to design a nice intuitive UI around. So vital can definitely be an appropriate description for certain UIs
Normal width scrollbars use way too much space. This is a professional app with a complex dense UI, similar to ones used by image editors, music production software, 3d modelers. All of these use non-native controls, since native ones are too "wasteful"
This is the compromise - allow the scrollbar to be styled and in exchange developers don't implement their own scrollbars in javascript (as demanded by designers/managers)
The new scrollbar styling properties are actually pretty consistent with native platforms. There's not that much flexibility with them - e.g. you can't define width in pixels, you just chose between thick, thin, or none, which match the existing native controls:
> To add more information to this issue. This property supports three values, auto, thin and none. These match nicely to WebKit's ScrollbarControlSize::Regular and ScrollbarControlSize::Thin and not rendering the scrollbar.
That ship has long since sailed. The web is the preferred framework for creating "non-native" (maybe nomadic? colonizer? invasive?) apps that largely ignore their host platform in favor of being the same everywhere. For better and worse this is what developers and designers have always wanted out of portability.
It's also what I, as a user, want. I don't want some middle-man corporate "platform" (of which there are very few to actually select from to suit your personal tastes) inserting their vision of what UIs should look like into interactions between me and the service I'm connecting to. I want my platform to be as invisible as possible and interchangeable with other platforms. The more things stay the same when switching between platforms, the better.
It's also a lot easier to learn the 2-4 dominant UX paradigms of the dominant platforms than the hundreds we have now with everyone doing their own thing. Doing remote tech support for elderly relatives is hell when you can't even rely on a menu bar being present/useful.
This is a rather bad way of making portability. It is bad for accessibility (even though they tried to add things to improve accessibility, it does not work very well), for working on multiple types of computers (since, then the software specific to that computer cannot do so by itself, and instead needs to use the specification of the received file, which is probably wrong anyways), and for many types of features that may be helpful but that are unavailable or are not designed or implemented well. Furthermore, WWW is also, not work well with multiple programs and with user customization very well, pipes, etc. And, it is complicated to implement and does not run efficiently. And, there are many security issues, having to be made more complicated just to avoid some of them, in ways that would not be necessary if it were designed properly. And, anyways, it cannot be the same everywhere, even if they want it to be.
This is mostly a question of costs & availability of developers. There's simply not enough native developers on the market, and the good ones can ask very high salaries.
Hiring N teams of M developers for N native apps, compared to hiring K<<M web developers is way more expensive, difficult, and slow.
Or seriously, working on software ecosystem preservation just to preserve it it is absurd. Things get replaced because people want, and at this point you are just trying to force people to use things they against their wishes.
If it wasn’t fore scrollbar styling, developers would just roll their own. And even if developers would be aware of how terrible it is, designers would still design it, and project managers would still demand it.
Even native scrolling is not without issues. If you have horizontal scrolling on a flex container with `flex-direction: row-reverse` the native scrollbar won’t work in Safari. So developers implementing a list which flows from the inline end to the start, are faced with two bad options. Either implement your custom scrollbar or reverse your list items before rendering to the page and set the scroll position everytime the list updates in JavaScript.
This. "How difficult would it be to write a custom implementation of scrollbar in JavaScript?" (whose performance would be 100x slower than native browser scrolling, but who cares, we all have Macbook Pros, right?)
The most offensive part is that the width is configurable. This gives try-hard designers more of an excuse to hijack and fuck up scrollbars.
The colours I don’t mind so much. Ideally all this would be a simple checkbox to toggle on right click of the scrollbar, but that gives the user choice which is almost a foreign concept in some circles.
I would agree but only for the main page scrollbar, but you can have app widgets like dropdowons, listboxes, grids that need to customize it's look like in PRO GUI toolkits.
Although some browsers might allow you to disable CSS, this can also cause problems with some files. One thing is that some implementations of form fields will not work at all with CSS disabled. One alternative would be a mode to use ARIA for styling instead of CSS. If the web page uses ARIA to denote the custom form fields and other stuff, then this might work; however, I do not know of any implementation that is capable of using ARIA for such a purpose (usually they use ARIA only for people with disabilities, but it could be useful for anyone, I think).
Yes, yes I definitely would apply this to others. Sick and tired of web developers and "designers" killing any usability and accessibility in those controls.
For those downvoting: Just as an example here's Google's Material "designers" doing a study with 800 people to figure out that yes, text fields must look like text fields, and learning literally nothing from it: https://medium.com/google-design/the-evolution-of-material-d...
As a bigger example: almost every single CSS framework decides that color and contrast are for suckers and makes many controls (and especially text inputs) with barely visible gray-on-gray colors.
Although appropriate enough, Interop is still a somewhat odd choice of name. Interop was a very venerable (1980s vintage) show that was originally focused on networking. As I recall, it sort of petered out during dot-bomb, recovered a bit, but I think closed up shop during the pandemic.
I didn't know it had apparently shutdown, so my reaction was a bit more "Really, that's still going?"
I went once or twice last decade when I was attending a lot of events and it seemed pretty unfocused and mostly memorable because it had a lot of history and I had never been. Don't remember what I spoke about but it was certainly not networking.
CSS Nesting is a huge deal for example, since it's one of those features that kinda made SASS and LESS useful to begin with, and (like variables) was always better as a core CSS feature than a preprocessor one. Always super interested in seeing what can be done with custom properties too, since that feels like a lovely next step after things like Shadow DOM and custom elements.
And popover is surprisingly neat too. The fact you can do these popup modals and things without any JavaScript now is super useful, and something that should finally stop developers wasting time with custom modals, dropdown menus, hamburger buttons, etc.
But I do wish that forms got a bit more attention from projects like this. The current status of them (wildly inconsistent in different browsers for many HTML 5 era fields, reliant on proprietary pseudoclasses being styled for display purposes, things being difficult to customise in general) feels surprisingly archaic for a platform that can let you do seemingly anything.