3 ms·

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.

by troupo 3y ago

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.

wbl 3y ago
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.
- harles 3y ago
  > 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.
  - strongpigeon 3y ago
    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
    - zer00eyz 3y ago
      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.
      - talldayo 3y ago
        > 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.
      - joshuamorton 3y ago
        > 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_Prefix https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Pre... and how absolutely garbage-awful it was for maintainability?)
  - joshuamorton 3y ago
    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.
  - dragonwriter 3y ago
    > 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.
  - ajross 3y ago
    > ["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.
- troupo 3y ago
  It is literally described in the standards process.
  - wbl 3y ago
    Rough consensus and running code
pgeorgi 3y ago
There precedence: https://www.powermapper.com/blog/web-standards-implementation-process/ 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-experience https://www.w3.org/2023/Process-20231103/#implementation-exp... "are implementations publicly deployed?"
- troupo 3y ago
  "Implementations publicly deployed" is widely understood as "released behind a flag to gather feedback and work out issues", not "release without a workable spec"
jauntywundrkind 3y ago
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-feature-process 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 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.
- troupo 3y ago
  > 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
winter_blue 3y ago
> 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?

by troupo 3y ago

wbl 3y ago

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.

harles 3y ago
> 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.
- strongpigeon 3y ago
  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
  - zer00eyz 3y ago
    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.
    - talldayo 3y ago
      > 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.
    - joshuamorton 3y ago
      > 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_Prefix https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Pre... and how absolutely garbage-awful it was for maintainability?)
- joshuamorton 3y ago
  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.
- dragonwriter 3y ago
  > 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.
- ajross 3y ago
  > ["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.
troupo 3y ago
It is literally described in the standards process.
- wbl 3y ago
  Rough consensus and running code

pgeorgi 3y ago

There precedence: https://www.powermapper.com/blog/web-standards-implementation-process/ 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-experience https://www.w3.org/2023/Process-20231103/#implementation-exp... "are implementations publicly deployed?"

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

jauntywundrkind 3y ago

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-feature-process 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 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.

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

winter_blue 3y ago

> 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?