Author: Shelley Powers

Categories
Specs Technology

Harmony

Harmony is a very good thing.

For some time now, the ECMAScript working groups have been split into two camps: one supporting ECMAScript 4, another ECMAScript 3.1. The former was a more radical leap forward in ECMAScript (JavaScript), while the latter favored more incremental progress.

Ajaxian, John Resig, Simon Willison, and a host of others are referencing an email by Brendan Eich to the lists for both efforts about a new, combined effort dubbed “Harmony”.

Eich writes:

It’s no secret that the JavaScript standards body, Ecma’s Technical Committee 39, has been split for over a year, with some members favoring ES4, a major fourth edition to ECMA-262, and others advocating ES3.1 based on the existing ECMA-262 Edition 3 (ES3) specification. Now, I’m happy to report, the split is over.

The Ecma TC39 meeting in Oslo at the end of July was very productive, and if we keep working together, it will be seen as seminal when we look back in a couple of years. Before this meeting, I worked with John Neumann, TC39 chair, and ES3.1 and ES4 principals, especially Lars Hansen (Adobe), Mark Miller (Google), and Allen Wirfs-Brock (Microsoft), to unify the committee around shared values and a common roadmap. This message is my attempt to announce the main result of the meeting, which I’ve labeled “Harmony”.

Executive Summary

The committee has resolved in favor of these tasks and conclusions:

1. Focus work on ES3.1 with full collaboration of all parties, and target two interoperable implementations by early next year.

2. Collaborate on the next step beyond ES3.1, which will include syntactic extensions but which will be more modest than ES4 in both semantic and syntactic innovation.

3. Some ES4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony.

4. Other goals and ideas from ES4 are being rephrased to keep consensus in the committee; these include a notion of classes based on existing ES3 concepts combined with proposed ES3.1 extensions.

The rest of the email then gives the details.

As one can read in comments out and about, not everyone is pleased by this new accord, as they don’t see that the new effort represents enough progress. However, without accord from all the major browser developers, there is no progress: only variations of pretty chaos.

I must admit, being somewhat conservative — or perhaps, after having worked with JavaScript since the first glimmerings over 12 years ago, exhausted with dealing with browser differences — that I’m happy we’re going for simpler changes, implemented broadly. This is a good thing.

Categories
SVG

I am dirt poor

Recovered 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)

Categories
Political Social Media

Al Gore joins gated community conference

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?

Categories
Internet

The Truth on Broadband Congestion

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.

Categories
SVG

SVG Gradient

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:

 

  • cx and cy define the size of the radialGradient’s outer circle and are equal to the 100% stop value
  • r is the length (size) of the gradient circle
  • fx and fy are the focal point for the gradient, equal to the 0% stop value

 

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.