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.

AjaxianJohn ResigSimon 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
Specs

The Secret of HDTV

Recovered from the Wayback Machine.

Popular Mechanics has an excellent article of the dirty little secret of HDTV: that there are no true standards or specifications in place defining what exactly is “high definition TV”. Because of this, the article’s writer, Glenn Derene, writes, the quality of broadcast we get from providers, varies. Considerably.

For instance, compression techniques can differ, with fast action shows needing more updates than “talking head” shows. Compression can degrade with the faster shows, than the ones that are more “static”, and with fewer moving parts. This explains to me why the news shows are the best looking shows on my HDTV.

Categories
HTML5

Blaming the W3C for a proprietary web

I hope my last post on the W3C processes does not come off sounding like I’m jumping on to the “Down with the W3C” bandwagon advocated by others in the web development community. That couldn’t be further from the truth. If anything, I would not be as frustrated if I wasn’t such a big supporter of the W3C and its work. I certainly find the W3C’s effort to be more open than anything put out by Microsoft or Adobe.

In particular, I found Paul Ellis’ A Propriety Web? Blame the W3C to be disingenuous, at best.

He writes:

This may seem like a forgone conclusion to many of you after seeing the W3C’s development timetables, but the real reason Flash and Silverlight exist is because the “open web” people dropped the ball. HTML simply can handle what Flash and Silverlight can do. It has become increasingly stale for modern web development needs.

Here is some perspective, HTML5 has finally added a tag for handling video. Flash 6 came out with video support in 2002! Where is the HTML version of Line Rider? It is in Flash and Silverlight now. If you want to see something really interesting check out Hard Rock Cafe’s memorabilia page (Silverlight 2 required) and tell me if you’ve ever seen something like that with HTML.

The best response to this bit of criticism came in comments to the post, by a person named Paul, who wrote:

SVG had a video tag since at least 2004. But SVG is stalled in its development in large part because a major plugin developer (Adobe) and a major browser developer (Microsoft) are uninterested in it. So the slow evolution of web standards is a result, not a cause, of the big company’s wish to dominate the web.

In fact, there is no chapter in the Bible that says that the only two options are W3C and totally proprietary. If Microsoft were truly frustrated with the W3Cs pace (and not its openness) it could just call up Adobe, Mozilla et. al. and start another standards body. But Microsoft and Adobe do not want to co-operate on Web technologies. They want to compete, and use their dominance of certain other industries as levers that will allow them to define the platform unilaterally.

The man got it in one. The slow progress of the web can be laid exactly at the doorstep of a company like Microsoft, which refuses to implement most standards we’ve had for years in the interest of developing its own proprietary crap. Proprietary crap, I might add, which is competitive with the other proprietary crap being developed by Adobe. Why do something like Silverlight, which is based on XML, when there is something like SVG, also based on XML and implemented in the other browsers? The W3C did not “force” Microsoft to take this route—this is Microsoft doing what it does best: trying to own the technology.

In the meanwhile, the W3C has released specifications such as SVG, CSS, RDF, XHTML, and so on, in addition to ECMA’s work on JavaScript 2.0, all of which could provide all of the functionality we need, and more, and all of it free to use by everyone for everything. Oh, no, how evil. Instead, let’s praise companies for re-implementing all of this functionality in their own little plug-ins and browsers, leaving the rest of us web developers to scramble to learn how to implement their adorable, playful, and proprietary “enhancements” so that the applications work on all browsers and all operating systems.

Blame a proprietary web on the W3C!? In what universe?

I do think the W3C needs to change. I think the recent issue with the SVG interest group shows that the organization is too fixed in a bureaucracy no longer compatible with today’s way of doing business. However, we don’t have to wait on the W3C passing new specs in order to have the web of the future. If all the browser companies implemented all of the specifications that have been released, or are under final consideration, combined with the JavaScript we have today, we could do all that Flash and Silverlight and any of these proprietary technologies do…and more. If Microsoft were to implement these specifications in IE8, and encourage companies to move on from IE6 and IE7. If we didn’t have to depend on Adobe’s plug-in. If tools that generate content actually generate content correctly. If the WaSP returned to actually demanding tool makers adhere to standards, rather than become apologists for companies like Microsoft, and it’s cute little meta tags of the week.

Another commenter to the Ellis post wrote what good does it do for the W3C to push out more specifications when browser companies aren’t implementing the ones that already exist. That’s the key to this issue: the W3C can’t force implementation. Only we can force implementation, by using these specifications and leaving other browsers out in the cold. We’re certainly not going to get an open web if instead of punishing companies who are holding all of us back, we give in, lay on our backs, and think of Silverlight.

Categories
HTML5 RDF SVG

Son of Blob

Recovered from the Wayback Machine.

Adobe has decided to partner with Yahoo and Google, specifically, in order to enable search engine access to Flash contents. In other words, web builders that use bad web practices have been rewarded, and can continue to use Flash to completely build their sites, without regard for accessibility or an open web. The site designers do not have to worry their pretty little heads any longer, because the big boys have come to an “arrangement of mutual benefit”, and have decided that no, their shit does not stink.

I’d like to think that one reason Adobe is making this move is because it feels threatened from competition by SVG, but even a fangirl like myself has to acknowledge that much of this is probably related to recent moves into the animation and rich content field by other not-to-be named competitors. Besides, what chance does an open sourced, and openly accessible, technology have against such attractively packaged vendor lock-in? I mean, Google, Adobe: what more would we want?

We should just quit work on HTML5, right now. RDFa, too, not to mention microformats. Forget that semantic markup stuff, and the debate over ABBR. Who needs SVG, anyway? We have Flash, and Flash can be searched. The web has arrived.



