4 ms·

But there's still room for competition with the same codebase. WebKit browsers differ significantly, and still compete with one another. Though this post claim

by just2n 14y ago

But there's still room for competition with the same codebase. WebKit browsers differ significantly, and still compete with one another. Though this post claims to be talking about WebKit, I see something like this: > There’s a bug — background SVG images with a prime-numbered width disable transparency. A year later, 7328 web sites have popped up that inadvertently depend on the bug. Somebody fixes it. The websites break with dev builds. And have to wonder if they're trying to project IE's issues onto WebKit. I used to have a lot of respect for Mozilla. But now that MDN is stagnating, Firefox is a much less inviting development environment than Chrome (oh how things have changed), and with Mozilla talking shit at every turn, I think I have to revoke all respect. Good luck, guys.

jlongster 14y ago
What do you mean MDN is stagnating? There's a constant upkeep going on there, which is difficult considering how fast the web moves but it's constantly being updated.
- just2n 14y ago
  It's becoming less usable (see: JS classes, prototypes were separated in some but not in others) and the information on it isn't keeping up with standards at all. It might be fine for people who are working on browser builds as of about 24 months ago, but it is woefully inadequate for anyone who wants to use something that is even in a draft state or considered stable. A quick example: look at document.cookie. They are referring to DOM2 information. It's undergone some (slight) changes in HTML5. Nothing is referenced, even though that section is relatively stable and marked as safe for implementation. That's a 2000 spec vs a 201x spec. Nobody's even gone in and pointed out that this has changed in HTML5.
  - bzbarsky 14y ago
    I hate to say this, but ... it's a wiki. Have you considered just adding a note to the page pointing out that it needs updating? For example, I had no idea document.cookie got changed in HTML5, and I bet neither did anyone else involved.
daleharvey 14y ago
The post is discussing how people develop against a single engine as opposed to a standard, its not 'projecting' and certainly not 'talking shit' about webkit
- rimantas 14y ago
  If developing to standard gives you the same result on each engine then the number of them does not matter. What if I develop to standard but only test in Webkit. My page is broken in Gecko though. Whose fault is that, Webkit's, Gecko's or mine? If it's mine then why? I did everything according to standards. So in reality you don't develop against standards (alas), you develop against their implementations, and having multiple engines helps in no way.
  - daleharvey 14y ago
    In reality you develop against multiple implementations that attempt to adhere to the same standard, where they break in between is where the standard or the implementations need fixed, differences in assumptions agreed and ambiguities clarified. That was the point of the blog post?
  - bzbarsky 14y ago
    In reality, most web developers have no clue about what the standard says in edge cases, which is just fine: neither do most other people. But the result is that it's very rare to find cases that are really developed "to standard". Even worse, though, on mobile right now people aren't even trying to develop to standards. UA sniffing and locking out of non-WebKit UAs and use of -webkit-prefixed things even when standard alternatives are available is rampant and purposeful. And when you ask these people to develop to standards they just laugh at you.
- just2n 14y ago
  I disagree entirely. This is an inflammatory piece that is factually full of nonsensical claims that don't and haven't held up. It makes HUGE assumptions that have direct contradictions in practice. I don't see how anyone could take it seriously. As for not "talking shit" about WebKit, let's look at that one claim: > Backwards bug compatibility This is obviously pointed at what IE did after years of maintaining the same bugs that people relied on. The article actually figured out WHY this happened: taking a year to fix a MAJOR issue results in people relying on it. IE was always updated very, very slowly. Nobody else really had this problem, and IE is the one who instilled major flaws as "features" and refused to correct them later on. This very much describes exactly what Microsoft did with IE. But then they try to ascribe that, somehow, with major handwaving as a problem that will be seen if everyone uses the same code base. This coming on the heels of Opera deciding to use WebKit. It's very clear they are making the claim that the same problems IE was having would be caused by WebKit. This is called talking shit. The problem is that these problems were caused by a well known phenomenon: taking years to fix major issues. Google has maintained a PHENOMENAL rate of development on their own browser, and they aren't even competing with Mozilla anymore, they're way out in front. Pushes to stable are slower but Canary is updated almost daily. I've seen major bugs and regressions get fixed in HOURS. And I've seen independent players issue patches to fix problems. This is a picture that is antithetical to IE. It is the POLAR OPPOSITE of the scenario under which this problem initially became so egregious. There is no basis for this claim. And to the point that we "NEED" multiple implementations of a standard to find where things are ambiguous, please feel free to peruse the discussion groups at your leisure. Not only are these ambiguities discussed without referencing Firefox, IE, or anyone else, but they're often resolved with changes in the implementation or, rarely, in the spec. This would be an impossibility if we all worked on 1 code base, clearly.

