Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Chrome often only pays lip service to the standards process. They often spit out a semblance of the spec, and enable it by default almost immediately. See, e.g. most of the hardware and PWA/related APIs.


There precedence: https://www.powermapper.com/blog/web-standards-implementatio... says draft spec, then candidate recommendation (unstable), then 2 independent implementations, then recommendation (== spec in w3c terms)

It's still in their docs, too: https://www.w3.org/2023/Process-20231103/#implementation-exp... "are implementations publicly deployed?"


"Implementations publicly deployed" is widely understood as "released behind a flag to gather feedback and work out issues", not "release without a workable spec"


> They often spit out a semblance of the spec, and enable it by default almost immediately.

On the flip side, standards committees can be painfully slow.

Can anyone explain why DOM access from WebAssembly hasn’t even been specced out yet (let alone even implemented) despite years and years (approaching a decade) of discussions around this? Like, seriously, what is going on with this?


How else do you get to learn what works in the real world? Saying "you can't make a feature until everyone agrees" is a recipe for stasis.


It is literally described in the standards process.


Rough consensus and running code


> you can't make a feature until everyone agrees

Except that’s exactly how the web is supposed to work and the reason Google was able to build a giant search business in the first place. This is absolutely them shitting in the punch bowl. We made plenty of progress without fragmentation.


> Except that’s exactly how the web is supposed to work and the reason Google was able to build a giant search business in the first place.

No, because whether or not that's how the web is supposed (by whom?) to work, it is not how it did in fact work when Google built that business, in fact, it's farther from how it worked in the period Google was building a giant search business than it is now.


> ["you can't make a feature until everyone agrees" is] exactly how the web is supposed to work

That's just wildly incorrect as a matter of history. To first approximation every technology we use was implemented via Netscape and Microsoft jamming features in as fast as they could and implementing ones from their competitor only once it was clear they were reaching adoption. The interest in a "standards process" really only showed up after the turn of the millenium, once Netscape had faded and IE had begun to stagnate. And in fact Chrome was by far the biggest driver of this change.


In a sense though, the WHATWG was fragmentation and was what helped move the web forward after the W3C got too slow and hard to get anything through… Requiring consensus to add anything to the web is how progress will slow down to a crawl and we have precedent for this. The current process seems pretty good IMO


The whole point of a slower moving standard is that you are less likely to fuck yourself.

Plan Ahea

d

At some point whatwg is going to jump the shark. They are going to feature paint themselves into a corner and have to make the choice of "cut off some chunk of the web" or "go forward on a new stack". The all gas no brakes add features like were a start up forget about thoughtful or engineering is a bad way to sustain something.


> They are going to feature paint themselves into a corner and have to make the choice of "cut off some chunk of the web"

This of course is actually much more likely (and functionally happened) with pre-WHATWG standards because they'd standardize things that were infeasible and no browser ever implemented, ever.

And at the same time everyone had their own weird nonstandard extensions (does no one remember the whacky stuff like https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Pre... and how absolutely garbage-awful it was for maintainability?)


> They are going to feature paint themselves into a corner

Has the web not done that, several times over at this point? We've lost too many online standards to count, from all of the FAANG vendors.

> The all gas no brakes add features like were a start up forget about thoughtful or engineering is a bad way to sustain something.

If native smartphone runtimes were not complete dogshit, I'd probably agree with you. Without the industry's cooperation though, expanding the lowest-common-denominator platform was an inevitability. People want emulators, game streaming, proper download management, the real features that the OEMs are too afraid to publish. If they won't provide that, then their users will find another way.

And so, these "all gas no brakes" features are a product of legitimate demand. It's sad, yeah; but what's even sadder is the miserly behavior from companies like Apple that market user freedom as a security apocalypse. The openness of the web has finally caught-up with it's most-restricted users.


I think you're misremembering, there's functionally never been a time when any browser implemented only the standards. Fragmentation was much worse in the pre chrome era.

