6 ms·

Hmm, I really feel Apple is to blame for this mess, just my gut feeling.

by Bino 10y ago

kitsunesoba 10y ago
Mozilla is at least partially responsible as well. WebKit only became as dominant as it did because it was readily and easily embeddable, highly portable, and nearly language and toolkit agnostic. Gecko easily could've become a major player as well, but instead of looking ahead and making Gecko more appealing to developers and OEMs, they dropped support for embedded Gecko entirely and doubled down on Gecko and Firefox for all practical purposes being one in the same and forcing anyone interested in using Gecko to wrestle around with XULRunner. So today WebKit is everywhere (even where Chrome/Blink isn't) and is the bar all others are measured by. Had Mozilla been more amicable to projects like Camino and K-Meleon things might be different now.
- pcwalton 10y ago
  KHTML was hardly embeddable, portable, or language/toolkit agnostic at the time.
  - lmm 10y ago
    It was absolutely embeddadble - the KPart was a first-class supported way of using it (widely used in other KDE applications) - and at least somewhat portable (KDE on windows predates WebKit).
    - gcp 10y ago
      But didn't KPart rely on KDE (libs)? That's hardly embeddable in any meaningful sense. Gecko was embeddable too if everything you wrote was XUL :-)
      - lmm 10y ago
        Kdeui was (and remains) a first-class toolkit for writing arbitrary applications (and widely used as such) in a way that XUL has never really been.
        pcwalton 10y ago
        I think "embeddable" means at least "I have an arbitrary Charles Petzold-style Win32 app and I want to put KHTML in it without adopting my whole app to a framework". KParts was never really designed for this.
- djsumdog 10y ago
  Google donated to/funded the Mozilla foundation, promoted a better web browser, and then released a closed source web browser based on both Gecko and Webkit. Yes, Chrome (at least its rendering engine) is open now. But back when it was released, and the way it was released, was taken by many to be Google taking a big heaping dump on the OSS community.
eyelidlessness 10y ago
Apple's success with WebKit, combined with their success in advancing browser technologies, is partially responsible. To explain... Their use of vendor prefixes was proscribed by the standards (and may well still be). After years of stagnation in browser technologies, and demand from content producers and developers for advancement, vendor prefixes were seen as a way to vet real-world usage of new standards before they were formalized. But because standardization was still quite slow, and because vendors (all of them!) were slow to remove prefixes, and because non-WebKit vendors lagged behind WebKit in features (for a while), the proliferation of `-webkit-*` was inevitable. Today's rejection of vendor prefixes is a reflection of that intersection of problems. They were maybe never a great solution to the problem that preceded them, but they are no longer suitable and that's just fine. I'd prefer Firefox (and every other vendor) simply disabled handling for prefixes entirely. But there is a ton of content that will never be updated again, and would break. Without some kind of versioning, that's untenable. And we already saw what happened when Mozilla tried to introduce versioning. (It was never supported by other vendors, and therefore never used by developers.)

Hmm, I really feel Apple is to blame for this mess, just my gut feeling.

by Bino 10y ago

Hmm, I really feel Apple is to blame for this mess, just my gut feeling.

Mozilla is at least partially responsible as well. WebKit only became as dominant as it did because it was readily and easily embeddable, highly portable, and nearly language and toolkit agnostic. Gecko easily could've become a major player as well, but instead of looking ahead and making Gecko more appealing to developers and OEMs, they dropped support for embedded Gecko entirely and doubled down on Gecko and Firefox for all practical purposes being one in the same and forcing anyone interested in using Gecko to wrestle around with XULRunner. So today WebKit is everywhere (even where Chrome/Blink isn't) and is the bar all others are measured by. Had Mozilla been more amicable to projects like Camino and K-Meleon things might be different now.

pcwalton 10y ago
KHTML was hardly embeddable, portable, or language/toolkit agnostic at the time.
- lmm 10y ago
  It was absolutely embeddadble - the KPart was a first-class supported way of using it (widely used in other KDE applications) - and at least somewhat portable (KDE on windows predates WebKit).
  - gcp 10y ago
    But didn't KPart rely on KDE (libs)? That's hardly embeddable in any meaningful sense. Gecko was embeddable too if everything you wrote was XUL :-)
    - lmm 10y ago
      Kdeui was (and remains) a first-class toolkit for writing arbitrary applications (and widely used as such) in a way that XUL has never really been.
      - pcwalton 10y ago
        I think "embeddable" means at least "I have an arbitrary Charles Petzold-style Win32 app and I want to put KHTML in it without adopting my whole app to a framework". KParts was never really designed for this.
djsumdog 10y ago
Google donated to/funded the Mozilla foundation, promoted a better web browser, and then released a closed source web browser based on both Gecko and Webkit. Yes, Chrome (at least its rendering engine) is open now. But back when it was released, and the way it was released, was taken by many to be Google taking a big heaping dump on the OSS community.

eyelidlessness 10y ago

Apple's success with WebKit, combined with their success in advancing browser technologies, is partially responsible. To explain... Their use of vendor prefixes was proscribed by the standards (and may well still be). After years of stagnation in browser technologies, and demand from content producers and developers for advancement, vendor prefixes were seen as a way to vet real-world usage of new standards before they were formalized. But because standardization was still quite slow, and because vendors (all of them!) were slow to remove prefixes, and because non-WebKit vendors lagged behind WebKit in features (for a while), the proliferation of `-webkit-*` was inevitable. Today's rejection of vendor prefixes is a reflection of that intersection of problems. They were maybe never a great solution to the problem that preceded them, but they are no longer suitable and that's just fine. I'd prefer Firefox (and every other vendor) simply disabled handling for prefixes entirely. But there is a ton of content that will never be updated again, and would break. Without some kind of versioning, that's untenable. And we already saw what happened when Mozilla tried to introduce versioning. (It was never supported by other vendors, and therefore never used by developers.)