Social Media

Scuttle, Google Reader, et al

This has not been a week for centralized services. With the announcement of the Yahoo/Microsoft partnership, I figured the writing was on the wall and decided it was time to decentralize my bookmarks. Good-bye delicious, hello Scuttle.

I don’t use a bookmark service because its part of social media. I use it because I have three computers, and I want access to the same set of bookmarks for each. To make this work, I needed some form of server-stored bookmarking service, and delicious seemed ideal.

Now, though, I’m not sure what is happening with delicious, and rather than wait until the rug is pulled out from under us, I moved my bookmarks to an open source application called Scuttle.

Scuttle is extremely easy to set up. Create a database and user, edit a couple of entries in a configuration file and ensure a subdirectory is writable, and then start up the application. The only thing the application didn’t have was a way of preventing others from creating an account. There is a Scuttle Plus that builds functionality on top of Scuttle, including search engine and user management, but all I really needed was a way of turning off user registration.

Easy as can be: all you have to do is remove the register.php file. Then if someone clicks the Register link in the page, nothing happens. Sure it’s not the most elegant workaround, but it works.

Scuttle has pop-up links that can be added to browser toolbars, and I like the look of it more than delicious. I really don’t care how many other people are linked to a site, or what keywords are used. I just want a way of sharing bookmarks between my computers.

I had barely finished my implementation of Scuttle when I was hit with another one: Newsgator is no longer providing centralized support for its feed reader, NetNewsWire. Instead, you have to get a Google Reader account, and sync a new version of the tool with the Reader service as back end.

I used NetNewsWire for the same reason I used delicious: I wanted an application that used a centralized service to maintain feed syncing between my two Mac computers. However, I haven’t been able to find an elegant workaround for replacing a centralized feed aggregator with something on my own, at least not yet.

I have moved my feed subscriptions to Google Reader, but I can’t stand the site. It is badly designed: cluttered, takes up too much space, hard to easily traverse your unread feeds. It is true that it seems like feeds and aggregators have gone the way of the dodo, with the advent of Twitter and the concept of “Blurb it!” rather than “Link it!”. But I do still like to read longer works, read the works of those few who are still weblogging rather than just Twittering, and catch the occasional actual linked story rather than URL shortened misdirected mess that we have at Twitter.

I could use NetNewsWire to access the Reader data, except the new version doesn’t work with Tiger, so won’t work with one of my computers. I could also just read feeds on one computer only, and set it up with NetNewsWire, synced or not, but I like the flexibility of my current system. So now I’m looking at options, as with Scuttle, for hosting my own feed aggregator that has a web interface, so I can read feeds from all my computers.

Suggestions on open source self-hosting feed aggregators with clean user interface would be welcome.


Embedded fonts with font-face

I’m experimenting with my first attempt at using embedded fonts here at RealTech. I’m using the Gentium Basic TrueType font, which I downloaded from Font Squirrel. Since Internet Explorer doesn’t support truetype fonts, I had to use the ttf2eot application to convert the truetype into EOT, which is what Microsoft supports. Edward O’Connor has a nice writeup in how to use ttf2eot. I downloaded my copy of the utility, since I couldn’t get the Macports version to install. You can also use Microsoft’s WEFT utility on Windows.

(update There is also a Gentium Basic font-face kit that contains everything you need, including EOT files and a stylesheet.)

Once I had both versions of all the font files uploaded to my server, I added the CSS for the font-face rules. You can add these rules as a separate file, or include them in your stylesheet, whatever rings your bell:

/* For IE */

