12 ms·

The web just gets better with Interop 2024

267 points by feross 3y ago

RobertWHurst 3y ago
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.
ghaff 3y ago
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.
- rexreed 3y ago
  That was my first thought - did Networld Interop restart and is now a big thing again? What next, COMDEX?
  - ghaff 3y ago
    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.
CharlesW 3y ago
I got a lot more excited reading this than I thought I would. Why do we think there isn't a PWA focus area from the participating consortium?
- etchalon 3y ago
  Because it's a niche use case compared to the much much broader case of "display content."
- yurishimo 3y ago
  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?
- agust 3y ago
  Because Apple has a say in what features are added there, and they'll do whatever they can to keep slowing down the progress of Web Apps.
  - askonomm 3y ago
    And what excuse do you have for Firefox dropping PWA support? Or is it just Apple that is evil?
    - deleted 3y ago
      [deleted]
    - culi 3y ago
      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: https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
lapcat 3y ago
> Scrollbar Styling I wish that this "feature" didn't exist. Just follow the platform and the user's defaults.
- deleted 3y ago
  [deleted]
- lloydatkinson 3y ago
  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.
- Spivak 3y ago
  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.
  - mostlylurks 3y ago
    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.
    - AlexandrB 3y ago
      I want the complete opposite. Most 3rd party developers absolutely suck at UX compared to Apple or even Microsoft. Look at this HP monstrosity, for example: https://i.pcmag.com/imagery/articles/07LJBKFE51UG5cHJPEojwn9-6..v1627596551.png https://i.pcmag.com/imagery/articles/07LJBKFE51UG5cHJPEojwn9... 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.
hardcopy 3y ago
> It ensured that all browsers have full support for P3 color, seven years after it started shipping. 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1626624#c16
darig 3y ago
[dead]
apitman 3y ago
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.
- treyd 3y ago
  > I would love to see some sort of reboot of the web with simple protocols There's the Gemini ecosystem, but it feels a bit like they overcorrected and now it's overly limiting.
  - petre 3y ago
    So that it's totally unattractive for business interests who want VR and if possible neuralink chips to send ads directly into your brain.
    - jeffhuys 3y ago
      FYI, Neuralink is one-way only. It does NOT “send” data into your brain, it only reads.
  - zzo38computer 3y ago
    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?).)
no_wizard 3y ago
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.
- chrismorgan 3y ago
  > Origin Private FileSystem 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 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.
CM30 3y ago
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.
- andirk 3y ago
  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.
  - ohrus 3y ago
    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.
  - jeffhuys 3y ago
    If you’d read the article, you’d have read that the new popover element allows CUSTOM elements, like designers love. Just without JS.
    - andirk 3y ago
      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.
ozten 3y ago
No mention of WebXR.
- msub2 3y ago
  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.
F3nd0 3y ago
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.
- no_wizard 3y ago
  I was also saddened by this. I don't know what Google's problem is with JPEG XL.
  - paulddraper 3y ago
    Because AVIF is already a thing. And is comparable for images and superior for video.
    - watersb 3y ago
      I could imagine hardware vendors telling the software platform creators to standardize on an image codec. Might be slightly encouraged to pick the image format that matches a video codec that's already widely supported by hardware IP.
    - F3nd0 3y ago
      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.
wackget 3y ago
I can't believe a Cookie Store API has not been officially implemented yet. How can it be 2024 and we're still having to parse a huge ugly string to get a cookie by name?
- stonogo 3y ago
  Because we got HTML 5 local storage?
  - wackget 3y ago
    Doesn't help if you want to send data to the server with every request (i.e. cookies).
sestep 3y ago
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.
- CharlesW 3y ago
  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.)
  - bemusedthrow75 3y ago
    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.
    - JimDabell 3y ago
      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.
      - bemusedthrow75 3y ago
move-on-by 3y ago
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.
- efields 3y ago
  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.
  - moron4hire 3y ago
    That really depends on the style of the artwork
    - andybak 3y ago
      Less than you think.
  - TheCoreh 3y ago
    With HiDPI/Retina displays, that 24px is actually 48px or 72px, so the need for pixel hinting is much less commonplace than it was 10 or 15 years ago. 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.
    - globular-toast 3y ago
      How many people have HiDPI displays? It seems to me apart from phones people mostly don't.
      - drcongo 3y ago
