4 ms·

I've heard people say this about Acid 3 before, but without justification. To me, it appears that the tests for Acid 3 were neither chosen at random, nor arbit

by pohl 17y ago

I've heard people say this about Acid 3 before, but without justification. To me, it appears that the tests for Acid 3 were neither chosen at random, nor arbitrarily. They were specifically selected so that every major browser failed at the time of its release. Moreover, tests were specifically selected to emphasize modern, DHTML (a.k.a "web 2.0") apps: with the bulk of the tests being in DOM, DOM2, and EcmaScript. Only one out of the 6 "buckets" do not - and those were chosen from a competition designed to include things the web community wanted. It's not like hixie threw darts at a board to get the tests. http://en.wikipedia.org/wiki/Acid_3#Standards_tested http://en.wikipedia.org/wiki/Acid_3#Standards_tested

Periodic 17y ago
A huge part of making the web easy to develop for is having things fail in predictable ways. There is very little that is more frustrating than making a few changes to your website and having it suddenly break in one of the major browsers and spending a day figuring out that it's because of a small edge case that doesn't follow the standard model.
boucher 17y ago
I think that almost by definition tests which fail in every major browser shouldn't be considered a high priority. It's nice that they have been fixed in some browsers, but I can't fault IE for prioritizing other things more.
- steveklabnik 17y ago
  But they now _don't_ fail in every browser, because everyone else didn't slack off and actually implemented them. I tested this earlier today, and Chromium get 100/100, FX3.5 on Linux got 97/100, and FX Windows 3.5.5 here gets 93/100. IE8 gets 12.
  - boucher 17y ago
    In my mind, this still isn't a particularly good reason to do it. Let's say the last 9-12 months is when ACID3 became compliant in most browsers (I think it's actually less). That means, by definition, only apps written in that timeframe even had an opportunity to use whatever features were previously broken. This is a tiny percentage of code on the web. Now, it could be that ACID3 is testing the 100 most useful things that previously did not work. Somehow, though, I doubt that's really the case. And even if it was, there are without a doubt 100 more important bugs in IE to fix. So, yes, ACID3 compliance is pretty low on my wishlist for IE bugs to fix. If they were fixing ACID3 bugs and letting more important things fall through the crack, I would be even more displeased with IE.
    - pohl 17y ago
      That's a fair perspective, but I'm left wondering if it sounds good only because it's very nebulous and hypothetical. I wonder if it would sound as good if you were to be more concrete. In particular, would you mention (or, at least, loosely characterize by subsystem or specification) some of the bugs in IE that you would consider a higher priority? I'm asking because all of the following appear fundamental to me: DOM Traversal, DOM Range, DOM2 Core, DOM2 Events, DOM2 Views, DOM2 Style, CSS3 selectors, ECMAScript conformance & garbage collection, the behavior of HTML forms when manipulated by script, the HTTP 1.1 Protocol... I admit that there are 4 tests for SVG and 2 for SMIL that could be placed at a much lower priority, and if IE were sitting at 94/100 for missing those then I might agree with you. (Those were among the bucket 5 tests that arrived via the contest.)
      - boucher 17y ago
        But you are also speaking in broad strokes. For example, "DOM Traversal" is something that IE can do. How critical are the specific features of DOM Traversal that the ACID 3 test is testing? I don't want to spend much time doing bug triage for IE, I'm just saying it's not hard to imagine that their priorities don't include bugs which were obscure only a year ago.
        pohl 17y ago
- pohl 17y ago
  That would make a lot of sense to me if I were to let myself believe that Microsoft just didn't have the resources required to keep up. It's more likely that they just don't want the web to obviate their platform, and so they're dragging their heels.

by pohl 17y ago

Periodic 17y ago

A huge part of making the web easy to develop for is having things fail in predictable ways. There is very little that is more frustrating than making a few changes to your website and having it suddenly break in one of the major browsers and spending a day figuring out that it's because of a small edge case that doesn't follow the standard model.

boucher 17y ago

I think that almost by definition tests which fail in every major browser shouldn't be considered a high priority. It's nice that they have been fixed in some browsers, but I can't fault IE for prioritizing other things more.

steveklabnik 17y ago
But they now _don't_ fail in every browser, because everyone else didn't slack off and actually implemented them. I tested this earlier today, and Chromium get 100/100, FX3.5 on Linux got 97/100, and FX Windows 3.5.5 here gets 93/100. IE8 gets 12.
- boucher 17y ago
  In my mind, this still isn't a particularly good reason to do it. Let's say the last 9-12 months is when ACID3 became compliant in most browsers (I think it's actually less). That means, by definition, only apps written in that timeframe even had an opportunity to use whatever features were previously broken. This is a tiny percentage of code on the web. Now, it could be that ACID3 is testing the 100 most useful things that previously did not work. Somehow, though, I doubt that's really the case. And even if it was, there are without a doubt 100 more important bugs in IE to fix. So, yes, ACID3 compliance is pretty low on my wishlist for IE bugs to fix. If they were fixing ACID3 bugs and letting more important things fall through the crack, I would be even more displeased with IE.
  - pohl 17y ago
    That's a fair perspective, but I'm left wondering if it sounds good only because it's very nebulous and hypothetical. I wonder if it would sound as good if you were to be more concrete. In particular, would you mention (or, at least, loosely characterize by subsystem or specification) some of the bugs in IE that you would consider a higher priority? I'm asking because all of the following appear fundamental to me: DOM Traversal, DOM Range, DOM2 Core, DOM2 Events, DOM2 Views, DOM2 Style, CSS3 selectors, ECMAScript conformance & garbage collection, the behavior of HTML forms when manipulated by script, the HTTP 1.1 Protocol... I admit that there are 4 tests for SVG and 2 for SMIL that could be placed at a much lower priority, and if IE were sitting at 94/100 for missing those then I might agree with you. (Those were among the bucket 5 tests that arrived via the contest.)
    - boucher 17y ago
      But you are also speaking in broad strokes. For example, "DOM Traversal" is something that IE can do. How critical are the specific features of DOM Traversal that the ACID 3 test is testing? I don't want to spend much time doing bug triage for IE, I'm just saying it's not hard to imagine that their priorities don't include bugs which were obscure only a year ago.
      - pohl 17y ago
pohl 17y ago
That would make a lot of sense to me if I were to let myself believe that Microsoft just didn't have the resources required to keep up. It's more likely that they just don't want the web to obviate their platform, and so they're dragging their heels.