A post over on Surfin’ Safari, High DPI Web Sites, talks about using SVG, and ways that SVG could be incorporated into current site designs while still maintaining backward compatiblity. The ideas presented are good possible ways to do it, but the way subsequent CSS definitions and advanced selectors are used to “override” the rasterized image feels like a CSS hack (”If only we could find a way to ‘hide’ this problematic CSS definition from browsers that misinterpret it…”; “If only we could find a way to ‘hide’ this problematic SVG file from browsers that don’t understand it…”). While reading this, I immediately though “what about lowsrc?”.
Lowsrc was an attribute on the <img> tag that could be used to specify a smaller, and thus presumably faster downloading, version of an image. The browser would download the lowsrc image first, which was usually a 1-bit color black and white image, and display it as soon as possible. The theory was that the user could begin to “use” the page before all the images were downloaded (back in the day, when page reflow was a big deal because it was so slow, and reflow didn’t happen incrementally, and 56k dialup was the norm). Then the normal, higher resolution image would be downloaded in the background and would replace the lowsrc content after the download was complete. This wouldn’t cause reflow because the lowsrc and src images were supposed to have the same physical dimensions.
For better or for worse, people found a way around the reflow problem. Browsers began to implement incremental rendering/reflow, and computers were becoming fast enough to handle it. In addition, you could usually avoid the problem all together by giving hints to the browser as to how much screen real-estate the image was going to occupy using the “height” and “width” attributes. The page would be rendered using those dimensions, and when the image was finished downloading, it would be resized (if necessary) to fit in exactly that space. No reflow was necessary. In fact, for a long time, finding out the physical dimensions of images and putting height and width attributes on all the <img> tags was the recommended workaround to get image heavy pages to “load” faster (thus forever blurring the line between “loading” and “rendering”, but I digress).
Along with that, other changes, such as bandwidth becoming more plentiful and HTTP/1.1 support for pipelining requests, made downloading and showing a lowsrc image a less attractive workaround for slow downloading pages. Why download a image that is only going to be replaced? The 400 bytes it took to download a lowsrc image was 400 bytes that was not being used to download the real image. There may have also been a need for lowsrc when certain browsers started supporting the questionable, from a web-with-limited-bandwidth standpoint that was prevalent at the time, BMP image format.
Unfortunately, lowsrc was officially depreciated sometime around HTML4, as it appears in DOM Leve 1, but does not appear in HTML 4.0 (forgive me if this isn’t the exact timeline; nevertheless, you can find archived discussions about removing lowsrc from later drafts).
Anyway, back to SVG. SVG is the ultimate high resolution image format, since it is not bound to any specific rasterization, resolution or DPI. As such, if SVG was fully supported as an image format, allowable in the <img> tag just like PNG, JPEG, and *cough* GIF (among others), then adoption would be more painless. At first, I was thinking that perhaps the SVG image could be given as the “src” attribute, and use “lowsrc” for the non-SVG “backup” image if the browser doesn’t support SVG. Once the data is downloaded from the “src” attribute, the browser could degrade gracefully and not replace the lowsrc image if it can not figure out what to do with the SVG data. This is also congruent from an image quality standpoint: the actual source of the image is a device independent, always high resolution SVG. Except in the case of some photographic images, rasterized images are always going to be lower quality, and therefore less preferred, than SVG images. Rasterized images are the new “lowsrc”.
But since “lowsrc” is depreciated, browsers may know about it but not honor it. It was a relatively obscure attribute anyway, even more so now since excessive bandwidth has made page download times a back burner issue, even for the most obscenely large, byte-wise, pages. Even if it was fully supported, it most likely wouldn’t be on the list of recommended things to do to optimize page download times.
What may make sense is adding a “highsrc” attribute to the <img> tag, which has no historical baggage. The only kind of content allowed for “highsrc” would be an SVG document (under the assumption that no image format can be a higher resolution than SVG), and the “height” and “width” attributes would be required also (so the SVG could be properly rendered). Browsers which did not understand “highsrc” would most likely also not know how to render SVG. These browsers would continue to use the src attribute, which is still required for <img>.
Silver Orange Labs documents using SVG graphics in a largely backward compatible way by using the <object> tag. This is good, we can start using SVG earlier rather than later. The drawback to overloading the <object> tag is that the document loses some of the semantic information that comes from using the <img> tag for images; the <object> tag is generic, and rightly so. The alternative content being nested inside the <object> tag is good because it allows something more than just an image or alternative text. But this is a red herring, since so much more is possible with SVG, like interactivity and scripted changes, the alternative content can end up being so severely downgraded as to be useless. I suspect that in many cases, the SVG <object> tag will only contain a single <img> tag, and this image may be used as an ad to encourage people to use a browser that supports SVG. SVG does not need to become PNG, where, because of Microsoft’s half-baked implementation, it got little use for so long, and where it was used, complex ActiveX hacks were need to get proper display. Designers chose not to use PNGs rather than encourage users to upgrade to a more capable browser, and there was really no option to politely suggest to users that they’d have a (albeit slightly) better experience if they upgrade while still remaining function (at least not without browser capability detection on the server to rewrite <img> tags on the fly–arg!, don’t get me started on Accept headers). This may have been acceptable, because, while PNG is a superior format, it does not offer the end user much more than a GIF in the majority of use-cases.
SVG needs to be directly and fully supported as a first-class image type as part of the various HTML standards. Recognizing that it can supplant rasterized image types for most image formats used on the web should give support to making it so. Recognizing that it can also be used for so much more (and is an open and accessible standard) should show that it shouldn’t be relegated to invocation via the general purpose <object> tag.
When the hell is Apple going to get their head out of their asses and catch up with the rest of the Internet? Does anyone else use QuickTime to distribute marketing videos on the Internet? Does anyone else use QuickTime to distribute videos over the Internet that they actually expect people to watch? The entire Apple website is centered around marketing, and I, as the consumer, have to go download some additional tool in order to witness the marketing? Apple, you’ve lost the web-browser-embedded video-via-a-plugin war (although technically, since QuickTime is pretty much a one-trick pony compared to Flash, you barely even showed up at the battle). It does not matter how interesting the video is, or what better kind of quality QuickTime has over Flash-based video, the barrier to entry to have to install yet another thing, just for a rarely used feature, is just too great.
mainly because the interface of things one would actually call “word processors” lend themselves to constant tweaking with the document’s look rather than making you focus on the content. It’s amazing how the speed, quality and content of my writing improves when written in vi. Once the content is written, the act of importing it into some kind of markup program (read “Microsoft Word” in the computer labs the hour before it was due) to do final formatting and print it out was a breeze. These days, I prefer a little more semantic control over the document than that which plain paragraphs of text afford, so give me a wiki syntax (I’m used to