andybak 3y ago
Biggest win would be Safari shipping updates that aren't tied to OS updates.
- alberth 3y ago
  You can on macOS. 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.
  - exodust 3y ago
    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.
  - concinds 3y ago
    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.
    - JimDabell 3y ago
      > 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. https://mixpanel.com/trends/#report/ios_17/from_date:-3,report_unit:day,to_date:0 https://mixpanel.com/trends/#report/ios_17/from_date:-3,repo...
e12e 3y ago
text-wrap: balance; is all well and good - but does browsers finally do a decent job of hyphenation with hyphens: auto;? 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...
- deleted 3y ago
  [deleted]
- roca 3y ago
  TeX/LaTeX don't compete on performance and don't handle dynamic document updates. Browser text layout is a much harder problem.
  - e12e 3y ago
    I don't think that's true today. Big difference running TeX on a 7Mhz 68000 and a 8 core multi GHz cpu. See also: https://hyphenation.org/ https://hyphenation.org/ https://github.com/mnater/Hyphenopoly https://github.com/mnater/Hyphenopoly
alberth 3y ago
Fonts 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-of-digital-typesetting-d082d84b202 https://medium.com/microsoft-design/leading-trim-the-future-... https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim
- alwillis 3y ago
  margin-trim shipped in Safari 16.4 nearly a year ago [1]. 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/#css https://webkit.org/blog/13966/webkit-features-in-safari-16-4...
  - alberth 3y ago
    I meant across all browsers since Interop is about raising the bar on all browser support. Right now, no other browsers support those features. https://caniuse.com/?search=leading-trim https://caniuse.com/?search=leading-trim
alberth 3y ago
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. https://wpt.fyi/results/?label=experimental&label=master&aligned https://wpt.fyi/results/?label=experimental&label=master&ali...
- troupo 3y ago
  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)
duckman1 3y ago
It's just a bunch of CSS rules lmao
chrisjj 3y ago
"Interop"?? The more honest name would be FixUpOp, surely.
saurabhchalke 3y ago
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.

267 points by feross 3y ago

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.

ghaff 3y ago

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.

rexreed 3y ago
That was my first thought - did Networld Interop restart and is now a big thing again? What next, COMDEX?
- ghaff 3y ago
  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.

CharlesW 3y ago

I got a lot more excited reading this than I thought I would. Why do we think there isn't a PWA focus area from the participating consortium?

etchalon 3y ago
Because it's a niche use case compared to the much much broader case of "display content."
yurishimo 3y ago
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?
agust 3y ago
Because Apple has a say in what features are added there, and they'll do whatever they can to keep slowing down the progress of Web Apps.
- askonomm 3y ago
  And what excuse do you have for Firefox dropping PWA support? Or is it just Apple that is evil?
  - deleted 3y ago
    [deleted]
  - culi 3y ago
    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: https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps https://developer.mozilla.org/en-US/docs/Web/Progressive_web...

lapcat 3y ago

> Scrollbar Styling I wish that this "feature" didn't exist. Just follow the platform and the user's defaults.

deleted 3y ago
[deleted]
lloydatkinson 3y ago
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.
Spivak 3y ago
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.
- mostlylurks 3y ago
  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.
  - AlexandrB 3y ago
    I want the complete opposite. Most 3rd party developers absolutely suck at UX compared to Apple or even Microsoft. Look at this HP monstrosity, for example: https://i.pcmag.com/imagery/articles/07LJBKFE51UG5cHJPEojwn9-6..v1627596551.png https://i.pcmag.com/imagery/articles/07LJBKFE51UG5cHJPEojwn9... 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.

hardcopy 3y ago

> It ensured that all browsers have full support for P3 color, seven years after it started shipping. 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1626624#c16

darig 3y ago

[dead]

apitman 3y ago

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.

treyd 3y ago
> I would love to see some sort of reboot of the web with simple protocols There's the Gemini ecosystem, but it feels a bit like they overcorrected and now it's overly limiting.
- petre 3y ago
  So that it's totally unattractive for business interests who want VR and if possible neuralink chips to send ads directly into your brain.
  - jeffhuys 3y ago
    FYI, Neuralink is one-way only. It does NOT “send” data into your brain, it only reads.
