^ Surreal sprouted thrush

While converting a blog into a moderation site for a client’s Twitter API, it was apparent that we needed at least one initial Tweet. And we will need one Tweet for every content bucket that the client wants to track. And the idea of a “seed tweet” was born!

So do we call it a seet, a tweed, a sweet? Or any variation with “ts” and “dt” like seedts, tweedts, sweedts?

The login Element we’re working on somehow got extra top & bottom padding. An hour of CSS into removing this, I said, “Maybe it’s a Visual Studio thing.” So I stripped all the classes and IDs down to just the bare HTML element tags. Padding still there.
Odd, it’s not inheriting anything in the CSS, but I can select it? This is moving from annoying to frustrating.

^ First clue: it behaves as content, but it’s not in the source code.

Okay, then; we’re going to have to do this the old fashioned way.

I started deleting whole sections of code, refreshing and seeing if that made any difference. I would undo the delete (thus restoring the wonky white-space characters) and delete even more code. STILL THERE!

^ Wonky white-space remained.

Then I saw it. Apparently, Firebug doesn’t show these hidden white-space characters outside of properly nested div tags. When all of the tags were finally gone, and there was only a line of white-space between the opening & closing DIV tags, and they were the only content, THEN they finally appeared.
They manifested themselves as   characters in the HTML!

^ Now appearing: Hidden characters!

I went back and examined at the hidden characters. They looked like subscript carrot, or like one wave of a spell-check squiggle.

^ Hindsight: 20/20.

Two things:

1. Viewing the source doesn’t help. They are invisible even in firebug.
2. Someone is taking liberties. The OS? Firefox? Not sure.

^ Invisible in the source code, but only appear in Firebug if they are a leaf node of the DOM (final descendant).

The programs are all doing what they’re supposed to be doing. Same with the operating systems. I pasted from email, pdf or other desktop-published documents into Coda many times before. And the results seemed to be just plain ASCII text. So this came as a bit of a surprise. Now I know it’s Unicode, and am all the wiser.

I have no excuse for Firefox’s interpretation of these characters. Anyone care to weigh-in on this behavior?

font-face update
Our Google Announcement
Google have recently announced that they are also entering the web-font market – with the same free, hosted model as ours.
Although we have put 100’s of hours into the design, development and readying of 150+ fonts (x4 formats = 600!), with only weeks before font-face.com was ready to go live, we have decided to bow out now. A bitter blow to the team.
Our decision has not been easy. Although we feel we would offer a better service, we would after all be competing with Google. A massive might to compete with.
The last thing we would want is to host fonts for everyone to link to, only to at some point (after google have beaten us) be forced to turn them off – destroying your website designs.
So as not do disappoint you in the future, we have decided to stop now. Have no fear though – we will be back! We are hatching a new plan for font-face.com – stay tuned!
font-face.com will still be the home of everything font-face, just not in the original way it was intended.
Thanks
The font-face.com Team x x

Quitters ≠ Cowards

These folks quit right before launch because Google threw their hat into the ring. I think it’s defeatist to say you’re going to get crushed. Or that you’re afraid to disappoint customers that you don’t even have yet.

On one hand, if they are struggling and not committed, then Google is a good scapegoat. And on the other hand, I can empathize with having to toss your creative efforts out. I put the brakes on some projects after they launched because the timing was wrong, I didn’t know what I was doing, or just plain sucked at something. But you don’t know if you don’t try.

The only Steve Jobs quote worth remembering: “Real artists ship.”
They do not give up because of a perceived danger.

Google has no Variety. Yet.

Right now Google font list is quite limited. By contrast Font Squirrel, Typekit, Kernest are way ahead. A modicum of variety is all it take place anyone ahead of Google in the running. Google isn’t there yet. But by entering the web fonts market, Google is validating the need for this service at a very public level. Their presence brings wider awareness to web fonts in general, and helps everyone in this situation. A rising tide floats all boats.

If @font-face.com were truly passionate about their product, and their service truly is better, then Google would eventually have to bow-out (not likely), buy them up (long shot), or make their service surpass theirs (most likely). Therefore, by laying down now, they’re lowering the bar for everyone.

Get Back in the Ring

This news is bittersweet. Google is into web fonts! Yay! @font-face is out! No! Really? WTF? Why do they have to be mutually exclusive? I say to @font-face: Pick yourselves up. Retract your defeatist email. Launch in two weeks and see what happens.

