BurningbirdRecovered from the Wayback Machine.
For those iPhone users, bereft at loosing the I am Rich Ruby, no worries: I give you the I Am Dirt Poor Ruby, in SVG.
Now, after Safari/Webkit properly builds in support for the Gaussian blur filter in SVG, you can impress your friends and still pay rent!
(derived from ruby)
Recovered from the Wayback Machine.
I gather Al Gore is joining the lineup for the Web 2.0 Summit in September. In his weblog, John Battelle writes:
Those of you following my posts around the theme of this year’s Web 2 Summit already know that we’re expanding the scope of the conference this year, and asking a core question: How can we apply the lessons of the Web to the world at large?
I have to ask: is an invite-only conference for the elite with primarily white, male speakers really the place to answer this question? Especially a conference beginning the day after we (hopefully) elect a black man for president?
Recovered from the Wayback Machine.
GigaOM has been spending considerable time lately covering issues of broadband congestion and possible broadband capping—not without some overt hostility expressed by regular readers, who seem to think the issue is one of “selfish” users impacting on the quality of broadband for all. Previous entries are Yo FCC! Are You Doing Anything About Metered Broadband and Warning Sign: Metered Broadband Already a Hassle.
Today, Stacey Higginbotham points to a new report by Free Press that addresses the reality of broadband congestion, as well as providing good alternatives to the caps that current ISPs are considering using.
According to the PDF report, how much congestion there is in broadband is open for debate. For instance when Bell Canada started application throttling it admitted during an investigation of its practice that there was “almost no congestion…”. I would not be surprised to see the same with networks here, including ATT with its talk of the use of caps being “inevitable”.
In addition, the report also provided some very real, effective solutions that are much better than capping—including throttling during peak usage, whereby a person’s bandwidth speed would be reduced to a certain level during congested hours. This is a superior solution because, as the report expresses eloquently, caps will impact on everyone’s use of broadband:
Compared to limitation pricing, limitation throttling also makes better sense for ISPs. Limitation pricing (especially with low caps) will modify the behavior of almost all users. With everyone watching the meter, this pricing model will inevitably lead even casual users to spend less time online or to avoid applications that use high amounts of bandwidth—the very applications that are response for the increases in the perceived value of broadband access of customers.
This pattern of changing behavior will inevitably cause the marginal customer to question the need for the connection in the first place, leading to a possible slowdown in the growth of new customers for ISPs.
The report also covers the issue of caps in other countries, such as Australia, New Zealand, Belgium, and Canada, but explains that much of the traffic in these countries is asymmetric, with traffic one way. This is more expensive than what we’re facing in this country, where we produce most of the online material we consume. As it is, most other countries also have much more competition among providers than we do in the States.
In addition to capacity issues, the report discusses the US’s declining position as technical “leader” in the world, a position that could only be degraded if we were to throttle an essential resource like the internet.
At issue is not that broadband companies are becoming overwhelmed, but that the same companies providing broadband are beginning to perceive that online video offerings such as Netflix WatchNow, Hulu, iTunes, and so on could become an eventual threat to their bread-and-butter operations: offering entertainment packages. Capping broadband use to prevent competition is against the law in this country. If this is the situation, when reason fails, the courts will then need to become engaged. I have to think the ISPs know this, and such knowledge will give them pause.
Chapter 7 in the book (Painting the Web) provides an introduction into some of the many useful elements in SVG. Included is a discussion of the two gradients, linearGradient and radialGradient. They can’t be used to create a visual element by themselves, but are, instead, used to fill any shape that takes the fill attribute. For instance, one of the book examples defines four radialGradients, which are then used to fill four different circles. The last two circles in the example demonstrate how the radialGradient can be used to provide spherical highlights, especially when using a monochromatic color scheme, as shown in the fourth circle.
The following is the radialGradient definition used to fill the fourth circle in the example:
<radialGradient id="gradient4" cx="20%" cy="20%" r="100%" fx="30%" fy="30%">
<stop stop-color="white" offset="0%" />
<stop stop-color="#666" offset="50%" />
<stop stop-color="black" offset="100%" />
</radialGradient>
The stop elements are used to define the colors for the gradient, in this case white from 0 to 50%, and then gray from 50% to 100% black. SVG user agents, like the browser you’re using (which, hopefully, supports SVG), derive the radialGradient from these stops in combination with the other radialGradient attributes. From the example given, these attributes are:
In the example, the focal point of the radial gradient is set to 30% along both x and y axis, which places it in the upper-left. If both were set to 50%, then the focal point would be in the exact center of the gradient.
An attribute that was not given explicitly in the previous examples was the spreadMethod, which provides instruction in how to fill the shape when the radialGradient is smaller than the containing element. The possible values are: pad, spread, and repeat, with pad being the default.
In the third example, three circles are filled with three different radialGradients. The cx and cy values are 30%, the fx and fy values are 20%, the length is 50%. All that differs between the circles is spreadMethod, which is, from left circle to right: reflect, repeat, and pad. The reflect value causes the gradient to repeat, from the outside in; the repeat value repeats the pattern literally, which can lead to rather abrupt transitions; the last option, pad, fills in the remaining area of the circle with the color given for the 100% stop.
When creating radialGradients, you’re not restricted to three stops or different saturations of the same color. The following SVG example has a radialGradient that uses 6 different stops, with six different colors, creating a nice neon light effect. The radialGradient is then used to fill a rectangle, rather than a circle.
Four issues with the radialGradient, all specific to browsers. I’ve found that the reflect spreadMethod can cause minor havoc with the Firefox 3.x browser in the Mac, pushing down the size of the area, without necessarily impacting on the visual rendering. This makes it a bit tricky to define a view port, or include the SVG using the object element. Opera 9.5b has some rendering delays when using gradients, and Safari/Webkit doesn’t respect the object’s transparent background. You’ll also need to use a SVG plug-in with Internet Explorer. I’ll have more on the issues of browser SVG support in a follow up writing, which I’ll link here when finished.
To see radialGradient in action, check out the following from Open Clip Art:
Dave Pena’s Sakura, which uses opacity and the radialGradient to create the soft hues and gradual coloration. This image was pulled from the downloadable archives.
A wonderful workstation by Kobo. Notice the hard “light streak” across the monitors? I discuss this use of a light streak to provide an impression of a hard, shiny plastic surface in the book.
A tasty cake from Jean Victor Balin.
Zipped files of all the book examples can be downloaded from the O’Reilly book support site.
37signals is phasing out support for IE6. The company weblog lists the reasons for this decision, including:
IE 6 is a last-generation browser. This means that IE 6 can’t provide the same web experience that modern browsers can. Continued support of IE 6 means that we can’t optimize our interfaces or provide an enhanced customer experience in our apps. Supporting IE 6 means slower progress, less progress, and, in some places, no progress. We want to make sure the experience is the best it can be for the vast majority of our customers, and continuing to support IE 6 holds us back.
Those are excellent reasons, and ones we should be taking to heart. At issue, though, is the fact that Microsoft has made it very difficult to eliminate IE6.
When Microsoft rolled out IE7, it did so only in newer generation operating systems, such as Windows XP and Vista. This left a large contingent of users of IE6 on Windows 2000, which is still in fairly wide use. The company also didn’t post recommendations for W2K users to switch to a different browser, such as Firefox or Opera. Both actions served to leave a bloc of orphaned IE6 users, many of whom are still haunting our web sites.
I also don’t give much credence to those bemoaning the burden that dropping support for IE6 would have on corporations, libraries, and schools. It is not an onerous task to install Firefox on people’s machines. Nor is it an impossible task for sites to update their software. If two years since the release of IE7 isn’t enough time, what is the right amount of time? Five years? Ten? At some point, we’re faced with biting the bullet, and doing so before IE8 is released seems to be a good time to crunch down.
The single biggest hindrance to expansion on the web today is IE6. We can’t use transparent PNGs because of IE6. Anything but the most rudimentary uses of JavaScript becomes a problem with IE6. Our sites are full of workaround CSS and page markup existing only to support IE6. We are, in effect, grand prix racers stuck behind some old cow left in the road by farmers who have decided they like pigs, better. Oink.
I don’t support IE6, and not just because most of my readers are using new browser versions. I don’t have a separate machine I can keep at IE6 in order to test my pages. Since we can’t run IE6, IE7, and IE8, simultaneously, I made a choice to support the two newer versions of IE, which are, themselves, enough of a challenge. For the older browser users, I provide the printer friendly pages with all JavaScript and CSS stripped out. It may not be an optimum solution, but neither is supporting IE6 until all the older machines are piles of rust.
I do hope that 37signals begins a trend.
(via Simon)
update
As Ralph points out in comments, yes we can use PNGs with IE6, if we use IE specific filters. I’ve not had the best of luck with IE6 and PNGs, and typically just hide my PNGs from IE6 with CSS. But then, I decided with the first beta of IE8 that I was not going to create specific code for IE6 any longer. Two versions of any browser is enough.
Ralph also notes the PNG8 workaround for IE6. However, using this technique does not ensure that an image is going to look as good in IE6 as it does in other browsers. I’ve not tried this with GIMP, and I don’t have a version of IE6 for testing, but is an option for those still having to support IE6. However, as the Cozi Tech Blog mentions:
We have since decided that we will no longer make heroic efforts to get our web application looking just as good on IE6 as it does in modern browsers. Quite apart from the extraordinary amount of pain we endured in the Affair of the Transparent PNGs, fighting with IE6 has been a huge timesink for us, especially when it comes to working around its CSS bugs.
A significant fraction of our users are still using IE6, so we have no choice but to support it. However, we no longer aim to achieve full parity.
If sites still support IE6, but at a minimum, as I do with my sites, this also may finally force the issue and hasten the EOL for this browser.