- zzo38computer 3y ago
  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?).)

no_wizard 3y ago

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.

chrismorgan 3y ago
> Origin Private FileSystem 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 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.

CM30 3y ago

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.

andirk 3y ago
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.
- ohrus 3y ago
  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.
- jeffhuys 3y ago
  If you’d read the article, you’d have read that the new popover element allows CUSTOM elements, like designers love. Just without JS.
  - andirk 3y ago
    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.

ozten 3y ago

No mention of WebXR.

msub2 3y ago
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.

F3nd0 3y ago

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.

no_wizard 3y ago
I was also saddened by this. I don't know what Google's problem is with JPEG XL.
- paulddraper 3y ago
  Because AVIF is already a thing. And is comparable for images and superior for video.
  - watersb 3y ago
    I could imagine hardware vendors telling the software platform creators to standardize on an image codec. Might be slightly encouraged to pick the image format that matches a video codec that's already widely supported by hardware IP.
  - F3nd0 3y ago
    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.

wackget 3y ago

I can't believe a Cookie Store API has not been officially implemented yet. How can it be 2024 and we're still having to parse a huge ugly string to get a cookie by name?

stonogo 3y ago
Because we got HTML 5 local storage?
- wackget 3y ago
  Doesn't help if you want to send data to the server with every request (i.e. cookies).

sestep 3y ago

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.

CharlesW 3y ago
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.)
- bemusedthrow75 3y ago
  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.
  - JimDabell 3y ago
    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.
    - bemusedthrow75 3y ago

move-on-by 3y ago

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.

efields 3y ago
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.
- moron4hire 3y ago
  That really depends on the style of the artwork
  - andybak 3y ago
    Less than you think.
- TheCoreh 3y ago
  With HiDPI/Retina displays, that 24px is actually 48px or 72px, so the need for pixel hinting is much less commonplace than it was 10 or 15 years ago. 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.
  - globular-toast 3y ago
    How many people have HiDPI displays? It seems to me apart from phones people mostly don't.
    - drcongo 3y ago

andybak 3y ago

Biggest win would be Safari shipping updates that aren't tied to OS updates.

alberth 3y ago
You can on macOS. 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.
- exodust 3y ago
  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.
- concinds 3y ago
  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.
  - JimDabell 3y ago
    > 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. https://mixpanel.com/trends/#report/ios_17/from_date:-3,report_unit:day,to_date:0 https://mixpanel.com/trends/#report/ios_17/from_date:-3,repo...

e12e 3y ago

text-wrap: balance; is all well and good - but does browsers finally do a decent job of hyphenation with hyphens: auto;? 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...

deleted 3y ago
[deleted]
roca 3y ago
TeX/LaTeX don't compete on performance and don't handle dynamic document updates. Browser text layout is a much harder problem.
- e12e 3y ago
  I don't think that's true today. Big difference running TeX on a 7Mhz 68000 and a 8 core multi GHz cpu. See also: https://hyphenation.org/ https://hyphenation.org/ https://github.com/mnater/Hyphenopoly https://github.com/mnater/Hyphenopoly

alberth 3y ago

Fonts 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-of-digital-typesetting-d082d84b202 https://medium.com/microsoft-design/leading-trim-the-future-... https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim

alwillis 3y ago
margin-trim shipped in Safari 16.4 nearly a year ago [1]. 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/#css https://webkit.org/blog/13966/webkit-features-in-safari-16-4...
- alberth 3y ago
  I meant across all browsers since Interop is about raising the bar on all browser support. Right now, no other browsers support those features. https://caniuse.com/?search=leading-trim https://caniuse.com/?search=leading-trim

alberth 3y ago

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. https://wpt.fyi/results/?label=experimental&label=master&aligned https://wpt.fyi/results/?label=experimental&label=master&ali...

troupo 3y ago
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)

duckman1 3y ago

It's just a bunch of CSS rules lmao

chrisjj 3y ago

"Interop"?? The more honest name would be FixUpOp, surely.

saurabhchalke 3y ago

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.