The web just gets better with Interop 2024
webkit.org
webkit.org
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.
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.
Once Safari 17.2+ gains more traction, I can use straight CSS :)
---
*That, and variables for @media query. But that's a less common need.
I don't know what Google's problem is with JPEG XL.
And is comparable for images and superior for video.
Might be slightly encouraged to pick the image format that matches a video codec that's already widely supported by hardware IP.
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.
For better or worse, it has much higher adoption. JPEG XL is supported by Safari, and.....well no that's it.
Not really true. Firefox still clamps all colors to sRGB before sending color to device. https://bugzilla.mozilla.org/show_bug.cgi?id=1626624#c16
Also, nothing's really stopping most developers from just scaling it naively to those tiny sizes, in fact it's what commonly happens.
I agree we should keep support for custom icons for each size, and it's probably a best practice, but shouldn't be a _requirement_ anymore.
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.
Pixeling editing is a <4% improvement.
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.
https://web.dev/articles/building/an-adaptive-favicon
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?
I also wish we could style <select> lists. Like adding flags to <option> elements.
No mention of CSS page transitions or scroll-driven animations which can also remove some boilerplate JS.
<link rel="mask-icon" href="/favicon.svg" color="#990000">
You'll be glad to know you it's not like that anymore; you just need one Apple-specific icon now [1]:
<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="icon" href="/icon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png"><!-- 180×180 -->
<link rel="manifest" href="/manifest.webmanifest">
Why do we think there isn't a PWA focus area from the participating consortium?
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?
https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
"On desktop:
Firefox and Safari do not support installing PWAs on any desktop operating systems."It's in their best interest to drag their feet on the issue and ensure that the pwa experience is disincentivised.
As for Firefox dropping pwa support I'm just not sure. It's probably maintenance cost.
I keep seeing people make this claim. But what does that even mean? PWAs absolutely work on Firefox. What specific API was dropped?
https://wpt.fyi/results/IndexedDB?label=master&label=experim...
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?
If a future Interop were to do this, I'd assume they'd define something like "profiles" of PWA capabilities (e.g. "Minimal" and "Extended") using lists like the ones at https://web.dev/learn/pwa/capabilities and https://whatpwacando.today/ for inspiration.
They are absolutely part of the web platform.
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.
Because most PWA work is Chrome's non-standards they push out with complete disregard to any and all objections from both Safari and Firefox?
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.
I really wish more effort was put into CSS typography.
In particular:
leading-trim
margin-trim
https://medium.com/microsoft-design/leading-trim-the-future-...
https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim
leading-trim—the new name is text-box-trim—is behind a flag in the latest Safari.
[1]: https://webkit.org/blog/13966/webkit-features-in-safari-16-4...
Right now, no other browsers support those features.
Just not on iOS.
And given that there’s a new iOS update every 3-4 months, it’s not a problem for iOS in practice.
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.
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.
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.
https://mixpanel.com/trends/#report/ios_17/from_date:-3,repo...
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.
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.
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.
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.
How can it be 2024 and we're still having to parse a huge ugly string to get a cookie by name?
https://wpt.fyi/results/?label=experimental&label=master&ali...
Last i checked TeX/LaTeX did a lot better.
I don't so much mind showing a ­ in a title/headline - but it gets really tedious and error prone for body text...
See also:
The more honest name would be FixUpOp, surely.
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.
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.
That page actually explains the change:
> 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.
Is the OPFS a viable alternative?
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.
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.
In this case, they implemented it following the same storage standard for everything to avoid inconsistencies.
https://storage.spec.whatwg.org/
> 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.
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.
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.
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.
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.
https://developer.chrome.com/docs/capabilities/web-apis/file...
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.
They should have put out a counter proposal. They certainly didn’t show it’s technically infeasible
So the origin is the one storing the tracking data, capturing it and sending it to Meta etc.
Which is what makes this so hard as there is no difference between a PWA and a rogue website.
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.
If you allow PWA apps to do this. You also allow websites to use it for tracking.
Hence why Apple restricted this feature.
We already do this with the file upload API
Should PWA installation be more obvious/straightforward than it is currently? Sure, but that’s a separate issue.
[1]: https://wicg.github.io/file-system-access/#privacy-considera...
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.
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.
Here is Mozilla’s position: https://github.com/mozilla/standards-positions/issues/154
Here is Apple’s position: https://github.com/WebKit/standards-positions/issues/28
> This makes it hard for purely offline PWAs to store data offline.
That restriction doesn’t apply to installed PWAs, only websites.
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.
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.
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.
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.
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.
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.
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.
Is this not just completely on-brand for Apple? Focusing on the sizzle and not the steak?
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
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).
And color functions don’t need displays with better color to work. They’re about better ways to describe colors, to mix colors, and to choose colors.
And Apple did nothing to prevent others from using displays with better color, nor does enhancing the web hamper the web.
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.
[1]: https://webkit.org/blog/10042/wide-gamut-color-in-css-with-d...
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.
We're nearly there...
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.
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.
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.
There's the Gemini ecosystem, but it feels a bit like they overcorrected and now it's overly limiting.
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?).)
…May we have links to both of those? For science.
- Spartan: gemini://spartan.mozz.us/specification.gmi
- Scorpion: https://raw.githubusercontent.com/zzo38/scorpion/trunk/Speci...
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).
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.)
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?
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.
[0] https://en.wikipedia.org/wiki/Widevine#Origins_(1998%E2%80%9...
It is however the complexity of the WWW that has resulted in the current situation where both mainstream browser engines support DRM.
Indeed, the real problem is that I can write an all-inclusive "both", and even then one is really just a fork of the other.
OK, there is a third one, but it's not the default anywhere and it also has DRM :(
> Last check Youtube is not doing server side ad insertion yet.
You also write `yet' :) Considering YT's anti-adblocking efforts lately, I assume it is just a matter of time.
You say that like it's not a useful thing.
I wish that this "feature" didn't exist. Just follow the platform and the user's defaults.
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.
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.
Hiring N teams of M developers for N native apps, compared to hiring K<<M web developers is way more expensive, difficult, and slow.
Blinkenlights output forever!
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.
Writing a native Mac app and a native Windows app and possibly two native mobile apps and maybe a Linux app is just not feasible for most companies.
Apple launched SwiftUI fairly recently and it seems to be being developed at a fairly fast pace.
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?
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.
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.
Nothing special about scroll, right?
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.
https://github.com/WebKit/standards-positions/issues/133#iss...
> 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.
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.