[HN Gopher] The web just gets better with Interop 2024
___________________________________________________________________
The web just gets better with Interop 2024
Author : feross
Score : 129 points
Date : 2024-02-01 17:33 UTC (5 hours ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| ghaff wrote:
| 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 wrote:
| That was my first thought - did Networld Interop restart and is
| now a big thing again? What next, COMDEX?
| CharlesW wrote:
| 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 wrote:
| Because it's a niche use case compared to the much much broader
| case of "display content."
| yurishimo wrote:
| 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 wrote:
| 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 wrote:
| And what excuse do you have for Firefox dropping PWA support?
| Or is it just Apple that is evil?
| culi wrote:
| 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...
| mlunar wrote:
| APIs sure, installing on desktop, no. A bit further down
| on the page linked via the second link:
|
| "On desktop: Firefox and Safari do not
| support installing PWAs on any desktop operating
| systems."
| politelemon wrote:
| It bypasses an app store model, you can install an app directly
| from a browser.
|
| 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.
| culi wrote:
| 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
| culi wrote:
| 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?
| CharlesW wrote:
| > _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.
| troupo wrote:
| > Why do we think there isn't a PWA focus area from the
| participating consortium?
|
| 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?
| lapcat wrote:
| > Scrollbar Styling
|
| I wish that this "feature" didn't exist. Just follow the platform
| and the user's defaults.
| lloydatkinson wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.c
| om/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.
| zzo38computer wrote:
| Well, it is there if that is what you want. But, not
| everyone wants such a thing like that, and you should not
| expect everyone to want that, please.
| jakub_g wrote:
| 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.
| zzo38computer wrote:
| 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.
| marcosdumay wrote:
| > maybe nomadic? colonizer? invasive?
|
| 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.
| toddmorey wrote:
| 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?
| dist-epoch wrote:
| > 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.
| bestouff wrote:
| We don't have the same definition for "vital".
| dist-epoch wrote:
| 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"
| runarberg wrote:
| 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
| esafak wrote:
| Do you mind sharing the identity of the app? I am curious
| to see how/what you customized.
| runarberg wrote:
| 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.
|
| https://bugs.webkit.org/show_bug.cgi?id=221347#c12
| jakub_g wrote:
| 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?)
| paulddraper wrote:
| I assume you would apply this to others? Checkbox, select,
| input, button, etc?
|
| Nothing special about scroll, right?
| troupo wrote:
| 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.
| zzo38computer wrote:
| 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).
| carlosjobim wrote:
| How I wish for minimap scrollbars in all applications...
| simion314 wrote:
| 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.
| promiseofbeans wrote:
| 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)
| hardcopy wrote:
| > 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
| apitman wrote:
| 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 wrote:
| > 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 wrote:
| So that it's totally unattractive for business interests who
| want VR and if possible neuralink chips to send ads directly
| into your brain.
| zzo38computer wrote:
| 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?).)
| zzo38computer wrote:
| > 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.
| apitman wrote:
| Would love to hear about what you're working on
| zzo38computer wrote:
| A GitHub repository is at:
| https://github.com/zzo38/scorpion
|
| 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).
| userbinator wrote:
| _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.)
| no_wizard wrote:
| 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 wrote:
| > _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 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.
| no_wizard wrote:
| 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.
| jprete wrote:
| 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?)
| da_chicken wrote:
| I believe you meant to link this:
| https://v8.dev/features/import-attributes
|
| 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.
| apatheticonion wrote:
| > Origin Private FileSystem
|
| 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?
| streptomycin wrote:
| Last I looked into it, it's not permanent in any browser.
| If you're low on disk space, stuff will get deleted.
| https://twitter.com/tomayac/status/1613605318407094275
|
| 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_wizard wrote:
| The broader spec that OPFS is part of is (was?) suppose to
| give you just that:
|
| 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 has been presented, and I don't believe it
| can't be done in a privacy friendly way. These are smart
| engineers, some of the best and the brightest, who
| supposedly are good at solving thorny problems
| nwienert wrote:
| 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.
| no_wizard wrote:
| 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.
| novov wrote:
| Interop is a joint initiative between all three browsers
| though, not just Safari. Its not just Safari that picks
| these focus areas.
| no_wizard wrote:
| 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.
| threeseed wrote:
| > 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.
| hammyhavoc wrote:
| >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?
| Etheryte wrote:
| 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?
| robertoandred wrote:
| 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.
| CM30 wrote:
| 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 wrote:
| 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.
| ozten wrote:
| No mention of WebXR.
___________________________________________________________________
(page generated 2024-02-01 23:00 UTC)