by just2n 14y ago

jlongster 14y ago

What do you mean MDN is stagnating? There's a constant upkeep going on there, which is difficult considering how fast the web moves but it's constantly being updated.

just2n 14y ago
It's becoming less usable (see: JS classes, prototypes were separated in some but not in others) and the information on it isn't keeping up with standards at all. It might be fine for people who are working on browser builds as of about 24 months ago, but it is woefully inadequate for anyone who wants to use something that is even in a draft state or considered stable. A quick example: look at document.cookie. They are referring to DOM2 information. It's undergone some (slight) changes in HTML5. Nothing is referenced, even though that section is relatively stable and marked as safe for implementation. That's a 2000 spec vs a 201x spec. Nobody's even gone in and pointed out that this has changed in HTML5.
- bzbarsky 14y ago
  I hate to say this, but ... it's a wiki. Have you considered just adding a note to the page pointing out that it needs updating? For example, I had no idea document.cookie got changed in HTML5, and I bet neither did anyone else involved.

daleharvey 14y ago

The post is discussing how people develop against a single engine as opposed to a standard, its not 'projecting' and certainly not 'talking shit' about webkit

rimantas 14y ago
If developing to standard gives you the same result on each engine then the number of them does not matter. What if I develop to standard but only test in Webkit. My page is broken in Gecko though. Whose fault is that, Webkit's, Gecko's or mine? If it's mine then why? I did everything according to standards. So in reality you don't develop against standards (alas), you develop against their implementations, and having multiple engines helps in no way.
- daleharvey 14y ago
  In reality you develop against multiple implementations that attempt to adhere to the same standard, where they break in between is where the standard or the implementations need fixed, differences in assumptions agreed and ambiguities clarified. That was the point of the blog post?
- bzbarsky 14y ago
  In reality, most web developers have no clue about what the standard says in edge cases, which is just fine: neither do most other people. But the result is that it's very rare to find cases that are really developed "to standard". Even worse, though, on mobile right now people aren't even trying to develop to standards. UA sniffing and locking out of non-WebKit UAs and use of -webkit-prefixed things even when standard alternatives are available is rampant and purposeful. And when you ask these people to develop to standards they just laugh at you.
just2n 14y ago
I disagree entirely. This is an inflammatory piece that is factually full of nonsensical claims that don't and haven't held up. It makes HUGE assumptions that have direct contradictions in practice. I don't see how anyone could take it seriously. As for not "talking shit" about WebKit, let's look at that one claim: > Backwards bug compatibility This is obviously pointed at what IE did after years of maintaining the same bugs that people relied on. The article actually figured out WHY this happened: taking a year to fix a MAJOR issue results in people relying on it. IE was always updated very, very slowly. Nobody else really had this problem, and IE is the one who instilled major flaws as "features" and refused to correct them later on. This very much describes exactly what Microsoft did with IE. But then they try to ascribe that, somehow, with major handwaving as a problem that will be seen if everyone uses the same code base. This coming on the heels of Opera deciding to use WebKit. It's very clear they are making the claim that the same problems IE was having would be caused by WebKit. This is called talking shit. The problem is that these problems were caused by a well known phenomenon: taking years to fix major issues. Google has maintained a PHENOMENAL rate of development on their own browser, and they aren't even competing with Mozilla anymore, they're way out in front. Pushes to stable are slower but Canary is updated almost daily. I've seen major bugs and regressions get fixed in HOURS. And I've seen independent players issue patches to fix problems. This is a picture that is antithetical to IE. It is the POLAR OPPOSITE of the scenario under which this problem initially became so egregious. There is no basis for this claim. And to the point that we "NEED" multiple implementations of a standard to find where things are ambiguous, please feel free to peruse the discussion groups at your leisure. Not only are these ambiguities discussed without referencing Firefox, IE, or anyone else, but they're often resolved with changes in the implementation or, rarely, in the spec. This would be an impossibility if we all worked on 1 code base, clearly.