This:
<p id="evolt"> <a href="http://evolt.org">evolt.org</a><br> <a href="http://lists.evolt.org">lists.evolt.org</a><br> <a href="http://browsers.evolt.org">browsers.evolt.org</a> </p>
Begat this:
evolt.org
lists.evolt.org
browsers.evolt.org
See a little more detail and the CSS over at evolt.org.
I tend to be wary of anything that reviews what I write and offers to spit out a score of how valuable it is. Just as I have mistrust for web sites that claim to be "Bobby Validated" for accessibility (I'm dating myself a bit there), or personality tests that tell plot me on a chart based on answers to a small set of questions (which has been co-opted by eHarmony), or guaranteed Google/SEO ranking offers (insert any spam you have gotten through your web site's contact form).
I've commented before on how, in social media, the number of Facebook likes you have or Twitter followers (Lots of Twitter Followers Guarantees... Nothing) you've amassed really doesn't say a lot about your ability (having the word "guru" in your Twitter bio is an automatic disqualification).
Of course it should come as no surprise to those who know me that I don't consider a service like Klout ("The Standard for Influence") to really do a good job of quantifying how good or bad, influential or not I am at social media. I have no illusions about my influence #8212; I have less than 400 followers on Twitter, I don't use Facebook for anything other than crazy talk, I hardly check my LinkedIn account, and I'm not exactly breaking new ground on this blog. My Klout score should be low. But I'd also like to know how it's generated and if it translates to anything tangible.
Cue an interesting article earlier this month, Why your Klout score is meaningless. The author claims to have a PhD in statistics, which admittedly makes no sense to me (I get natural math, not the invented math of economics or statistics), but puts him well above me to evaluate whether or not Klout has any merit. His conclusions:
It often does not correctly order individuals in terms of how influential they are, is easy to game higher simply by adding a Facebook account, and does not respect some very basic monotonicity rules. Put simply, it acts like a derived measurement.
Earlier in the post he offers research has repeatedly shown derived measurements to be inconsistent and not trustworthy individually.
The Director of Ranking (interesting title) from Klout responded in the comments provides some context for how Klout works, but doesn't explicitly challenge the core assertions of the article.
A professor of statistics and political science and director of the Applied Statistics Center at Columbia University weighs in on the previous discussion with his own blog post, also titled Why your Klout score is meaningless. He doesn't dispute points from the original post, instead taking issue with the application of the term "derived measurement." He does have this to say about Klout:
The problem with the Klout score is not that it's subjective but that it's cloudy: we don't know what it is. To understand a cloudy measurement, one has to poke it from the outside. [...] Which makes sense given that Klout itself seems like a tool for ... selling itself! Sort of [like] other notorious rating schemes such as the Places Rated Almanac and the U.S. News college ratings.
For a bit more vitriol wrapped around a play-by-play between Klout and others, you can catch up in this post from November, Klout. Nail. Coffin. Who cares?.
Since these posts were written Klout has moved to add two more features that will likely further affect a person's Klout score, and further confuse (or confound) those trying to measure it. Klout introduced a "+K" button, which is a take-off of Google's own derivative "+1" button, allowing people to indicate that a particular person has influenced them on a topic (Introducing +K: Your Influence is Topical). In addition, Klout will now allow you to associate your LinkedIn account and factor that into your overall Klout score (Measure Your LinkedIn Klout)
If you aren't concerned about how Klout and other arbitrary measurements (such as your number of Twitter followers) can affect you and others, consider these examples (from Get ready. Social scoring will change your life.):
- The Palms Hotel in Las Vegas is providing perks to guests based on their Klout score (an assessment of social media influence)**
- By the end of the year, Twitter said their new analytics will provide influence scores for every user.
- People are now curating lists of the most influential bloggers by Klout score.
- Virgin Airlines offered free flights on a new route to people with high influence scores on Twitter.
- Hoot Suite allows you to sort Twitter results by the influence of the people in the list.
There are already people and organizations who perform triage (at best) or just selectively respond to others based on their Klout score. Apply the same motivation for spammers to game the Google algorithm to Klout scores, and you may face the risk that your former ability to reach out to a brand using social media is hampered because you haven't paid for enough tweets in mainland China to artificially boost your ranking (or that those getting the responses did).
I think my next career might lie in goldfarming followers, likes and re-tweets.
Years ago the general public was aware of three primary generic top level domain extensions (gTLD): .com, .net and .org. There was a huge "land" rush as the dot-com bubble grew and organizations were willing to spend absurd amounts of money to get the .com extension for their business, even building the massive cash outlays into their business plans. Then search engine marketers (snake-oil salesmen) and web development gurus (hacks) started to push organizations to get the .org and .net versions of a domain for assorted reasons.
As ICANN moved to provide more gTLDs, many of which didn't make sense to the average user and gained little traction, we saw extensions like .aero and .museum appear. Registrars hopped on the bandwagon and promoted every new TLD as a requirement to branding your site.
Then countries got into the business by selling access to their ccTLDs, such as Tuvaloo with .tv marketed to to the television industry, and with enough advertising behind it, users started to accept them. The explosion of Twitter and the need for shortened web page addresses further promoted otherwise ignored TLDs, and services like bit.ly helped put the Libyan TLD on the map. Some of us are still curious to see how .xxx pans out.
As of today, ICANN has approved a process to allow organizations to apply for a TLD of their own (read the PDF press release [and you thought UDRP was complex]). If you are Google, for example, you might want .google. Apple might want .apple. It is conceivable that you could see addresses for search.google, maps.google, ipad.apple, iphone.apple, and other unlikely but possible combinations. Apparently the 22 gTLDs already in play don't offer enough variance for the web.
The process itself may be relatively straightforward. ICANN will make applications available (get the May 2011 draft of the Applicant Guidebook) from January 12, 2012 through April 12, 2012, giving companies time to develop a marketing plan and come up with justification to pay the $185,000 application fee and, if approved, the annual $25,000 fee.
With those numbers you can see the potential for a small set of players who want to give it a go. From ICANN:
New gTLDs will change the way people find information on the Internet and how businesses plan and structure their online presence. Internet address names will be able to end with almost any word in any language, offering organizations around the world the opportunity to market their brand, products, community or cause in new and innovative ways.
If my favorite "cause" ponies up that kind of money for a TLD, I can assure you I'll re-evaluate whether that cause really needs my money.
Given how inexpensive it is to obtain a domain name using one of the current TLDs, I am not sure how ICANN expects companies to justify the expense. The limited window implies that this is just an experiment, but is probably also designed to get organizations to move before they lose their chance. Whether or not the public will understand, and use, these is a different story. Instead, I see value in an existing company (with some cash) to consider finding a two-character gTLD, that is not already assigned through the ccTLDs, and rolling its URL own shortener service.
What is also not clear is what happens when two valid organizations in different spaces apply for the same gTLD. If Champion (spark plug makers) and Champion (t-shirt makers) apply for .champion, how is that sorted out and is the application fee lost for the loser of that decision? Here's ICANN's answer from the FAQ:
It is not feasible for two or more identical strings to occupy the Internet space. Each name must be unique. If there are two or more applications for the same string (or confusingly similar strings), the String Contention procedures would come into effect. Refer to module 4 of the Applicant Guidebook for more detailed information regarding the String Contention procedure.
Module 4 defines two methods in the String Confusion Dispute Resolution process to address this (with the presumption that the parties at odds with one another weren't able to sort it out on their own):
The first one only applies to community-based organizations and an unspecified deposit is required to participate. The second one, the auction, isn't allowed when the extension is for a geographic name. The document then goes into detail outlining the concept of an auction along with general rules (currency, defaulting, etc). At that point, it truly is a pay-to-play scenario.
Given how many users still type a web page address into Google search, will the new gTLDs really matter? I'm not sure I understand the problem hat ICANN thinks it is solving, or the business case to justify the purchase, but I am also not privy to the players on the board or the pressure they might be getting elsewhere.
The video below shows the vote — well, it shows the vote for the change, but pans away so you don't see how many voted against this or abstained (13 for, 1 opposed, 2 abstentions).
Mashable, a resource I generally consider good for quickly covering stories but not so good for providing much depth, has taken some time today to review the ICANN guidebook for the new gTLDs and put together the post 9 Things You Need to Know About ICANN’s New Top Level Domains. It's not terribly detailed, but it does provide a good, quick overview if you need to know something right now. You know, because January is right around the corner.
ICANN has announced the list of requested gTLDs. I provide links and list some my favorites at the new post ICANN Announces Requested gTLDs.
The marketing manager for names.co.uk guest-writes a post at .net Magazine ("Google sets precedent for new gTLDs to be open") detailing how Google may be opening up any of the new gTLDs it acquires, instead of restricting their use to just Google brands. The writer hopes others will follow Google's lead.
It's only been 13 years, but CSS version 2.1 is now officially a W3C Recommendation — essentially meaning the specification is final. Which of course means you are now all free to use it in your web pages.
CSS2 became a W3C Recommendation on May 12, 1998, over 13 years ago. Since then the CSS Working Group has been developing CSS Level 2 Revision 1 (CSS 2.1) to correct errors and omissions from the original CSS2 specification. For context, the HTML 4 specification was approved on April 24, 1998. The HTML 4.01 specification was approved on December 24, 1999. Between those two versions, little more than a year and a half passed.
The W3C has a slightly confusing progression of a specification before it is considered a "standard." There are essentially four steps:
In July of last year I wrote up a post about the CSS 2.1 specification status ( CSS 2.1 Still Not Final). Bruce Lawson picked up on the irony in my post (or at least my bewildered expression) and used humor to convey just how this hasn't stopped anyone from implementing it for the last decade-plus (CSS 2.1 “not ready for use” says journalist).
The key reason that this is newsworthy is because CSS level 3 (CSS3) is relying on CSS 2.1 to be wrapped up before it can move forward to the final steps. The CSS Working Group acknowledges that future CSS specifications rely on this final step (read the original release from June 30, 2010: An Update on CSS 2.1):
[CSS] 2.1 must be released as a Web Standard because that's one of the current cornerstones of the architecture of the World Wide Web. We cannot make the next steps, CSS 3 even module by module, happen without 2.1 before.
In case you want to replace the last version of the CSS 2.1 specification that you have hanging on your refrigerator, you can grab the latest (today's) version at the W3C site:
Just to make sure CSS3 isn't lost in the certain global buzz over CSS 2.1, the W3C pushed two more CSS specifications to W3C Recommendation status today:
For further reading, visit the press at the W3C site:
Net Magazine has a brief piece on the wrap-up of CSS 2.1 by interviewing some known standardistas and getting their thoughts on the milestone approach versus the constant iteration approach: It's official: W3C finalises CSS 2.1
This past week I have encountered people asking about testing for Internet Explorer browser versions in real life, on Twitter, via email, and spray-painted under a bridge (along with the phrase I don't want the world, I just want your half
). I have seen response after response directing web developers to simply use the different browser modes in Internet Explorer 9 for browser testing, in particular addressing those who are using Macs and do not want to install multiple versions of Windows for each browser instance.
I whipped up some HTML and CSS of the most basic (and invalid) sort to run my installations of Internet Explorer through the paces. Historically I have found subtle differences between the emulation modes and how the original version of a browser (specifically IE) might render a page. This time out I simply found the emulation mode testing process so confusing that I suspect many developers who rely on this method are doing it incorrectly.
These images represent screen shots from Internet Explorer versions 6, 7, 8 and 9 — the full install version of each, using default settings, no emulators. For the most part we can see differences between IE6, IE7 and IE8, while the differences between IE8 and IE9 are negligible.
Internet Explorer 6
Internet Explorer 7
Internet Explorer 8
Internet Explorer 9
You can see that IE6 has trouble with the 24-bit transparent PNG files, and both IE6 and IE7 apply the padding to the wrapper element differently than IE8 and IE9 do. IE6 is also not setting the height of the element that is the green box, but from IE7 onward the height declaration is honored.
The problem is that once you install IE9 you are kind of stuck. Unless you are willing to spin up a virtual machine for the last few versions of IE you want to test (and I still recommend you at least see how IE6 will munge your pages), you have to rely on emulators. Many developers think that IE9 will allow them to see how older versions of the browser saw pages, and to some extent it will. The confusing part is that not only is there a Browser Mode setting, there is also a Document Mode setting. Using combinations of those two settings, I generated the following screen shots:
Internet Explorer 9. Browser Mode: IE7. Document Mode: IE7.
Internet Explorer 9. Browser Mode: IE8. Document Mode: IE7.
Internet Explorer 9. Browser Mode: IE8. Document Mode: IE8.
But those aren't all the modes. You can also run the browser in the following slightly confusing modes. You might notice that "Quirks Mode" most closely resembles the rendering in IE6 above, without the issues displaying PNG files. This is as close as you can get to testing IE6, and even that doesn't do justice to some of the rendering issues of that rather old browser.
Internet Explorer 9: Quirks Mode.
Internet Explorer 9: IE9 Standards Document Mode
Assuming you simply toggle the "Compatibility Mode" in IE9, which of all the above combinations do you think you'll get? Or better yet, how do you think your page will render? This experiment shows that it most closely resembles the rendering used for its IE7 browser and document modes. I would have expected it to use IE8, or at least some clear indication of which browser version it is trying to emulate. This example alone shows that even a quick cross-browser test in IE9 to test older versions of IE may provide unexpected results.
Internet Explorer 9: Compatibility Mode.
Even if you understand all the document and browser modes available in the IE developer tools, that doesn't mean your web staff, client, or random web savvy user will. The best way to truly test how a site renders in older versions of a browser is not by running emulators, but by running the versions of those browsers themselves.
If you still insist on going down the path of testing using emulators, you should take a few minutes to read the Microsoft article, Testing sites with Browser Mode vs. Doc Mode. The article outlines what each of those settings means and how it adjusts the rendering of the page.
The article makes an assumption, however, that as a developer you will want to serve up different doctypes and meta tags based on how the browser reports itself in the user agent string as defined by the Browser Mode. This image illustrates that:
If you do have a site that adjusts itself based on the browser, given the extra steps to configure the browser, test and compare differences, it's still probably easier and definitely fool-proof to use the specific version of IE that you want to test. This way you don't have to worry about incorrectly read UA strings or mis-selected settings in your browser emulator.
Suck it up and install some virtual machines to get each version of Internet Explorer for testing.
Microsoft has made virtual machines with old IE versions available to developers at its Modern.IE site. There really is no excuse now to claim you can't test in older versions of Internet Explorer.
Typekit points out the dangers of cross-browser testing with IE9′s Browser Modes when it comes to font rendering. Typekit comes to the same conclusion as I do: Instead, you should test with real installed copies of IE7 and IE8[.]
Found this post on Stack Overflow, dated just a couple months before I wrote this post: How well does IE7/8 mode in IE9 compare to actually running IE7/8? Many specific issues there.
I spent about a thousand words explaining RSS before I realized that, for the most part, if you are reading this blog I have to guess you have some familiarity with it (at least by just having heard of it). If you need some background, Wikipedia has a pretty good overview on RSS.
If you are a web site developer or author, there are three methods to get your Twitter feed or your Facebook business page information integrated into your site: via some sort of JavaScript-driven widget, via an API that is unique to each, or via RSS. This isn't limited to just Twitter and Facebook. PicPlz, Foursquare, and others provide these methods as well.
A JavaScript widget (whether via an embedded iframe or not) typically does not integrate well with a site, forcing the branding of the service, its color scheme, and its styles. For many sites, a Facebook widget or Twitter widget can look very out of place, almost like an afterthought. On top of this, because these widgets rely on JavaScript so heavily there is no alternative for those without JavaScript support (whether by choice, by restrictions, or by errors elsewhere on the page — see my post Beyond Hash-Bangs: Reliance on JavaScript Is a Bad Idea)
The API approach gets around styling issues, but often each API has its own proprietary offerings and syntax, requiring you as the developer to learn it, integrate it with your own platform, and spend time maintaining it as the API changes (possibly on a whim). While using this method you have control over how the data is styled on your site, relying on a free service means that you will have less input and recourse should a feature suddenly change (as I say, free doesn't mean good: You Get What You Pay For). Many APIs are reliant on JSON solutions as well, requiring JavaScript to perform the calls, and therefore the rendering, unless you are processing all of the features server-side.
The third method I mention, and the point of this post, is RSS. Because RSS has a standardized XML structure behind it (spread across parallel but unique versions, not counting variants like ATOM), as a developer you always know what to expect from an RSS feed. A JavaScript developer can just as easily parse the XML structure as a server-side coder. Once you have built a function to parse and display an RSS feed from one source, you can re-use it for any other RSS feed, forking it if you want to present the data in a different way on your site. This means you have complete control over the presentation (HTML, CSS and code structure).
In addition, most blog platforms (I'd say all, but someone might surprise me with one I don't know) not only provide RSS feeds of their data (and can even rely on a service like FeedBurner to provide additional RSS versions), they also support RSS import. This little feature means that if you provide content from your site as an RSS feed, any blogger can integrate it into his or her blog with only a few clicks.
An example of just how robust RSS can be is demonstrated with podcasts (and even vodcasts). The structure of a podcast file is really just an RSS feed with attachments, much like you might attach a file to an email. A regular RSS reader should be able to process the file, even if it cannot play the music. A podcast reader should, conversely, be able to read a standard RSS feed, even if there is no music to play.
Another powerful adaption is GeoRSS, which allows geographic data to be embedded in a feed. Syndicated content can be associated with locations on a map, something which has proven to be useful to the rise of location-based social media. For example, you can get your Foursquare history as an RSS feed, with each location tagged with geolocation data. In fact, a precursor to Foursquare, Brightkite, allowed users to generate custom RSS feeds to track specific spans of time, locations, groups of users, and even control how many items to display. When it came time for Brightkite to shutter its location-based services, it made all user data available to its users via RSS feeds.
Because of these reasons I have typically ignored hype expressing that RSS is on its way out. And then I stumbled across the post Twitter and Facebook Both Quietly Kill RSS, Completely, which was followed up a couple weeks later with Facebook Listens. RSS Added Back to Pages. Will Twitter be next?
This reminded me of an exchange I had on the Picplz API mailing list, where I asked if they would update the RSS they provided with geolocation data (since most photos are associated with a venue pulled from Foursquare). I was told that the RSS pre-dates the API and essentially that there aren't any changes in the pipe.
In just the last few days I have been struggling with the new MapQuest, trying to figure out how to embed GeoRSS in the new platform. In addition, I noticed that my "classic" MapQuest maps were no longer showing the embedded GeoRSS. After going through the support forum I found that GeoRSS is not (yet) supported in the new MapQuest, and nobody had noticed that it appears to be broken on the classic MapQuest (the solution they told me I should use for now).
So now I find myself wondering about the future of RSS. When Google Chrome doesn't even show an RSS icon or format it for display, when a new location-based service isn't adding the GeoRSS features, when a major mapping service doesn't support GeoRSS in its latest release, when Twitter buries the link for RSS, and when Facebook toys with its removal, I am concerned that they are contributing to the eventual demise of RSS.
I understand that content drivers (Twitter and Facebook) who survive on advertising revenues want to drive their brand and, ideally, their advertising to end users. Widgets that include a brand and drive people back to the advertising on the parent site make sense. For services and platforms (Picplz and MapQuest), pushing developers to a proprietary API increases the developers' investment in your platform, making it less likely for them to peel off when they can't simply apply their code to the next shiny new thing.
Unfortunately, these all combine to make the barrier to content syndication higher for everyone. While we can still wield an RSS parser to syndicate much of this content (often the one built into a blog, but typically a module within a CMS or other platform), it may be a matter of time before we lose the freedom to rapidly and repeatedly re-use a tool already in our belt. It may also be a matter of time before we as developers forget we should always build an RSS feed when we are instead enamored with the ability to claim our product or service has an API — even if it's not offering any more than an RSS feed can offer.
As developers we need to make sure we are helping our users, future developers, and ultimately our clients, by leveraging standardized tools. When it comes to content syndication and generally sharing data, RSS is the common denominator and typically worthy of implementation as the first step in a solution. If we aren't continuing to use it and expect it, the walled gardens and self-congratulatory APIs will catch up to us.
If you follow the ongoing developments of HTML5, by which I mean the W3C specification and not the regular JavaScript and CSS sites-of-cool-gee-whiz bandied about across the web (Apple.com (Not Really) Updated to HTML5, Google Doodle: Bouncy Balls Aren't HTML5, Google, Arcade Fire Confused on HTML5), then you probably know that it has gone to Last Call as of two days ago. I think, however, that we all need a little context for what this means.
The version of HTML5 I am referencing here is the W3C version, not the WHATWG version. WHATWG has already stated that it will not be releasing discrete versions of HTML, owing partly to the modular nature of the specification. The W3C, however, is still keeping versions and sending the core HTML5 specification and related specifications to last call. Both organizations have been providing updates as they have them (W3C and WHATWG Provide HTML5 Updates), not counting the public mailing lists.
To clarify further, there are six specifications heading into last call, one of them is HTML5. The specifications are:
And just to keep things interesting, the W3C published three other documents at the same time, which are related to the six specifications mentioned above:
What's important to note here is that last call in this context does not mean that the HTML5 specification will be ready at 4:15am (in Buffalo, bars are open to about 4am, so last call is at about 4am). This is simply the last part of the first step of a four step process. The four steps:
To recap, we are approaching the end of the Working Draft step. This meets the timeline that the W3C laid out in the HTML Working Group Charter and a press release from mid-February (ok, Valentine's Day) of this year. The schedule that working group has been pushing all along puts the final release of HTML5 in the second quarter of 2014. The dates as laid out in the charter, as they correspond to each step in the process
If the HTML working group keeps making its deadlines, we are still three years out from a final standard (or set of standards, really). Given how complex these all are and how much debate is happening among them, it shouldn't be a surprise that it can take this long. For example, these two posts helped re-open the issue of alt attributes in HTML5: Image alt Attributes Not Always Required in HTML5, More on Image alt Requirement in HTML5.
If we're practical about all this, and I'd like to think we are, we are in the midst of a new set of browser skirmishes that have resulted in greater and greater support for many of the features to be included in HTML5 and its related specifications. Even if the semantic meaning of all the new elements can't be harnessed in CSS or even in search engine parsing, some of the more advanced features can be used in some of the more advanced browsers. These are all contributing to testing the specifications, something necessary for a specification to keep moving forward (indeed, test suites are a necessary part of the natural flow).
If you are interested in contributing to the specification, you have until August 3, 2011 to get your feedback to the working group. If you want more detail on what you can do or what is expected, go read the FAQ for HTML5 Last Call.
Now I'd like to put a little context in place here. Nearly a year ago I wrote about how CSS 2.1 was not yet a final specification (CSS 2.1 Still Not Final). CSS 2.1 was in the second step as a Candidate Recommendation. the CSS 2.0 specification was finalized in May 1998, but it's taken over 12 years to move the 2.1 revision along. That has not, however, stopped its real-world implementation by developers. It also helps that CSS 2.1 is just building on CSS 2, so it's not quite a fair analogue.
