4 ms·

Yes, but also on the part of non Webkit web browser vendors...

potch 14y ago
So when a user types '-webkit-', and doesn't type '-ms-,-o-,-moz', when they all work, that's laziness on the vendor's part? Or better yet, when the syntax 'linear-gradient' works and you don't need a prefix at all, and you don't bother because you can't be bothered, that's laziness on the browser vendor's part? The vendors have bent over backwards to be fully compatible on gradients, animations, transition, border radii, box shadows, keyframes, and boat loads more every day. Every vendor makes compromises, the prefixes get removed and the whole web moves forward as one unified. But you'd never know it because hack developers can't be arsed to at least open one other browser to see whether it even worked. But yes, the vendors are lazy.
- tomjen3 14y ago
  While the w3c likes to think the univrse revolves around it, html5 has several competitors and given that the syntax for a particular css property doesn't matter much, they should have just standalized it the first time a browser added that feature. Beside, why use a non-webkit browser?
  - tobylane 14y ago
    What are html5's competitors? Are Opera and Firefox not even notable anymore?
    - tomjen3 14y ago
      Flash, native apps, Silverlight.
  - thristian 14y ago
    It's not CSS, but the <canvas> tag was invented by Apple for Safari, and was originally just a thin wrapper around the OS X drawing API, which was (thanks to OS X's heritage) basically just the PostScript drawing API, including all the various Porter-Duff software compositing methods (because they were all naturally supported by the API, so why not). It turns out, a decade later, that most platforms don't want to render PostScript-compatible graphics in software, they want to render graphics with hardware designed for APIs like OpenGL and Direct3D, which don't support all those compositing modes. In particular, I think IE deliberately does not implement most of the <canvas> compositing modes because they can't be hardware accelerated by Direct2D. So "just standardizing the first browser to add a feature" can lead directly to brittle, incompatible implementations, and that hurts the Web for everyone. Sure, you don't want people to wait decades for some feature or other to become widely implemented, but putting a little thought in before standardizing things helps a lot. > Beside, why use a non-webkit browser? Man, when you put it like that, why did we ever leave IE6? You could write your HTML just once and be sure it would work everywhere!
    - pretoriusB 14y ago
      >Man, when you put it like that, why did we ever leave IE6? You could write your HTML just once and be sure it would work everywhere! We left it because a) it stagnated and b) it didn't work on all platforms. Surely not because of some zeal to support multiple independent implementations. Since Webkit has neither problems, seeing that: a) it's open source portable to all platforms with ports existing for all major platforms and tons of minor ones. b) it's an engine, not a browser, and as such supports several widely varying browser GUIs, from Safari to Chrome to mobile browsers to command line tools. c) It moves at a fast pace with lots of companies contributing to it, from Apple, to Google, to Nokia, to Adobe, to Samsung, to RIM to ensure that. It doesn't make much sense to use anything else. You could achieve all the dreams Mozilla has AND use Webkit at the same time. Just add your other stuff on top of it, instead of in a completely different implementation. I'm not even against experimenting with new engine ideas. If you need to create a completely different engine do it, but only because there is an important difference and reason to do so. Today we just have different engines not because of some special differentiating factor or novel way, but just because a few companies hold to their old engines from the early days of the Web (namely Mozilla, Microsoft and Opera). Almost everybody else that came after Webkit has adopted it. Some things just make sense to have one single and common base. The same way most of us use, say, OpenSSH, and don't think much about it.
      - thristian 14y ago
        No software is infinitely malleable; no matter how much flexibility or portability you design into a code-base, it'll still only really work in situations that at least resemble the ones in which it was originally designed. Currently, the situations Webkit was designed for are a really good match for the situations we have (desktops, laptops, tablets, phones), and it's very difficult to find a situation where Webkit isn't a great choice. However, if there's one thing to learn from history, it's that situations change and usually in unpredictable ways. I have no idea what possible up-set to the computing landscape could arrive and make Webkit unfeasible, but I'm pretty sure something will change eventually, and wouldn't it be nice if we had a backup plan? Also, consider what might happen if Webkit were the only browser engine. Sure, Webkit moves at a fast pace now, when it has competition from both other browsers and native apps, but consider that the two biggest supporters of Webkit both benefit directly from people using native apps over web-apps. Sure, they benefit from web-apps too, but Apple in particular gets actual revenue directly from native apps, so if they didn't have other browsers to compete with, maybe Webkit wouldn't be as shiny and cutting-edge as it is. I mean, it already renders existing websites, and anything that needs abilities the current web-platform doesn't support can just be implemented as a native app, right? > If you need to create a completely different engine do it, but only because there is an important difference and reason to do so. The thing is, if Webkit were the only browser-engine, even if you did come up with some completely different engine, your idea would be useless. You wouldn't be able to achieve compatibility with existing sites without mimicking all the weird bugs and corner-cases of Webkit, which would not be feasible, and if your idea is so completely different you can't just fork the Webkit code and add your idea on top. > You could achieve all the dreams Mozilla has AND use Webkit at the same time. "all the dreams Mozilla has" is pretty much "make sure there are always multiple independent, interoperable implementations of the Web technology stack", so no, that wouldn't really be possible. :)
  - mattmanser 14y ago
    Hmmm, yeah, we tried that 10 years back. Didn't work.

