5 ms·

Because, hey, monopoly and monoculture, what could possibly go wrong? If Webkit's codebase defines the "standard" then the decision-making process is no longer

Because, hey, monopoly and monoculture, what could possibly go wrong? If Webkit's codebase defines the "standard" then the decision-making process is no longer open, even if the source code (eventually) is. It is controlled by a small number of people, primarily at Google and Apple, who have their existing products and product plans to consider when adding features and changing behavior. Think about what that means if you are trying to compete with those two. Forget trying to create a competing code base, they control like 90% of the existing mobile web. But even if you adopt Webkit you're at a huge disadvantage because they're months ahead--you can't just fork the code and go your own way, you also have to adopt whatever they include later because it's the standard.

blibble 15y ago
as a pragmatist, I really don't care. the W3C is completely ineffective. I kinda wish Gecko and Trident would die, as it would make my life a lot easier (no more silly compatibility libraries, testing in 5 different engines, etc). what's stopping Mozilla from forking Webkit? remember that Webkit itself was a fork of KHTML...
- gcp 15y ago
  Well, WebKit is nice and all. At some point, it was not WebKit, but Gecko that was the shit. Then early WebKit authors made something that was easier to embed and had a license that was friendlier to corporate entities. Apple and Google flocked to it, and improved it even more. They could do this because they had a standard to work from. They didn't have to source-reverse-engineer Gecko, because they could work from that standard, that described how things worked. They didn't have to fork Gecko (nor would they have wanted to because of the licensing), because they didn't need to do things exactly the same way even where it made no sense. This standard came to be because earlier browser vendors (including Microsoft/IE and Mozilla/Gecko) understood that things would be a mess if they didn't cooperate. They'd been there, and done that. If you're now proposing to drop the actual standardization process and define the Internet as "whatever WebKit renders", be aware that you're just killing what made WebKit possible in the first place. You could fork WebKit, but you'd still have to emulate it close enough to be bug-for-bug compatible. That's not a way to get a real improvement or independent implementation. And it wasn't how WebKit came to be, either. For the companies that are heavily invested in WebKit (Apple, Google), it's a wet dream: it ensures they can never be eclipsed by something even better. Imagine if we had done that for Gecko (it's open source too, after all!): Mozilla could have sat on their asses and wouldn't even really have to have cared about improving it. Luckily people competed with rendering engines, so both WebKit and Gecko keep improving rapidly. And so do IE and Opera. I can make similar analogies for things like C++, GCC and LLVM. Even if the implementations are open source, having a standard that allows independent ones is tremendously important to prevent stagnation. I'm not ready to allow C++ to be redefined as "whatever GCC compiles" any more than I am ready to allow the Internet to be redefined as "whatever WebKit renders". Even though yes, this does mean more work keeping things compatible for me as a C++ programmer.
  - blibble 15y ago
    KHTML is as old as Gecko, and Webkit and Gecko are both LGPL. the killer feature back in the early 2000's was the ability to render most of the pages on the Internet as IE did, so saying that the engines were the product of standards is categorically wrong. the lack of adoption of Gecko outside of Mozilla is more to do with the fact the source code is a mess, whereas Webkit is very clean and tidy, and as a result very easy to hack on (years ago I wanted to embed Gecko in a project, and ended up using Webkit as it was actually possible to modify...).
    - pcwalton 15y ago
      The remarkable thing about Firefox is not how much it compromised on implementing IE-specific features, but rather how much market share it gained in spite of the fact that it didn't compromise on implementing IE-specific features. To name a few off the top of my head: ActiveX, filter:progid:DXImageTransform, CSS "zoom" property, insertAdjacentElement(), etc.
    - yuhong 15y ago
      Gecko is now LGPL. Back in 2000 it wasn't.
- robin_reala 15y ago
  On the other hand, there is no one WebKit: http://www.quirksmode.org/webkit.html http://www.quirksmode.org/webkit.html
