It looks like they're leaving out everything in the spec I linked above. Currently this is the only way to persist File objects locally, although it looks like they're planning to make that possible through IndexedDB instead.
The specific requirement for being whitelisted is that it shouldn't have a MIME type that Chrome wants to open inline. Give me a list of extensions that you'd like to see supported and I'll see what I can do.
I can't comment on unannounced engineering efforts, and I certainly didn't mean to imply anything about them.
All I can really say is that if they wanted the primary Gmail client to support offline, then it's my personal opinion that the only tenable way to do that is by having a single code path. Whether there are plans to actually do this I don't know and couldn't talk about if I did.
Attachments should work, with a few caveats. Due to some annoying quirks of the HTML5 FileSystem API, there's a whitelist of supported file extensions. This includes everything useful we could think of, but it's not exhaustive.
One thing we learned early on was that making any existing system (especially one as big as Gmail) work offline had some very difficult, fundamental issues. The biggest of these is that everything that normally happens server-side must also be able to happen client-side when there's no network connection.
This is a problem not only because there is a lot of server-side complexity in Gmail, but also because it changes all the time. New features are added, old behavior is changed, and if the offline code path isn't changed along with it, things have a tendency to break horribly. The only solutions to this involve having every Gmail engineer modify the offline code path whenever they touch the online, which is a large burden that we weren't willing to lay on them.
The primary reason this is Chrome-only is because other browsers don't yet have complete implementations of relevant specs (for example the FileSystem API: http://dev.w3.org/2009/dap/file-system/pub/FileSystem/). I can't make any promises on the team's behalf, but I personally would like to see it working on Firefox as well at some point.
It's not actually true that Sass and Less have the same features. Each has some features the other doesn't, with Sass having substantially more than Less. Notable examples include the ability to use variables in selectors, the @extend directive, and a wealth of useful built-in functions. It's because of these and other features that Compass can be built on Sass, where it couldn't be built on Less.
That's the difference between reference documentation and introductory documentation. You go to reference documentation when you want to look up the details of something you already know; you go to introductory documentation if you want to learn it for the first time.
Software patents have a strong tendency to be both vague and obvious. Although these are supposed to make something unpatentable, this doesn't happen in practice with software patents (possibly due to the relative novelty of software and lack of understanding among non-technical people).
Yes. While combining minification and gzip doesn't produce as dramatic an improvement as either does above plain text, combining them does usually yield some additional improvement (especially if minification handles things like variable renaming in JS or property folding in CSS).
No it's not. Look at it: it's one-selector-per-line, which is a very common style for handwritten CSS. If it were compressed, it would have no line breaks.
I was assuming compiling to JSON wasn't an option since the point of the post was the usefulness of avoiding a manual compilation step. With such a step, yes, you could avoid all the parsing headaches. I'm not sure how useful it would be to manipulate the JSON client-side, but there are probably a few clever things one could come up with.
I'm certainly not afraid of compilers. I write Sass, so I'm pretty intimately familiar with what's going on. My point was not that compilers are inherently scary and/or slow (although I stand by my original point that if it's compiling to CSS it will always be at least somewhat slower). I was just making the claim that the current speed of less.js is too slow for practical production use.