Month: July 2009

Categories
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.

Categories
Technology

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'),
             local('GentiumBasic-Regular'),
             url('GenBasR.ttf') format('truetype');
}

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

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

@font-face {
        font-family: 'Gentium Basic';
        src: local('Gentium Basic Bold Italic'),
             local('GentiumBasic-BoldItalic'),
             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 {
  width:960px;
  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.

Update

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 4.0.202.0 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] http://code.google.com/p/chromium/issues/detail?id=9633 [2] http://code.google.com/p/chromium/issues/detail?id=17818

Categories
Standards

Simpler is better

Manu Sporny and Ian Hickson have had an interesting, and telling, exchange about RDFa and microdata in the HTML WG list (see the opening email for the thread). In one of the emails, Hickson writes about why he created a whole new microdata section, rather than incorporate RDFa:

By “technical problems” I mean problems with the design, as opposed to
editorial problems. They’re primarily usability issues, which are to some
extent subjective. I make no apology for having an opinion on what makes a
usable language; it’s my job to have such an opinion.

Generally speaking, my position on this topic is a straightforward one:
simpler is better.

One asks: what is simple about creating an entirely new metadata solution, when there are two viable ones (microformats and RDFa) with both history and use? A new microdata section with predefined vocabularies that will be out of sync with their outer specification counterparts before the ink on HTML5 is even dry?

I haven’t touched on the microdata section of the HTML 5 specification in my little story on HTML 5 yet, because that one, in particular, is really key to everything that is wrong with the HTML 5: the specification and the process. It all really boils down to Ian and a few of his friends having opinions, and the power to enforce those opinions on the next version of the web. There are no checks. There are no balances. There is nothing but an illusion of equality and fairness.

What’s obscene is that no one really likes the microdata section, not even Ian himself. Oh, a few of his buddies manfully came out with the appropriate murmurs of delight, but none of these folks are interested in metadata. More importantly, where there is universal application of microformats and RDFa, there is no implementation that supports microdata (though I imagine one will be tossed into Opera quickly, just for spite).

In the end of the thread, when last I looked, Sam Ruby has vetted Manu Sporny’s RDFa alternative HTML 5 specification. So what does that mean? Your guess is as good as mine, but in my opinion, it does not mean that RDFa has a fair chance, any more than creating specification text for a new description of the summary or alt attributes, means these will be given a fair chance. If any of this comes down to a vote, I have no doubt that the WhatWG folks will be able to swing a majority. After all, client side data storage is sexy, summary attributes for screenreaders is not.

Having a majority does not mean that the best decision wins.

Categories
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!

Categories
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.