- pcwalton 15y ago
  Having to completely rewrite Firefox for no gain, which would basically destroy Firefox. See Matt Brubeck's answer here: http://www.quora.com/Mozilla-Firefox/Will-Firefox-ever-drop-its-Gecko-layout-engine-to-adopt-WebKit#ans906999 http://www.quora.com/Mozilla-Firefox/Will-Firefox-ever-drop-... Besides, Gecko is ahead of WebKit in several ways (MathML, Direct2D, etc.); there's no compelling reason to switch.

blibble 15y ago

as a pragmatist, I really don't care. the W3C is completely ineffective. I kinda wish Gecko and Trident would die, as it would make my life a lot easier (no more silly compatibility libraries, testing in 5 different engines, etc). what's stopping Mozilla from forking Webkit? remember that Webkit itself was a fork of KHTML...

gcp 15y ago
Well, WebKit is nice and all. At some point, it was not WebKit, but Gecko that was the shit. Then early WebKit authors made something that was easier to embed and had a license that was friendlier to corporate entities. Apple and Google flocked to it, and improved it even more. They could do this because they had a standard to work from. They didn't have to source-reverse-engineer Gecko, because they could work from that standard, that described how things worked. They didn't have to fork Gecko (nor would they have wanted to because of the licensing), because they didn't need to do things exactly the same way even where it made no sense. This standard came to be because earlier browser vendors (including Microsoft/IE and Mozilla/Gecko) understood that things would be a mess if they didn't cooperate. They'd been there, and done that. If you're now proposing to drop the actual standardization process and define the Internet as "whatever WebKit renders", be aware that you're just killing what made WebKit possible in the first place. You could fork WebKit, but you'd still have to emulate it close enough to be bug-for-bug compatible. That's not a way to get a real improvement or independent implementation. And it wasn't how WebKit came to be, either. For the companies that are heavily invested in WebKit (Apple, Google), it's a wet dream: it ensures they can never be eclipsed by something even better. Imagine if we had done that for Gecko (it's open source too, after all!): Mozilla could have sat on their asses and wouldn't even really have to have cared about improving it. Luckily people competed with rendering engines, so both WebKit and Gecko keep improving rapidly. And so do IE and Opera. I can make similar analogies for things like C++, GCC and LLVM. Even if the implementations are open source, having a standard that allows independent ones is tremendously important to prevent stagnation. I'm not ready to allow C++ to be redefined as "whatever GCC compiles" any more than I am ready to allow the Internet to be redefined as "whatever WebKit renders". Even though yes, this does mean more work keeping things compatible for me as a C++ programmer.
- blibble 15y ago
  KHTML is as old as Gecko, and Webkit and Gecko are both LGPL. the killer feature back in the early 2000's was the ability to render most of the pages on the Internet as IE did, so saying that the engines were the product of standards is categorically wrong. the lack of adoption of Gecko outside of Mozilla is more to do with the fact the source code is a mess, whereas Webkit is very clean and tidy, and as a result very easy to hack on (years ago I wanted to embed Gecko in a project, and ended up using Webkit as it was actually possible to modify...).
  - pcwalton 15y ago
    The remarkable thing about Firefox is not how much it compromised on implementing IE-specific features, but rather how much market share it gained in spite of the fact that it didn't compromise on implementing IE-specific features. To name a few off the top of my head: ActiveX, filter:progid:DXImageTransform, CSS "zoom" property, insertAdjacentElement(), etc.
  - yuhong 15y ago
    Gecko is now LGPL. Back in 2000 it wasn't.
robin_reala 15y ago
On the other hand, there is no one WebKit: http://www.quirksmode.org/webkit.html http://www.quirksmode.org/webkit.html
pcwalton 15y ago
Having to completely rewrite Firefox for no gain, which would basically destroy Firefox. See Matt Brubeck's answer here: http://www.quora.com/Mozilla-Firefox/Will-Firefox-ever-drop-its-Gecko-layout-engine-to-adopt-WebKit#ans906999 http://www.quora.com/Mozilla-Firefox/Will-Firefox-ever-drop-... Besides, Gecko is ahead of WebKit in several ways (MathML, Direct2D, etc.); there's no compelling reason to switch.