Sometimes you had standards, but they were often misimplemented because they were bad, the whatwg process is vastly less bad, since it keeps the beta features in beta and no single browser can force them through popularity alone.


I struggle to think of any piece of software or any group on the planet that has better commitment to transparency & doing it right. Who do you think does a better job, and how?

https://www.chromium.org/blink/launching-features/#new-featu... shows the process followed. Creating an explainer comes first, which is to be presented immediately to an incubation venue like WICG. Prototype behind a feature flag. Then widening review further, getting request for positions. It's recommended to start an origin trial which will run for a quarter or more. If everything is going fine, then one can start the intent to ship process.

Looking at https://groups.google.com/a/chromium.org/g/blink-dev paints such a picture of slow, controlled evolution. It's absurd to me this kind of flak blasted in the air trying to shoot down something that is generally so measured & controlled & steady in releasing. No one else has anything half this controlled. Who else does Intent to Experiment or Intent to Prototype? Few software has such a model where it's so clear what's coming, what's happening, where change & evolution is done in a controlled, slow, deliberate fashion, where prototypes are worked on & tested in the field for a significant amount of time before coming back to shipping. Few other softwares have such an extreme responsibility in going to working bodies, in soliciting requests for positions, where all manners of discovery are done.

> See, e.g. most of the hardware and PWA/related APIs.

Unclear what specific specs you are trying to throw under the bus here. PWAs took a long time to cook, in my view; hardly did they seem rashly done. A lot of people are really offended the web has MIDI & Gyrometer & other support, to the degree that they wouldn't let others enjoy this.


> shows

> paints

Exactly. You can show and paint all you want. And then there's reality.

> Unclear what specific specs you are trying to throw under the bus here.

Almost all the hardware specs (most of which are "not on any standards track", shipped in Chrome), things like Backround Fetch and Background Sync (same).

There are also others that Google shipped even before there was consensus and there were glaring issues in the spec (like Constructible Stylesheets)

> A lot of people are really offended the web has MIDI & Gyrometer & other support, to the degree that they wouldn't let others enjoy this.

To call this a misrepresentation of reality is a gross understatement


What? Generic-sensor API is a candidate recommendation from Devices and Sensors Working Group at the w3c, "intended to become a w3c recommendation". That's like 85% of the sensors. This seems incredibly weird to quibble over.

I'm struggling to see great difficulties in Background Fetch and Background Sync, specs from 6 years ago. WebKit's big fear in their position was that maybe a background fetch for a user who changes networks leaks more data than expected... Ok, maybe, yeah, but also an incredibly tiny corner case that'll affect like 1e-8% of uses.

FUD FUD FUD.

Go read the mailing list folks; figure out for yourself what if anything seems so onerous & terrible about what's happening. By all means, freak out & share if you have concerns. But this looks like a very useful benefit to us all, happening day by day, getting as much consensus and buy in as they can, to me.


> What? Generic-sensor API is a candidate recommendation

I said hardware APIs, not sensors. There are more hardware APIs than just the one you decided to cherry pick.

> I'm struggling to see great difficulties

Whatever you're struggling with, the status of these is literally "not on any standards track"

> FUD FUD FUD.

You asked which standards are not on the standards track and are enabled by default by Google. I listed some of them. No matter how loudly or hysterically you shout "FUD", reality remains unchanged.

I don't have time for your emotional outbursts. Adieu.


Sorry, which hardware APIs? Webusb? Others?

Excellent as usual chery picking. Way to be perpetually offended & antagonistic & address nothing. We should all be done with whining nothing's like this crap roll.

You have sold fear fear fear & your counter of trying to disregard & ignore is a strong strategy indeed. Strongly cast down then say nothing when the time comes! Well done. Expert moves. Have you at any point obeyed the HN guidelines that discussions should get more specific? No, you just moan and belly ache. Insult belittle & degrade. More broadly & pitiful than the last time.

Society would be better without these shit show tantrums. Sound & thunder, full of nothings.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: