Correlation

noticed a correlation between my last two posts on the lack of women at Ajax Experience and the seeming lack of RDF or semantic web applications. Both are based on perennial questions: Where are the women in technology? Where are the semantic web applications?

Next time I’m asked either, I think I’ll answer that the women in technology are off building RDF-based semantic web applications. Yeah, that’s the ticket.

The women in technology are off building RDF-based semantic web applications. It works better than answering yes, there are women in technology but we’re still not as visible as we should be, and yes there are semantic web and RDF-based applications, but they’re still not as visible as they could be—both of which evidently don’t play well in the dominant technical culture, because the same damn questions keep getting asked, again and again.

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.

Liar, Liar

Scott at Lazycoder writes on his recent job interview experiences.

Certification and licensing should be about setting a base level of competency. You shouldn’t have to ask someone what the difference between a div and a span element is during a phone screen if they are a licensed web developer. You shouldn’t ask a C++ developer to find the memory leak in a given piece of code. What you really want to know are the intangibles. Are they a cowboy coder? Are they continuously trying to improve their skills or are they set in their ways? Will they speak up during a meeting if they see a bottleneck or problem coming or will they just ignore the problem? We, as a group of professionals, need to determine a structure and governing body that will allow us to not wonder if an applicant is lying on their resume, but instead focus on whether or not a person will be a good fit with the rest of the team.

Most tech interviewers haven’t a clue how to interview. Instead, they set up some code, and allow the code to do the interviewing. Worse, they set up the interview in such a way as to make themselves look good, while making the process as difficult and painful as possible for the interviewee. Rather than a co-worker, the interviewer sees the interviewee as a potential competitor, and acts accordingly.

It’s the only field I know of that uses this approach. Most other fields are populated by people who genuinely care about finding the best person for the job.

XHTML and the Forum

An issue I had with supporting XHTML in my WordPress weblogs is that it can be difficult to control others’ input in comments. I solved the issue with Drupal by not supporting comments directly on posts. Instead, I’ve provided a forum, using the Drupal Forum module, here at RealTech. I’ve only provided the one forum for all of my sites to make it simpler for people to register, as well as follow any active discussions.

To ensure that Forum pages don’t create XHTML errors, I modified the PHP to serve pages as XHTML to exclude URLs that have the word “forum” in them. I realize this will impact on any page with ‘forum’ in the title, such as this page. However, it’s unlikely that I’ll be using inline SVG and the word “forum” in the title for the same post.


header("Vary: Accept");
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml"))
    if (stristr($_SERVER["REQUEST_URI"],"forum"))
        header("Content-Type: text/html; charset=utf-8");
    else
        header("Content-Type: application/xhtml+xml; charset=utf-8");
else
    header("Content-Type: text/html; charset=utf-8");

In addition, I turned filtered HTML on for forum entries, as well as installed htmLawed, to ensure that the entries are as clean as possible. Regardless, a problem in the forums won’t take down a post, and that was my main criteria for making this change.

The forums should also provide a much more flexible communication system. You can use your OpenID to register, or just register directly. You can still comment anonymously, though the comments are moderated.

Typically, any person who registered is an authorized user and could create forum topics. Well, I wasn’t quite ready to make that leap of faith. I created a “trusted” user who can create forum topics and will reserve this user classification to people I know. I then adjusted the permissions to enable forum topic creation for trusted users and admins, only.

I’ve created main forum categories. Over time, I imagine I’ll need to adjust the forum categories to be general enough to be useful, without being so general that it’s difficult to find discussions of interest.

ACIDBird

The problem with relying on an external service is it can go away years later. The content of this page is broken because the examples relied on the Skitch service. 

Today’s design is based on the Open Road SVG image that was just uploaded. This SVG image is ideal for a background, because it lends itself to morphing. It’s also a horizontal image, which works better for a background image.

The image is adding into the page in such a way that it expands to fill the page, regardless of how small or large the browser window is. It is resolution independent. I use two SVG attributes to manage how the images show in my sites, both set on the SVG element, itself.

The first SVG attribute I set is viewBox. The viewBox attribute is a way of capturing a specific section of the SVG image, and using this captured section to fill a given viewport. For instance, if the image naturally sizes to 400 pixels wide, 200 pixels tall, setting a viewBox to 0 0 400 200 is equivalent to how the image would fill the viewport by default without a viewBox. If you use different settings, say 50 20 350 150, then you’re modifying the viewport for the image, setting the beginning x at 50, beginning y at 20, the width at 350 and the height at 150. Since, by default, x increases from left to right, y increases from top to bottom, setting the beginning x and y clips the upper and leftmost edges of the image. If the width and height is less than what the image’s true width and height is, this clips the bottom and rightmost section of the image. You can use any combination, including negative for min-x and min-y, but you can’t use negative values for the width and height. If you use a negative value for the min-x and min-y, it’s about the same as using a margin–it pushes the image over and down.

The viewBox I put on the Open Highway SVG is 50 50 600 400. I decided I didn’t like the sun showing, so I set a smaller width, clipping the image on the right. I didn’t like as much blue sky, and I liked having the road focused a little off-centered, to the right, so I set the min-y and min-x accordingly.

Now, if I used the SVG, as is, with my expanded background, what would happen is the browser engine would attempt to fill my space, but still maintain the image’s original aspect ratio. The image would expand to fill the width at a 100%, but to preserve the aspect ratio, the height wouldn’t be enough to fill the space. The image expands in both dimensions until one fills the space, and then stops expanding along the other dimension.

This can work sometimes, and sometimes it doesn’t work. In this case, it doesn’t work.

I use the second SVG attribute, preserveAspectRatio, set to a value of “none” to tell the browser engine not to preserve the aspect ratio. Then the image expands 100% along the width and height–stretching the image, true, but filling in the space. If you choose the right background, such as Open Road, which works rather well, it doesn’t matter the perspective, it works. There are also other settings for peserveAspectRatio, but I’ll play around with those another day, with another design.

Burningbird
Burningbird

The images were created using Firefox 3b3. Firefox 2.x has limited support for SVG at this time.

My two other images are not the same as the background, as I’m not demonstrating the resolution independent nature of SVG today. I used a coffee cup for the top image, and a little car for the bottom, both of which I think complement the “open road” scheme. Both have the viewBox set, otherwise the SVG images would not resize to fit the container. Instead, I’d be stuck with scrollbars (more on scrollbars later). The coffee cup viewBox creates a viewport big enough for the entire image. The car’s height is clipped, so that the wheels line up directly on the bottom of the page.

Burningbird
Uploaded with plasq‘s Skitch!

I used the object element rather than inputing the SVG inline for today’s theme, as I wanted to record another couple of bugs with WebKit and Opera.

Webkit stretches the image, but it doesn’t draw the content over the SVG until I scroll down and back again. In addition, WebKit also adds a white background for the SVG, which is something we can’t seem to control. This can really ruin a nice effect, such as the top coffee mug, and the bottom car.

Burningbird

Opera doesn’t stretch it at all, and also persists in putting scrollbars on the objects. No matter what I do to try and control the object overflow, the scrollbars get added.

Burningbird

I’ve turned in bug reports for WebKit about the drawing problem and the white background. I’ve also noted problems with pages for Opera, but I’m going to make sure formal bugs are entered for the gradient problem with yesterday’s design, and the object scrollbars and inaccurate resizing with yesterday’s and today’s design.

The work on the themes does demonstrate another important issue. Something like ACID2 and ACID3 are handy ways of seeing if key web technologies are supported, but they’re not comprehensive. Firefox 3b3 scores less than Opera 9.5b and the WebKit nightly on ACID3, but it has better overall support for SVG; especially as integrated into a web page. If the browser makers focus too much on the Acid tests, they may miss the overall picture, which is ensuring that SVG works well in a web page. I have confidence, though, that my reported bugs will generate activity.

I won’t keep this design for long–or at least, I won’t use the object elements–because IE does not deal well with SVG loaded into an object elements that are supposed to be in the background, no matter what version of IE I use. The content is pushed down with IE7, and gone altogether with IE8. I’m getting this behavior even when using the Adobe SVG plug-in.

In the meantime, since Microsoft isn’t welcoming bug reports from the general public related to IE8, my only recourse is to remove the Adobe plug-in. Once the Adobe SVG plug-in was de-installed, then the page opened just fine in IE. Well, it’s in black and white, but legible.

updated

Bud didn’t like the clouds.

*poof*

Clouds gone.