4 ms·

> the more code engines share, the more de facto standardization of bugs we would see, so having genuinely separate implementations is very important. Well it'

by zaro 9y ago

> the more code engines share, the more de facto standardization of bugs we would see, so having genuinely separate implementations is very important. Well it's not like there aren't any bugs in the specs. And whether there are bugs in the code or the specification, it's the same process for fixing them : politics :)

roca 9y ago
Web developers code to Web browsers, so bugs in Web browsers lead to sites depending on those bugs, making those bugs unfixable unless you have developers testing in multiple browsers. Spec bugs don't become unfixable that way.
- Leszek 9y ago
  Though spec bugs go the opposite way: if you discover an issue in the spec, then it is very difficult to change it because someone somewhere may have been - at the time correctly - relying on that behaviour.
  - peterwwillis 9y ago
    Or, you could just be Google, and change your browser to work the way you want, and ignore all the pages breaking by insisting that the change is "within spec", giving a big middle finger to anyone that complains.
  - roca 9y ago
    Web developers can only rely on a spec bug if the browsers they test with actually implement that bug. So it still comes down to what browsers implement, not what the spec says.
- vbezhenar 9y ago
  It doesn't have to be this way. Apple doesn't have fear of breaking old apps sometimes, for example, and they are successful. I think that absurd backwards compatibility should be considered harmful and some breakage should be normal. It's always possible to install old browser into virtual machine, if content is so precious.
  - tolien 9y ago
    Apple doesn’t have the competitive pressure that I can take my broken iOS app and run it somewhere else as-is, or tell my customers to do that. “It works in Chrome” (and previously IE) is a real issue and the browser that broke compatibility like that would have to be supported (potentially through the coercive power of its own market share - see the initial “any open source browser versus IE is a good thing” switching to “we need multiple browser engines, even if they’re all open source”) by the others or face irrelevance.
jgraham 9y ago
There has been a lot of progress recently on the web-platform-tests project [1]. This is a cross-vendor effort to improve interoperability on the web platform through testing. Historically the process for building web-platform features has been to write a spec and then assume that implementations of the spec would reach compatibility in an ad-hoc manner by patching until sites worked. The big innovation of the last decade — still controversial to some — was the idea that it's OK to adjust the specs themselves when implementations have converged on some other behaviour or when the spec is otherwise wrong. The goal for the future is to use the same engineering discipline that you would use for developing software to developing the platform itself. In particular the objective is: * Every change to a spec that influences browser behaviour must be accompanied by a corresponding test case. * Every change to a browser that affects a cross-platform feature that isn't already adequetely tested must be accompanied by cross-browser test cases. * The results of those tests must be visible to browser vendors in a way that makes it easy to identify the higest value bugfixes (e.g. cases where N-1 browsers agree and one is different, or cases where a spec change makes previously correct behaviour — which may not have shipped yet, but just be enabled on nightly builds or behing a flag — wrong). Apart from the work of actually writing the test, achieving those goals involves a lot of infrastrucutre work to ensure that the cross-browser tests are well integrated into the development cycle of each browser and are able to cover as many scenarios as possible (testing often involves manipulating the browser in a way that is not exposed to normal web content). Despite the large scope of the project, I think it's agreed that modernising the way the platform is developed, and prioritising interoperability at all stages of spec and browser development is essential to avoiding existential threats to the open web in the long term. Certainly Mozilla put a lot of resources into post-hoc fixes for site-compatibility issues, and whilst there will probably always be some bugs that slip through, it will be much more efficient to catch those problems up-front before they ship to end users. I sadly don't have data to backc this up, but I'm pretty sure we're already seeing the effects of this effort, with recent, complex, features shipping with fewer cross-browser issues that we would have predicted five years ago. [1] http://web-platform-tests.org/ http://web-platform-tests.org/
- zaro 9y ago
  Very nice. I haven't heard of these tests before.

by zaro 9y ago

roca 9y ago

Web developers code to Web browsers, so bugs in Web browsers lead to sites depending on those bugs, making those bugs unfixable unless you have developers testing in multiple browsers. Spec bugs don't become unfixable that way.

Leszek 9y ago
Though spec bugs go the opposite way: if you discover an issue in the spec, then it is very difficult to change it because someone somewhere may have been - at the time correctly - relying on that behaviour.
- peterwwillis 9y ago
  Or, you could just be Google, and change your browser to work the way you want, and ignore all the pages breaking by insisting that the change is "within spec", giving a big middle finger to anyone that complains.
- roca 9y ago
  Web developers can only rely on a spec bug if the browsers they test with actually implement that bug. So it still comes down to what browsers implement, not what the spec says.
vbezhenar 9y ago
It doesn't have to be this way. Apple doesn't have fear of breaking old apps sometimes, for example, and they are successful. I think that absurd backwards compatibility should be considered harmful and some breakage should be normal. It's always possible to install old browser into virtual machine, if content is so precious.
- tolien 9y ago
  Apple doesn’t have the competitive pressure that I can take my broken iOS app and run it somewhere else as-is, or tell my customers to do that. “It works in Chrome” (and previously IE) is a real issue and the browser that broke compatibility like that would have to be supported (potentially through the coercive power of its own market share - see the initial “any open source browser versus IE is a good thing” switching to “we need multiple browser engines, even if they’re all open source”) by the others or face irrelevance.

jgraham 9y ago

There has been a lot of progress recently on the web-platform-tests project [1]. This is a cross-vendor effort to improve interoperability on the web platform through testing. Historically the process for building web-platform features has been to write a spec and then assume that implementations of the spec would reach compatibility in an ad-hoc manner by patching until sites worked. The big innovation of the last decade — still controversial to some — was the idea that it's OK to adjust the specs themselves when implementations have converged on some other behaviour or when the spec is otherwise wrong. The goal for the future is to use the same engineering discipline that you would use for developing software to developing the platform itself. In particular the objective is: * Every change to a spec that influences browser behaviour must be accompanied by a corresponding test case. * Every change to a browser that affects a cross-platform feature that isn't already adequetely tested must be accompanied by cross-browser test cases. * The results of those tests must be visible to browser vendors in a way that makes it easy to identify the higest value bugfixes (e.g. cases where N-1 browsers agree and one is different, or cases where a spec change makes previously correct behaviour — which may not have shipped yet, but just be enabled on nightly builds or behing a flag — wrong). Apart from the work of actually writing the test, achieving those goals involves a lot of infrastrucutre work to ensure that the cross-browser tests are well integrated into the development cycle of each browser and are able to cover as many scenarios as possible (testing often involves manipulating the browser in a way that is not exposed to normal web content). Despite the large scope of the project, I think it's agreed that modernising the way the platform is developed, and prioritising interoperability at all stages of spec and browser development is essential to avoiding existential threats to the open web in the long term. Certainly Mozilla put a lot of resources into post-hoc fixes for site-compatibility issues, and whilst there will probably always be some bugs that slip through, it will be much more efficient to catch those problems up-front before they ship to end users. I sadly don't have data to backc this up, but I'm pretty sure we're already seeing the effects of this effort, with recent, complex, features shipping with fewer cross-browser issues that we would have predicted five years ago. [1] http://web-platform-tests.org/ http://web-platform-tests.org/

zaro 9y ago
Very nice. I haven't heard of these tests before.