I recently finished rewatching the whole of the Stargate franchise with Carey. Here is the order in which I would recommend watching the show. This order optimises for avoiding spoilers (references to other episodes always happen after you've seen the corresponding episode), and where possible given that constraint, avoids switching back and forth between SG-1 and Atlantis so that you can watch as many episodes of one show back to back as possible without having to switch series.
Stargate SG-1, episodes 1.1 to 8.2
Stargate Atlantis, episodes 1.1 to 1.15
Stargate SG-1, episodes 8.3 to 8.20
Stargate Atlantis, episodes 1.16 to 2.1
Stargate SG-1, episodes 9.1 to 10.2
Stargate Atlantis, episodes 2.2 to 3.4
Stargate SG-1, episodes 10.3 to 10.12
Stargate Atlantis, episodes 3.5 to 3.19
Stargate SG-1, episodes 10.13 to 10.20
Stargate: The Ark of Truth
Stargate Atlantis, episodes 3.20 to 5.1
Stargate Atlantis, episodes 5.2 onwards.
For the most entertainment, avoid watching "previously on" segments. Some of the "previously on"s are really bad spoilers and actually ruin the whole episode. To avoid watching them, the easiest thing to do is to mute the sound and wait for the light from the screen to fade to black. Simiarly, avoid watching the credit sequences at the start of each episode, as they tend to give away major plot points. Just look away and wait for the end of the music. (I used to try and fast-forward but unless you have a very responsive player I find that it ends up taking more time than just waiting through it.)
(I similarly recommend not watching commentaries for one season until you have seen the last episode of the next season, as the commentaries are recorded as the writers are preparing the next season, so they sometimes accidentally give things away.)
The characteristics that make me love the Stargate franchise are that it is internally self-consistent, it doesn't take itself too seriously, things that happen in one episode do affect future episodes, the main characters aren't immortal, and it is technically a very well-produced show. It doesn't reset to zero with each episode (StarTrek), or ridiculously over-use hand-held camera effects (Battlestar Galactica). It has a reliably well-written score.
As with everything with Acid3, the update I did earlier today ended up being more complicated than expected. It turns out the SVG working group got their errata wrong (instead of changing the strange requirement to a sensible one, they changed it to another strange requirement, and I doubt that's what they intended it to be).
At the same time, the CSS working group contacted me and asked for a change because apparently media queries rules for handling bogus keywords are in flux, and despite the interoperability we have today because of Acid3, they still want to change the behaviour to an arguably more sensible one. ☺
I've commented out the relevant parts of the test (you can see the commented out bits — search for "COMMENTED OUT" in the source), so that browsers and users using Acid3 as a vague indicator of compliance aren't subject to the prevailing winds on these minor issues. (WebKit and Opera builds should be back to 100/100.)
When Acid3 was written, I only tested specs that had been marked as "done" (in CR) for three years or more. Apparently specs take more than three years to bake! Oh well.
When we do Acid4 (probably around the time we have at least three major browsers shipping Acid3-passing browsers), I think we'll have to focus on testing fewer, more critical things. Acid3 tests a lot of critical stuff, but also checks a lot of less important stuff at the same time, and it's in those areas that we've had the most problems with specs changing under us.
In the meantime, if you want a weekend project, try printing out the Acid tests in various browsers and seeing if you can track down the bugs! There might be some legitimate differences due to the different media type, but in theory most bits of the tests should render fine. In my brief testing, the browsers seem to do much worse than I expected.
One of the bugs that Acid3 found was actually a problem with the SVG spec, apparently. The SVG spec errata will be updated to say that getSubStringLength() shouldn't throw when accessing the last character. This affects Acid3 test 77. For details, see Erik's post to public-svg-wg. I have updated the actual test now, which is why WebKit just dropped down to 99, but I expect that will be fixed soon.
I love my job. I really do. I work with some of the brightest
people I know, on something that is directly affecting literally a
billion people, from all walks of life, and which has the potential to
eventually reach everyone alive (except maybe these
Not only that, but I find what I work on to be fascinating,
interesting, and challenging. I'm in the enviable position of being
someone who is paid to do his hobby as a job. Some people wonder what
they would do if they didn't have to go to work, but I know
what I would do: standards development is exactly what I did, as a
hobby, the year I spent seeking a job in the Bay Area between when I
got my BSc and when I finally gave up and took Håkon up on his
job offer in Norway.
I've even managed to find an employer who not only lets me work
full time on improving the Web, but actually gave me specific
instructions to not put the company's short-term interests ahead of
the Web's, something which is frankly unheard of in the industry.
David Baron of Mozilla discovered some errors in the Acid3 test. It turns out that the Media Queries draft changed between 2002 and 2007, and I was testing things as they stood in the 2002 version of the specification! This has now been fixed. He also found a logic error that I'd made, which I have also fixed.
I'm really glad to see the Acid3 test being reviewed so carefully. With something so complex it's always possible that there are more errors, though, so if you find any more please let me know!
On a related note, the lasttwo posts I made discussed the performance aspect of Acid3, and how to determine if a browser has passed the "smoothness" criteria. While I covered how to test browsers that run on regular laptop computers, there are of course a lot of browsers out there that run on computers that aren't, and never will be, as powerful as high-end laptops. So for the record: if the test is run on a slow computer or device, it may run slowly or not smoothly and this does not imply non-conformance.