@font-face {
        font-family: 'Gentium Basic';
        src: url('GenBasR.eot');

/* For Other Browsers */

@font-face {
        font-family: 'Gentium Basic';
        src: local('Gentium Basic Regular'),
             url('GenBasR.ttf') format('truetype');

@font-face {
        font-family: 'Gentium Basic';
        src: local('Gentium Basic Italic'),
             url('GenBasI.ttf') format('truetype');
        font-style: italic;

@font-face {
        font-family: 'Gentium Basic';
        src: local('Gentium Basic Bold'),
             url('GenBasB.ttf') format('truetype');
        font-weight: bold;

@font-face {
        font-family: 'Gentium Basic';
        src: local('Gentium Basic Bold Italic'),
             url('GenBasBI.ttf') format('truetype');
        font-weight: bold;
        font-style: italic;

Notice that there are separate files for bold and italic fonts, as well as the ‘normal’ font. All are included, and all are given the same font-face alias, in this case “Gentium Basic”. It’s up to the user agent to determine which font to use in which circumstance (normal weight versus bold, normal text versus italics), Once the fonts are defined, they’re used wherever you would use standard fonts:

#rap {
  margin: 0 auto;
  position: relative;
  z-index: 2;
  background-color: #fff;
  color: #444;
  font: 0.9em/1.5em "Gentium Basic", Georgia,serif;
  font-style: normal;

I provide fallback fonts, for browsers that don’t support font-face.

So, how are these font rules working in various browsers?

Browsers that don’t support font-face yet, such as Opera 9.64, pick the fallback web safe font, as they should.

Safari 4 supports font-face, though the page can show up oddly until the fonts are downloaded to the person’s machine. If you’ve accessed a web site and no text shows, but underlines are appearing for the links, chances are the person is using font-face. The “blank” text doesn’t last long, though, depending on how fast your connection is, and how fast the web server serves up the font.

Once the font is loaded, Safari uses the fonts as described in the CSS3 specification.

Firefox has support for font-face beginning with 3.5. It doesn’t have the download hiccup that Safari seems to have, because it uses the default web font until the font is downloaded, and then redraws the text. (From what I can see, other browsers such as Opera 10.0 beta 2 do the same.)

Using Browsershots and my own PC, I’ve found that Internet Explorer also makes use of the fonts, in the EOT format I’ve provided. However, it doesn’t support the font style and weight specification.

Chrome is using WebKit, which would lead one to think that it supports font-face, but I’ve not seen webfonts work with Chrome. Again, just because Chrome is using the WebKit engine, doesn’t mean the Chromium graphics engine (Chrome’s own graphics engine) supports the same functionality that Safari or WebKit’s graphics engine have.

Opera 10.0 has been a problem for me. All of the fonts are showing as italic in Opera 10 beta 2. I don’t think there’s a problem with my CSS, and have since filed a bug with Opera. When the fonts are installed on the desktop, then Opera 10.0 seems to work. If not, you get italics.

update Thanks to Philippe, I’ve updated the stylesheet. IE does not support the font weight and style setting, so you only specify the one EOT file, for the basic font. In addition, the local setting in the stylesheet provides a local file name for the font, for the browser to use rather than have to download the font. Opera 10 does work when the file is local, but not when downloaded.

Also thanks to Baldur, whose use of Gentium Basic inspired me to try it at my site.


Bruce Lawson added a comment that Opera is aware of the problem, and working on a solution.

I received an email from Stefan Hausmann,who wrote:

@font-face has been disabled in Chrome [1] because of “security concerns”. They announced webfonts support months ago, then disabled them by default, but failed to communicate that to the general public. They’re working on reenabling them by default [2].

In the meantime, you can use the –enable-remote-fonts command line switch. It’s still buggy on Chromium where I tested it. Sometimes web fonts don’t render at all, sometimes single words don’t render (as if they were transparent) or only when selected. Sometimes selecting text with web fonts crashes the browser.

[1] [2]

HTML5 Specs

HTML5: Canvas must go

Latest in my HTML5, A Story in Progress: Separating Canvas out of HTML 5.

Recent discussions about Canvas and accessibility should highlight the importance of pulling the Canvas object API from the HTML 5 specification. The HTML WG went outside its charter to incorporate the Canvas API into the HTML 5 specification. Keeping it in is not good for the HTML 5 spec, nor is it good for the Canvas element.

It wasn’t up to the HTML WG to insist that the Canvas element either be included in the HTML 5 specification or some other formal working group. The group can’t just grab things in, willy nilly, like crows grab a piece of tinsel because it sparkles in the sun. Oh! Me want! Me want!

HTML5 SVG Technology

Separating Canvas out of HTML5

The HTML 5 specification is too large, that’s a given. Too large, and too diverse. With the merge of the DOM into the specification, as well as an attempt to cover two different serializations, not to mention the microdata section, it’s difficult to describe the HTML 5 spec as an “improvement on HTML 4”, which is what the HTML WG’s charter specifies. Kitchen sink comes to mind, and kitchen sinks don’t make good specifications.

One simplification of HTML 5 I would make is to remove the Canvas section from the specification. Instead, I would reduce the Canvas section down to coverage of the syntax for the Canvas element, similar to what’s happening with MathML and SVG, but remove the guts of the object to a separation specification. Or don’t move the Canvas object to a separate specification, but don’t leave the object in HTML 5.

I read through results of the three votes associated with Canvas, or should I say, “immediate mode graphics API”. Two of the votes had to do with the WG charter and creating a tutorial about the Canvas element, and one was specifically about splitting the Canvas element out.

The vote was overwhelmingly against splitting the element out, but also against not updating the charter to reflect the fact that including the Canvas element is outside of the group’s current charter. Frankly, this was undisciplined, and at that point in time, the W3C Director should have stepped in to remind the group about what the charter is, and the importance of adhering to it.

Looking again at the vote about not splitting the Canvas object into a separate specification, you can see immediately that few people are really enthusiastic about keeping the Canvas element in the HTML 5 specification. However, they were even less enthusiastic about doing the work necessary to split the Canvas element into a new specification, and developing a group to support the new spec. Being disinterested in starting a new working group does not make for a compelling argument for keeping Canvas in HTML 5.

Now we’re seeing problems arise by that bad decision. There have been numerous recent discussions about Canvas and accessibility, and it isn’t difficult to see that work on Canvas accessibility needs to continue, probably for a significant period of time; possibly long enough to impact on the timeline for the Last Call for HTML 5.

In addition, there is a very real concern that the same governments that mandate against JavaScript because of accessibility will also mandate against Canvas for the same reason, because Canvas is dependent on JavaScript. Yet the Canvas element is integrated into the HTML 5 specification. The end result could be a slower roll out of HTML 5, perhaps even a reluctance to adopt HTML 5. I hesitate to say there may be a ban against HTML 5, but there is that possibility, too, slight as the risk is.

Most importantly for the folks who like the Canvas object, it’s now tied to the same schedule of the HTML 5 specification. This means that if we want to expand the Canvas object at same later point, we have to do so in conjunction with a new version of HTML. This tie-in makes absolutely no sense. When you consider the increasing capabilities being built into Flash and Silverlight, Canvas also needs room to grow. Now, the HTML WG has effectively boxed it in, limited its future expansion, and probably helping to hasten its future obsolescence. Of course we still have SVG, which is not integrated tightly into the HTML 5 specification, and can continue to grow and expand. Good for SVG. However, I happen to believe that it’s healthy to have both graphics capabilities—but only if both have room to grow.

It wasn’t up to the HTML WG to insist that the Canvas element either be included in the HTML 5 specification or some other formal working group. The group can’t just grab things in, willy nilly, like crows grab a piece of tinsel because it sparkles in the sun. Oh! Me want! Me want! If people are interested in the object, they’ll work to help standardize its use. If they aren’t, then it will continue as it has in the past, based on informal agreement among four of the top five browser developers. At least then it won’t get stuck being permanently embedded in an HTML specification.

HTML5 Specs

One Table

Next up in my series HTML5: A Story in Progress is a final discussion on the table summary attribute, as well as new discussion on the HTML5 table examples, and the introduction of an HTML5 Primer. Read more at RealTech: One Table in a Thousand..

By providing the differing, and I feel complementary table documentation techniques and examples, we’re also, indirectly, enabling better data collection activity in regards to summary in the future. If the issue with the perceived incorrect use of summary is that people don’t understand how to use summary, then in the future we should see correct descriptions of the table using one of the other techniques, without seeing an associated correct use of summary. I hypothesize, though, that we’ll see a positive correlation between correct use of HTML tables, and correct use summary, most likely used with a correct use of caption, or figure legend.