potch 14y ago

So when a user types '-webkit-', and doesn't type '-ms-,-o-,-moz', when they all work, that's laziness on the vendor's part? Or better yet, when the syntax 'linear-gradient' works and you don't need a prefix at all, and you don't bother because you can't be bothered, that's laziness on the browser vendor's part? The vendors have bent over backwards to be fully compatible on gradients, animations, transition, border radii, box shadows, keyframes, and boat loads more every day. Every vendor makes compromises, the prefixes get removed and the whole web moves forward as one unified. But you'd never know it because hack developers can't be arsed to at least open one other browser to see whether it even worked. But yes, the vendors are lazy.

tomjen3 14y ago
While the w3c likes to think the univrse revolves around it, html5 has several competitors and given that the syntax for a particular css property doesn't matter much, they should have just standalized it the first time a browser added that feature. Beside, why use a non-webkit browser?
- tobylane 14y ago
  What are html5's competitors? Are Opera and Firefox not even notable anymore?
  - tomjen3 14y ago
    Flash, native apps, Silverlight.
- thristian 14y ago
  It's not CSS, but the <canvas> tag was invented by Apple for Safari, and was originally just a thin wrapper around the OS X drawing API, which was (thanks to OS X's heritage) basically just the PostScript drawing API, including all the various Porter-Duff software compositing methods (because they were all naturally supported by the API, so why not). It turns out, a decade later, that most platforms don't want to render PostScript-compatible graphics in software, they want to render graphics with hardware designed for APIs like OpenGL and Direct3D, which don't support all those compositing modes. In particular, I think IE deliberately does not implement most of the <canvas> compositing modes because they can't be hardware accelerated by Direct2D. So "just standardizing the first browser to add a feature" can lead directly to brittle, incompatible implementations, and that hurts the Web for everyone. Sure, you don't want people to wait decades for some feature or other to become widely implemented, but putting a little thought in before standardizing things helps a lot. > Beside, why use a non-webkit browser? Man, when you put it like that, why did we ever leave IE6? You could write your HTML just once and be sure it would work everywhere!
  - pretoriusB 14y ago
    >Man, when you put it like that, why did we ever leave IE6? You could write your HTML just once and be sure it would work everywhere! We left it because a) it stagnated and b) it didn't work on all platforms. Surely not because of some zeal to support multiple independent implementations. Since Webkit has neither problems, seeing that: a) it's open source portable to all platforms with ports existing for all major platforms and tons of minor ones. b) it's an engine, not a browser, and as such supports several widely varying browser GUIs, from Safari to Chrome to mobile browsers to command line tools. c) It moves at a fast pace with lots of companies contributing to it, from Apple, to Google, to Nokia, to Adobe, to Samsung, to RIM to ensure that. It doesn't make much sense to use anything else. You could achieve all the dreams Mozilla has AND use Webkit at the same time. Just add your other stuff on top of it, instead of in a completely different implementation. I'm not even against experimenting with new engine ideas. If you need to create a completely different engine do it, but only because there is an important difference and reason to do so. Today we just have different engines not because of some special differentiating factor or novel way, but just because a few companies hold to their old engines from the early days of the Web (namely Mozilla, Microsoft and Opera). Almost everybody else that came after Webkit has adopted it. Some things just make sense to have one single and common base. The same way most of us use, say, OpenSSH, and don't think much about it.
    - thristian 14y ago
      No software is infinitely malleable; no matter how much flexibility or portability you design into a code-base, it'll still only really work in situations that at least resemble the ones in which it was originally designed. Currently, the situations Webkit was designed for are a really good match for the situations we have (desktops, laptops, tablets, phones), and it's very difficult to find a situation where Webkit isn't a great choice. However, if there's one thing to learn from history, it's that situations change and usually in unpredictable ways. I have no idea what possible up-set to the computing landscape could arrive and make Webkit unfeasible, but I'm pretty sure something will change eventually, and wouldn't it be nice if we had a backup plan? Also, consider what might happen if Webkit were the only browser engine. Sure, Webkit moves at a fast pace now, when it has competition from both other browsers and native apps, but consider that the two biggest supporters of Webkit both benefit directly from people using native apps over web-apps. Sure, they benefit from web-apps too, but Apple in particular gets actual revenue directly from native apps, so if they didn't have other browsers to compete with, maybe Webkit wouldn't be as shiny and cutting-edge as it is. I mean, it already renders existing websites, and anything that needs abilities the current web-platform doesn't support can just be implemented as a native app, right? > If you need to create a completely different engine do it, but only because there is an important difference and reason to do so. The thing is, if Webkit were the only browser-engine, even if you did come up with some completely different engine, your idea would be useless. You wouldn't be able to achieve compatibility with existing sites without mimicking all the weird bugs and corner-cases of Webkit, which would not be feasible, and if your idea is so completely different you can't just fork the Webkit code and add your idea on top. > You could achieve all the dreams Mozilla has AND use Webkit at the same time. "all the dreams Mozilla has" is pretty much "make sure there are always multiple independent, interoperable implementations of the Web technology stack", so no, that wouldn't really be possible. :)
- mattmanser 14y ago
  Hmmm, yeah, we tried that 10 years back. Didn't work.