On Mac, you press [Cmd + R] to refresh. And Firefox has the extra ability to force a refresh all the page resources (regardless of any Keep-Alive, Last Modified or TTL headers) by pressing [Cmd + Shift + R].

I’d like to clarify that it’s not a “make Chrome smarter issue,” it’s a basic UI “make Chrome more usable” issue. And it has roots way back in WebKit. Frankly, this lack of instant updates is why I’ve never been able to rely on WebKit for web development.

^ What a black eye

An error occurred, please try again later.

I absolutely hate this error. Even the folks who made this Clash of the Titans campaign right on the YouTube homepage have this error. WTF. While it’s good to know that I’m not alone, this does not bode well for YouTube support. You’d think that this kind of major ad buy would help you get some kind of development assistance, especially if you’re on their homepage!

I rant because this error has plagued me this past month. I’ve used the Google AJAX Search API to embed videos, and the YouTube API to build a feed for a custom player. Both methods result in the same error, inconsistently.

When Flash upgraded their security in 2009, it basically broke a lot of cross domain functionality that we developers had relied on to serve-up content. And a simple crossdomain.xml file does not fix this error.

Jeff Posnick of the YouTube API team posted this note in a thread a while back. So the custom player was rewritten from scratch in AS3 in hopes that a supported version with the Security.allowDomain(”www.youtube.com”); method would work. After implementing these suggestions, still no luck.

YouTube API: It’s Not the Size That Counts

Another solution we tried was different sizes.
In testing, some videos wouldn’t play unless they were HD. Or 480p. Or 360p. But sometimes they wouldn’t play at all. Other times they would play only one size. But when retesting the videos, they would work with a different size! And some not at all… Then, we built size-checking into the player so that if it returned an error, it would request the next size. This method succeeded as much as it failed. So much for that approach.

In our testing we’ve gotten return errors of “0″ and “100″ meaning that the API thinks these videos are removed, banned or otherwise restricted by the user. In truth, they are not restricted, so there seems to be a disconnect between the requested video and what the API returns.

This error is so frustrating because it’s so inconsistent. And, yes, trying again later sometimes “fixes” it. But then, the other requested videos are broken. Right now I have no fix. I have videos that sometimes play. That is the best that you can get from the YouTube API.

I personally suspect that YouTube’s API and their CDN are not integrated as soundly as we think.

When you inspect an IMG (image) tag that is wrapped in an A (anchor) tag, you will see that the A tag is not actually expanding to cover the image. (Fig 1.) The A tag is represented as a horizontal bar that extends several pixels above and below the baseline of your image.

At first this is surprising, but once you verify that it still functions as expected, you scratch your head and move on to more pressing matters. And pray that the Pixel Bitch doesn’t notice.

Figure 1. Inspecting the A tag of the A IMG combo (with Firebug in Firefox). See how it’s flattened at the base of the image? ^

I played with the CSS display property of the A tag until I got it to cover the image. First try: div.ad a { display:block; }

Okay, so now the “A” tag now displaces the correct height of the image. And there is the added benefit of losing that extra 5px or so pixels of vertical margin underneath of the image. (Fig. 2.) It’s odd because that amount of space has a certain minimum height that’s based on the font and line-height since the default is display:inline.

Figure 2. Fixed on inspection and behaving properly!^

The net effect is about a five pixel decrease in padding under the image. And if you still have :focus on, you’ll see that it snugly wraps the image border instead of just appearing at the base.

The permanent fix to this minor issue? Set display block on all A tags that have child IMG tags.

a>img { display:block; }


Veddy nice.

We’re familiar with the ALA method of generating a print stylesheet. The basic idea (assuming you have well-structured HTML) is to add a few “noprint” classes to specific page divisions and make them disappear. Then, format what’s left to generate nicely-printed page.

From a Content Management point of view, this is essentially a print view of your page. The only problem is that the User can print from the browser at any time, so you cannot rely on the “Print this page” link for pretty CMS print templates. This is another justification for the eventual universal Print Stylesheet.

THE PRINT STYLESHEET

A year ago, the client had a nicely printed page. My tweaks were confirmed by a graphic designer with experience in print (who has – and still does – typeset books). But the client doesn’t want a page of type, designed or not. The client wants what’s on the screen in the content area. (Fig. 1)

Fig. 1. The standard template with the Header, Navigation, Content Area, Sidebar and Footer parts blocked-out. ^

