Not really. A lot of DOM tests involve try/catch, and checking whether the exceptions are precisely right. Web applications tend to not intentionally throw exce

Not really. A lot of DOM tests involve try/catch, and checking whether the exceptions are precisely right. Web applications tend to not intentionally throw exceptions. Acid3 also tested some other things like SVG fonts. SVG fonts specification didn't make any sense, browsers were against implementing an under-defined specification not designed to interact with HTML and Acid3 test authors likely realized this, because a lot of tests were like: a web browser can do this or this or this, because we have no idea what the specification requires. You really don't want a standard like this in a web browser. Web browsers implemented bare minimum sufficient for Acid3, but literally nothing else. WOFF won over SVG fonts in the end as it was a better specification, but Acid3 insisted on SVG fonts. Case in point about issues with SVG fonts: what should `<iframe>` in an SVG font do? The specification won't tell you. Some other tests also feel weird. For instance, test 86 is literally checking whether `new Date().setMilliseconds()` returns `NaN`. I mean, that doesn't seem very useful to me, why would anyone pass no arguments to a setter intentionally? Official ECMAScript Conformance Test Suite would be a better place for this test. What I think is fine in Acid3 is CSS selector tests, the rest is honestly kinda pointless. I have the same issue with Acid2, the CSS tests in it were fine, but Acid2 test also decided to include an SGML comments test for who knows what reason. Web browser vendors were against this test, but had to support it anyway. SGML comment test broke real world web sites without providing any real value. Thankfully, this test is now gone from Acid2. I hope Acid4 won't happen or if it will, it will ONLY have CSS tests and won't test anything else. Although, it likely won't (thankfully) due to The Web Standards Project's closure.