Rob Sayre's Mozilla Blog

Steve Souders: CSS Sprites are a way to make your web pages faster. A sprite combines multiple background images into a single image. This reduces the number of downloads in the page. Most major websites use sprites, but they’re a pain in the neck!

Sprites have the advantage of working right now, but maybe there should be a way to serve up a multipart response with your sprite images as well. That would cut down on CSS rule count and maintenance, but still group the images in one HTTP request. Authors are already giving up the advantages of separate resources in return for speed, so maybe this is worth doing.

You can (in theory… haha) get some of these advantages with HTTP pipelining, but a multipart response would allow the server optimize the response order as they do with sprites today.

Update: more from vlad

Mark is going try working on Vanilla full time. Mmmm, beans.

Julian Seward has joined Mozilla. Julian is the original author of Valgrind and bzip2. He’s also worked on the Glasgow Haskell Compiler and at ARM Ltd.

Initially, he’ll be focusing on the nanojit component we share with Adobe. Here’s a start.

Steve Yegge: “Shit is NOT easy. Remember that. Shit is NOT easy. If you think it’s easy, then you are being naïve. You are being a future VP. Don’t be that way.”

There are lots of obsolete laws on the books.

Sam Ruby: The goal here is not to repeat the exercise where people present use cases and continue to have the HTML working group be a gatekeeper and king maker and sole determinant as to which features are permissible and which are not in the open web. Specifically, if RDFa is “out”, then I see HTML5 and XHTML2 continuing their separate ways.

I don’t see a problem with HTML5 and XHTML2 continuing their separate ways. I do see a problem with some features being made part of HTML. Examples include a laughably underspecified SQL syntax, a video element that isn’t interoperable, and an RDF syntax that uses namespaces in text/html and QNames in content. Maybe we can all agree that those examples don’t belong in the HTML specification at this point. But then the problem shifts to one of endorsement. People want the HTML specification to tell them what they’re doing is OK. I don’t think the HTML document should do that either.

Sam is right that author conformance requirements are contentious and rooted in non-technical matters. I would say the same is true of distributed extensibility mechanisms, XHTML, and other issues that have landed in the HTML WG. My plan is to produce a draft that is smaller than my last one. It will not include XHTML of any kind, and it will characterize elements and attributes that are not defined by the HTML specification as “not part of HTML”. This characterization will apply to the <audio> element and RDFa alike.

People interested in continuing work on XHTML, RDFa, <audio>, and a host of other things should work to produce interoperable implementations of their technology. Versions of the HTML specification targeting later dates, such as Ian Hickson’s excellent draft, will probably incorporate successful efforts.

This rule is not just for startups.

I’m happy to see it applied to our download pages.

I recently nearly missed a meeting because the notice was only distributed as a .doc file.

I’m delighted to report that I wasn’t sure what program I would use to open the file once I learned of its existence. It happened to be readable in the OS X program TextEdit.

Bruce Schneier: “The solution is to better design security systems that assume uneducated users”

I covered this issue a few years ago. The Mozilla project still hasn’t grasped this concept, but I remain optimistic.

<Hixie> i would be really impressed if i ever saw a blind or text mode user actually successfully navigating an svg file using <title> or <desc>

more

Mike Ash: “I guarantee that if you run it for the first time on any substantial base of Cocoa code, you will be surprised and frightened at what it finds.”

Mike is talking about Clang, in a post I found via Brent Simmons. Dave Orchard also mentioned it.

My Mozilla coworker Nicholas Nethercote has been working on the OS X version of Valgrind.

I decided to poke around my macbook’s Applications folder with this tool. It wasn’t pretty.

==65875==
==65875== Thread 9:
==65875== Mismatched free() / delete / delete []
==65875== at 0xC6E607: operator delete(void*) (vg_replace_malloc.c:341)
==65875== by 0x602DEA: (within ./Skype)
==65875== by 0x21E1F51: thread_start (in /usr/lib/libSystem.B.dylib)
==65875== by 0xFFFFFFFF: ???
==65875== Address 0x7f02830 is 0 bytes inside a block of size 72 alloc'd
==65875== at 0xC6DC6F: operator new[](unsigned long) (vg_replace_malloc.c:260)
==65875== by 0x6020E2: (within ./Skype)
==65875== by 0xFFFFFFFF: ???

We’ve been running Valgrind on the Linux version of Firefox for years, so we’re doing better than most (there are also some false positives that we ignore using a suppression file). It is possible to browse the Web and otherwise interact with the program without triggering endless streams of warnings. Unfortunately, I can’t say the same thing for any other application I checked, or the OS itself.