Once you get a stylesheet link added to the header (ensure that the media tag is set to “print” ), it’s easy to start debugging. First, refresh your page. Next, hit Crtl +P (or Cmd+P) to bring up your OS’s print menu. Then, hit “Print Preview.” On Mac OS 10, you’ll get a PDF of the printed page in Preview app. On Windows XP I think it’s a resized screen capture.

[On a related note: IE 6 cannot have table row padding greater than zero, or else it will crash Print Preview.]

Then it’s an Alt + Tab flick back to the CSS editor. Save. Then back and forth to the browser. Refresh. Print. Preview.

DEBUGGING PRINT CSS

A previous developer took a stab at the aforementioned standard technique and got rid of the backgrounds and some of the main areas. This was a solid head start, but I ran into the same things that he did. There were still inheritance issues. And the ASP .NET FORM and extraneous DIV elements didn’t help.

I took a swing at it, and started from the outer DIVs and targeted the header, logos, sidebar, menus, and container elements, setting them all to display:none. That worked okay, but it still created positioning inheritance issues. Some DIVs still appeared to hold their shape and position contradicting what looked like obvious overrides.

To better see what was going on, you usually just put a border on all DIVs. But I also incorporated one of the techniques for adding the actual URL address in parenthesis after an underlined link term in the copy. It amounts to some decent code that will help you identify the elements in your print preview. At the end of your print stylesheet, add this print debugging CSS:

div { border:1px solid aqua; }
div:before { content:"div: " attr(id) "-start"}
div:after { content:"div: " attr(id) "-end"}


Basically, it will trace all the divisions of your page, and add the DIVs’ ID attributes to them so that you can see who’s doing what. I find it extremely helpful when fine tuning CSS selectors. (Fig. 2.)

Fig. 2. Print preview of the debugging CSS.^

KICKING ASS

After an hour of not getting the DIVs to disappear, I stopped this silly outside-in approach of stringing huge DOM selectors to try and override all the previous styles. I went for the nuclear option. I deleted the print styles and replaced them all with one line:
div { display:none }

TAKING NAMES

Then, I gave the body a black border { border:1px solid #000; } and set the margins and width on it, similar to the “artboard” in Adobe Illustrator. From there, I walked down the DOM tree of the Content Area, turning “on” each DIV, and adjusting dimensions as I went. The print debugging code (above) helped because I could see each new border turn “on” as I saved a new rule.
#someElement {display:block; margin:0. padding:0; position:relative; visibility:visible; }

For this fairly good-sized site, this approach worked very well. Nuke everything, then turn on only the parts you want. By contrast, to go and name everything you don’t want can be error-prone, time consuming, and inefficient to code!

In the end I displayed exactly what the client wanted (their content area) and it even saved them some time & money.

1. Open a new tab and go to about:config
2. Type in “network.http.pipelining“
3. Click the booleans to switch their values to true, and double the integer to “8″ instead of “4.”
4. Close the tab.

Happy surfing!

There are basically three stylesheets that you end-up with when templating a CMS:

1. The Browser Reset – By now, you should have a comprehensive version set to some hotkeys. Between Meyer’s, YUI, and the several popular CSS scaffolds, I’ve never written one from scratch.
2. The Surround – This is the big one, where half of your CSS work is done to create a functional page layout that matches the design. This can include, but is not limited to a header, breadcrumbs, navigation, sidebar(s), tertiary navigation and a footer.
3. The Content Area – This is the other half where your users can enter content in their admin editor area. This can be straight text, a WYSIWYG editor, or even sorted views of content straight out of the CMS. Just when you think you’re done, there’s forms that have to live in the Content Area, too!

The browser has to load all of these so your h1 tag gets assigned about four times! Once from the internal browser styles, then it’s reset, then it’s spec’d for the design, then it’s declared yet again when it cascades into the content area. Graciously, modern browsers are wickedly efficient when doing this.

Which begs the question: could your site be more efficient? What if you just set the values from the start? Sorry to disappoint, but it’s basically negligible. However, there are a few things that you can do to optimize your CSS for browser DOM crawling. This is more of a philosophy about organizing your stylesheets, too.

1. Use IDs – There should only be one ID per document, so once a browser finds it, it can disregard the rest of the DOM.
2. Namespace any HTML tags with ids – #Header h1 Instead of searching the entire document for every h1 tag, the browser can focus on the #Header div to look for h1s exclusively.
3. Use only one class in a selector – Because every DOM element has the potential to have many classes, you need to limit their use to one or two specific ones.

Happy styles!