4 ms·

the comparison between IE6 and Webkit is unfair: Webkit is completely open-source and under active development, whereas IE6 was propriety and dead. as a pragma

by blibble 15y ago

the comparison between IE6 and Webkit is unfair: Webkit is completely open-source and under active development, whereas IE6 was propriety and dead. as a pragmatist I don't see it as an bad thing if Webkit becomes close to 100% of the browser market...

dmethvin 15y ago
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.
khuey 15y ago
And what happens when somebody discovers a zero-day security flaw in Webkit then? Even benign monoculture is bad for the web.
- batista 15y ago
  So what? Then the exploit will work with 100% of browsers instead of, say, 40% as it is now. Not that much of a difference...
  - ootachi 15y ago
    So because we don't have enough browser competition, we should have one browser monopoly? Your cure is worse than the disease.
    - batista 15y ago
      I never said we should have browser monopoly. I said, a 0-day covering 100% of browsers compared to one covering 40-50% of browsers ain't much of a difference. That said, a single browser engine used is not a browser monopoly. For one, because a browser is more than the browser engine used. So you can have browsers with the same engine (Chrome, Webkit, Konqueror, ...) competing on the GUI front. Second, you can even add new rendering features and options ON TOP of the same rendering engine. Webkit has stuff that Chrome does not, even in the browser engine department. It just means that you have the bases covered with ONE codebase, with more compatibility, and you don't have to reinvent any "wheels", ie. things you have to get working the same way anyway, as is the rendering of a DIV, for example. So this also takes care of the "competition" in HTML implementation issue. Third, a monopoly (when considered a bad thing) implies some way to abuse that power. The use of a single open source browser engine provides none, since no one in particular controls it. Besides, anyone can still write a better browser engine if you want, and even cherry pick parts of the single 99% popular engine.
      - ootachi 15y ago
        You're implying that nobody in particular controls WebKit? That is patently false. And the distinction between a browser engine monopoly and a browser monopoly is irrelevant to this discussion. We're talking about browser engines here. Furthermore, suggesting that people can add "new rendering features and options" on top of WebKit solves nothing! Those would just have to be prefixed in the same way, or would be incompatible, and we're back to square one.
cbs 15y ago
IE6 was propriety and dead. I don't think either propriety vs opensource or dead vs active development are important to the overall question of "is standardizing on a single implementation a bad idea?" Yes, the fact it had dropped out of active development made it worse to standardize on, but it was already a bad idea. The same goes for open source. Yes, it can be forked to get away from something bad, but if only one browser/engine becomes standardized on by users and developers, then that engine's team has complete control over what the web becomes regardless of competing implementations are doing. It creates a HUGE hurdle to pull the web in another direction. People weren't "stuck" with IE6 because it wasn't opensource, they were stuck because the distributor wasn't releasing new versions that also did what the competing products wanted supported.

by blibble 15y ago

dmethvin 15y ago

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.

khuey 15y ago

And what happens when somebody discovers a zero-day security flaw in Webkit then? Even benign monoculture is bad for the web.

batista 15y ago
So what? Then the exploit will work with 100% of browsers instead of, say, 40% as it is now. Not that much of a difference...
- ootachi 15y ago
  So because we don't have enough browser competition, we should have one browser monopoly? Your cure is worse than the disease.
  - batista 15y ago
    I never said we should have browser monopoly. I said, a 0-day covering 100% of browsers compared to one covering 40-50% of browsers ain't much of a difference. That said, a single browser engine used is not a browser monopoly. For one, because a browser is more than the browser engine used. So you can have browsers with the same engine (Chrome, Webkit, Konqueror, ...) competing on the GUI front. Second, you can even add new rendering features and options ON TOP of the same rendering engine. Webkit has stuff that Chrome does not, even in the browser engine department. It just means that you have the bases covered with ONE codebase, with more compatibility, and you don't have to reinvent any "wheels", ie. things you have to get working the same way anyway, as is the rendering of a DIV, for example. So this also takes care of the "competition" in HTML implementation issue. Third, a monopoly (when considered a bad thing) implies some way to abuse that power. The use of a single open source browser engine provides none, since no one in particular controls it. Besides, anyone can still write a better browser engine if you want, and even cherry pick parts of the single 99% popular engine.
    - ootachi 15y ago
      You're implying that nobody in particular controls WebKit? That is patently false. And the distinction between a browser engine monopoly and a browser monopoly is irrelevant to this discussion. We're talking about browser engines here. Furthermore, suggesting that people can add "new rendering features and options" on top of WebKit solves nothing! Those would just have to be prefixed in the same way, or would be incompatible, and we're back to square one.

cbs 15y ago

IE6 was propriety and dead. I don't think either propriety vs opensource or dead vs active development are important to the overall question of "is standardizing on a single implementation a bad idea?" Yes, the fact it had dropped out of active development made it worse to standardize on, but it was already a bad idea. The same goes for open source. Yes, it can be forked to get away from something bad, but if only one browser/engine becomes standardized on by users and developers, then that engine's team has complete control over what the web becomes regardless of competing implementations are doing. It creates a HUGE hurdle to pull the web in another direction. People weren't "stuck" with IE6 because it wasn't opensource, they were stuck because the distributor wasn't releasing new versions that also did what the competing products wanted supported.