Categories
Specs SVG Technology

State of SVG, state of the Bird

I was quite pleased to see all of the activity related to SVG in the HTML5 working group’s public email list. I agree with those who say that HTML5 needs to be able to work with any unknown vocabulary via namespaces, rather than try to coerce a HTMLized version of SVG and MathML. A case in point is the vocabulary items providing metadata information about the image that Inkscape puts into SVG documents. Creative Commons, Dublin Core, its own stuff–Inkscape believes in metadata.

In the meantime, I will continue using XHTML with my SVG design integration. I was momentarily peeved about the repetition of the “draconian” error handling of XHTML every time anyone even mentions the topic. However, I’ve since decided that rather than be peeved, I should feel flattered. According to the people who talk about the “draconian” nature of XHTML, I must then be some kind of superwoman to be able to support it. Hey, go me.

Burningbird currently demonstrates my new philosophy of design, though not necessarily using a specific design I will keep–though it is bright and cheerful in a “Horton Hears a Who” way, and I need bright and cheerful with all the rain and flooding we’re having. As I’ve mentioned in a couple of earlier posts, the site uses a relatively simple SVG image as flexible background, in addition to other SVG for decorative accents. For IE or other user agents that can’t process SVG, I provide a tiny repeating blue striped background, so that they don’t get a plain page. Different but decent.

Though I use the rgba function to set the semi-transparent background of the center column and sidebar, I first define a background color using hex notation:


.column
{
        background-color: #fff;
}
.column
{
        background-color: rgba(255,255,255,0.8);
}

Browsers that don’t support the rgba function yet will pick up the hex notation, getting a nice coordinated blue center column, with white for content and sidebar; otherwise, they’ll pick up the rgba notation, with a completely transparent center column, and semi-transparent sidebar and entry area.

Safari and Firefox support rgba, but Opera doesn’t at the moment (it most likely will in the next beta release). However, again the design is such that it degrades gracefully and looks decent even without support for this CSS3 color module attribute. Or I think it looks decent, though lord knows I’m not a web designer. Let’s say my use of the technology is sound, but my design sense may suck, depending on your perspective.

I’ve also implemented text-shadow, in this weblog and at Burningbird. The sub-headings have a very tiny text-shadow, which really makes the text pop out nicely:


        text-shadow: #ccc 1px 1px 2px;

Opera and Safari both support text-shadow, but there’s no adverse impact with browsers that don’t. It adds a nice polish, but that’s all it is, polish. I really like it, though, and can’t wait until Firefox implements it.

All in all, Safari is currently the browser with the most advanced support for my design concepts, with Firefox a close second.

Another interesting point on the design is the flexibility as to scale. The background scales large for larger monitors, but the entire content will resize based on browser window size, as well as font size and resolution. If you resize the window small enough, the sidebar pushes to the bottom. This is not a bug–the sidebar gets pushed out of the way when the web page is accessed by a smaller device, such as an iPhone. It’s still there, but not taking up valuable real estate.

In fact, the photo and the bright yellow box currently showing also demonstrate the scaling–the yellow box is a SVG element that is constrained to size to the parent container, but preserve aspect ratio; the photo will display at its maximum width, but scale down as the window scales. All in all, the site can scale to an infinite width or down to a minimum 40em in width, and still be readable. The site even works with my Kindle, either using the mobile CSS, or when using the Kindle’s advanced web browsing, the scaled down width and the blue stripe background (though in gray tones, of course).

Best of all, you can zoom the text and the whole site zooms out, so that the words per line length is consistent.

That’s the key to my site designs in the future–not trying to get the sites to look the same in all devices, but looking good for each. Or at least good enough while still giving me the opportunity to try out new technologies. We’ve fixated too much in the past on making sure a site looks “the same” in all browsers. We’ve crippled our creativity trying to make sites look “the same” in all browsers. This was someone’s anal design “rule” set out long ago, and it’s time we toss the bugger aside.

I promised Bud a writing on SVG and performance, especially as compared to raster images (such as PNG, JPEG, and GIF). I actually checked out the WebKit code to see how it manages graphics, and was surprised at how easy I was able to follow the code considering that I haven’t worked with C++ since my old Windows programming days. The WebKit code is well organized and documented, with a minimum of tricksy coding. It really is an excellent product–not the least of which that it will probably be the first browser to pass Acid3. It or Opera, they’re both very close.

Anyway, the writing will be coming after my site redesign, after I finish proofs, after I get the next book started, but I wanted to quickly mention my discovery, in the course of my explorations, how committed Apple is to the use of SVG–in browser and out–because of the scalability. Think of it: if you have a desktop icon that you want to look good in a tiny screen, as well as a monster 60 inch television, would you want to use raster images? Of course not. OK, then, would you want to invent a graphics format, or use one that already has extensive tool support, as well as earning you brownie points with the development and open source communities?

*beep* time’s up

Apple chose wisely. Still, I was surprised at the strength of commitment Apple has to the integration of SVG into its products. And this despite HTML5 disapproval. Hey, go fruit.

Update Opera is stating they’ve reached 100/100 on Acid3. Congratulations Opera! Can’t wait to get my hands on a working tech preview. When I do, I’ll run it against the *Firefox Minefield edition, and the latest WebKit build and we’ll see how they’re all doing. The real test is getting 100/100 with a publicly accessible browser version.

I will declare a winner in my Acid3 races once I’ve seen the 100/100 with my own little eyeballs. Being as I’m superwoman and all.

*Oh, and IE8, too.