tantek.com

t

  1. On Google Plus, Pownce Prior Art, Friends over Federation, Day One Data Export and This Summer's Social War

    Yesterday Tom Coates posted on Google+ about being impressed and compared it to Pownce (moment of silence).

    screenshot of Pownce.com by Andrew Mager

    I wrote the following as a comment on Tom's post and then realized I should have just blogged it so here it is. Viva la IndieWeb!

    Tom is spot on with the comparison to Pownce. What if Google (instead of Six Apart) had bought Pownce? Would it have been too soon? Did Google need to learn from the failures of Wave and Buzz in order to design/build G+?

    Tom also said (in the comments of said G+ post)

    "Don't even get me started on Federation. Don't. Even. Get. Me. Started."

    I'm liking the term Federation less and less because it's the wrong focus/framing.

    Friends matter more than Federation.

    Tom goes on to wonder about social network splintering:

    "I'm actually interested to know what happens if a community splinters. What happens if Google+ is successful. Do all social services get a little worse / emptier?"

    About what happens if Google+ is successful and/or splinters other communities: while the straight up "we're a better version of the thing you're using [AKA Facebook]" approach appears to be Google+'s initial implicit messaging, that's merely the opening salvo.

    They've led with a decent UI and that's the right approach to quickly gain users, fans, and attention (not going to say "buzz", oh drat too late), and data export from day 1.

    My prediction: At some point they're going to flip-on real-time open data flow (e.g. ActivityStreams + PuSH + Salmon or some simplification thereof), so you can get your freshest data out (and in) in real-time. This is fundamentally different in nature from simple static data exports.

    This will enable #indieweb sites to fully participate in Google+ while owning content on their own independent sites without having to write code for a snowflake API/TOS - something which no other silo has done yet (Buzz, Cliqset, Statusnet got/are close).

    At that point I have a feeling the open network effects will be unstoppable. You'll get everyone joining that one open network - rather than splintering among silos.

    Google+ still has to launch this real-time open data flow support of course, so there's a window of opportunity for Facebook or even Twitter to do so first, but I have a feeling that being the newest network, Google+ will be able to do so faster.

    However, I wouldn't underestimate what a competitively motivated David Recordon, Paul Tarjan and co-workers could ship first, so Facebook has a chance (and they've shown in the past they can respond quickly). In contrast Twitter is horribly bad at shipping new features in any sort of timely fashion (e.g. they can't even ship a "who favorited my tweets" feature and whole other sites e.g. favstar.fm have had to do it for them), nevermind actually respond to competition.

    The space of social network silos just got a lot more interesting. It's going to be a fun summer.

    Afterword: I signed my comment on Google+ with "tantek.com" and noted: Once Google+ turns these kinds of external person references (e.g. tantek.com) into a one of those light blue + links e.g. +Tantek Çelik (Hint: it's as easy as doing a quick representative hCard discovery/lookup and grabbing the 'fn' property), then you'll know it's game-on.

  2. Wait, Google+ launched with data export (Google Takeout) on *day 1*? First content silo to do so I think. Links: https://plus.google.com/ https://www.google.com/takeout/ and obligatory funny video: http://youtu.be/QP4NI5o-WUw nicely done @therealfitz and team. Update: see the follow-up related blog post: tantek.com/2011/181/b1/google-plus-pownce-friends-federation-data-export-summer-social-war

  3. Dear @JerryBrownGov, the 'Amazon Tax' is a mistake. It reduces income tax revenues. http://j.mp/amztxbd longURL: http://tech.fortune.cnn.com/2011/06/29/california-passes-amazon-tax-amazon-pulls-plug-on-affiliates/

  4. RT @scobleizer: "Ashton Kutcher [@aplusk] asked me for an invite. Hey +Vic Gundotra you got a hot property!" G+: https://plus.google.com/111091089527727420853/posts/QXD5Rsm7bNn

  5. Amazing code/ux/design discussed+built @IndieWebCamp Class of 2011 http://flic.kr/p/9XLfrG. Demos+session notes: http://indiewebcamp.com/2011/Demos and good notes for *all* sessions (might be a BarCamp/DevCamp first) are hyperlinked from their entries on the Schedule: http://indiewebcamp.com/2011/Schedule http://farm6.static.flickr.com/5226/5881894938_cc4920c8c5_b.jpg

  6. Dear Portlanders: here just one more night. Come to Rogue Ales Public House cc @helloerica @naughtypatches @waxpancake

  7. today #indiewebcamp hack sessions include web intents, 1-click-#indieweb, federated wiki, personal photo backup: instagr.am/p/GclCM http://images.instagram.com/media/2011/06/26/63f3d94536a4459eb53f4032599a3e16_7.jpg

  8. yesterday #indiewebcamp opened with first minute of http://youtu.be/lB95KLmpLR4 and amazing sessions with notes: indiewebcamp.com/Schedule. Here's most of the day 1 session grid: instagr.am/p/GX19K http://images.instagram.com/media/2011/06/25/decddcd88eaa49c2b7a2b6e4dbbe46ab_7.jpg

  9. On that note, looking forward to collaborating with all the #IndieWebCamp builders and apprentices this weekend: http://plancast.com/p/3cos and http://indiewebcamp.com/Guest_List#Builders

  10. "more than ideas ... We are inventors, we are makers, we are doers." -@BarackObama http://j.mp/invmkdo longlink: http://www.whitehouse.gov/the-press-office/2011/06/24/remarks-president-carnegie-mellon-universitys-national-robotics-engineer Great quote to kick-off the weekend of IndieWebCamp.com

  11. #osb11 BarCamp: added #schemaorg WTF? to 13:30 SemWeb session and leading 14:30 #IndieWeb discussion. free pass: http://osbridge.eventbrite.com - get the "Community Pass" for $0 just for today (Friday 2011-06-24) and come participate in the sessions starting at 10:15! http://instagr.am/p/GTIm_ http://images.instagram.com/media/2011/06/24/0189217b0de8447998324a07eb83aef6_7.jpg

  12. The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web. #osb11 lunch table. #diso #indieweb

  13. #IndieWebCamp is this weekend! Follow @IndieWebCamp and auto-join irc://irc.freenode.net/indiewebcamp for discussions.

  14. If you haven't already, update to Firefox 5 ("About Firefox" menu item in the app) or download it: http://firefox.com

  15. Peace, Love, Firefox, and free ice cream Sat 25th ~ Dolores Park: http://j.mp/ffdpice follow @MozMobile longURL: https://wiki.mozilla.org/Engagement/Peace_Love_and_Firefox

  16. Happy 6th birthday microformats.org! Many challenges+opportunities. What can we all do in @microformats' year 7? #ufy7

  17. Au Revoir Simone is an antidote to 386. Time to get ready for #doubletrouble.

  18. walking the talk: openly iterating #idbrowser forms annotation brainstorms: https://wiki.mozilla.org/Identity-inputs

  19. 10 Practices for Good Open Web Standards Development

    Last year I wrote a brief post on What is the Open Web? in which I listed open web standards as a key component, web standards that are:

    • openly documented on the web itself
    • freely accessible with no charges to view or download
    • unencumbered by patents, e.g. patent-free, or available under unconditional royalty free licenses (like CC0 and OWFa 1.0).

    These are good high level requirements for evaluating a finished web standard, but provide only clues for what went into it and how it was developed.

    You can judge a piece of apple pie by its appearance, texture, flavor and other finished qualities, but you have no idea what ingredients went into it. Were the apples organically farmed? How about the flour? What kind of oils or butter were used? Any preservatives or corn by-products?

    Apple filling Or how was the pie prepared? Was it mass-produced in an industrial oven? Crafted by a neighborhood bakery? Or lovingly made by a friend or relative? Just as there are good ways and bad ways to bake an apple pie, there are good ways and bad ways to develop open web standards.

    There's a whole spectrum of ways to develop open web standards that's expanding over time as we learn new practices both good and bad. We can and must always strive to be better at it. We've significantly evolved our best practices over the past couple of decades, and yet we must stay ever vigilant against bad faith behaviors, both known and novel.

    Here is a list of good practices, many gleaned from my personal experiences with various open standards groups and communities. The presence of these makes a standards effort more open, the absence, less so. You might recognize some/most items on this list from my previous post which explained their historical relevance to the CSS Working Group.

    This post explores some of the how and why of these emergent practices, patterns, and some examples of corresponding anti-patterns. Suggested additions welcome.

    1. develop it openly.

      This may be the most important aspect. You might not consider every idea or brainstorm worthy of publishing publicly on the world wide web. That's ok, understandable, and maybe even shows humility. Instead you're more comfortable sharing an idea privately with a few friends or colleagues, maybe even at a private event. No problem, take notes. The instant you've received enough feedback sufficient to convince you that you might have something worthy of consideration, even (perhaps especially!) before you've implemented it, publish it on the public web. On a wiki or a blog. Sharecropped on a content hosting service or on your own site (preferred). As plain text or rich semantic HTML (preferred). Whatever and however, just put it somewhere on the public web with a permalink.

      Anti-pattern:

      Resist the temptation to develop an idea until it's "complete" or until you've got other companies to sign-on - i.e. avoid the trap of "delayed open" development or duopolistic/oligopolistic announcements. Publish your ideas early and ...
    2. iterate openly.

      Whether you publish your standards brainstorm ideas on a blog, a wiki, or check them into github, iterate on them openly. Publish, save, commit new versions with any degree of stable improvement over current versions. Keep old versions and a public interface to access them all. Preferably make sure each version has its own permalink. This provides greater transparency and visibility into the thinking behind a standard, its current state, and how it got there (provide at least minimal check-in / edit summary comments with each change). Even small edits reflect activity, attention, stability/flux and are thus quite useful.

      Anti-patterns:

      As convenient as it may seem, avoid simply updating a static URL in place. It's ok to have a "give me the latest version" URL, but only if you can also access specific iterations at their own date(-time)-stamped permalinks. Avoid the temptation to wait until each iteration feels "complete" (kind of a "delayed open iteration" problem). Avoid deleting older revisions just because they're "old" - people may have linked to them, and often early changes provide insight into why things ended up a certain way.
    3. use an open wiki.

      I have Kevin Marks to thank for first suggesting that we write-up some of the early microformats on an open wiki. I was skeptical at first, being used to W3C's more formal specification process. Starting with XOXO (fairly sure that was the first wiki-based microformat) we've used wikis to conceive and iterate. Some microformats like rel-license, hCard, and hCalendar started as brainstorm presentations and blog posts, but were quickly captured on wiki pages and iterated there since. Wikis are also good for documenting research, examples, and even decent for issues, feedback, and capturing multiple points of view. In general it's best to use wikis for all content related to your standards effort. Be sure to allow anyone to trivially create an account or use an OpenID to login. You may want to consider disallowing anonymous edits as the resultant spam can overwhelm a new wiki that has few contributors/gardeners. Finally, having an "Edit" link/button as well as a browsable history on open standards sends a profoundly strong message of community accessibility, accountability, and participation.

      Anti-patterns:

      Avoid creating a private wiki for an open standard. Avoid using a single account for edits (make everyone use their own account - this helps accountability). Avoid bureaucratic sign-up processes - the reason you put things on a wiki is to make it easier for casual readers to participate. Don't force users to read pages of bespoke legalese etc. just to create an account to contribute. Use standard licenses and contributor agreements such as CC0 and OWFa CLA 1.0 which casual readers can accept (or not) based on previous evaluation.
    4. discuss openly.

      In addition to blogging and/or tweeting etc. publicly about your potential standards ideas, discuss them publicly. Start with existing applicable public wikis, mailing lists and/or IRC channels (preferably both) rather than creating new ones.

      Anti-patterns:

      Minimize private discussions. Sometimes, even with iterations, you want to bounce an idea off of a trusted colleague, which is a completely sensible thing to do. Regardless, minimize them and don't fall into the trap of preferring private discussions because you're afraid of public criticism. If you do have a private meeting, document the outcomes or results promptly. Finally, avoid prematurely creating a new list or IRC channel. Rarely is an idea worthy of its own forum. However, if/when the need arises to create a new group...
    5. open email list and IRC channel.

      (create if necessary). If your idea both attracts sufficient attention from others (at least two more is a good minimum) and exceeds the scope of existing mailing lists or IRC channels, you may have to create a new IRC channel and mailing list. Make them open for anyone to join, preferably requiring open contribution agreements, e.g. CC0 and OWFa.

      Anti-patterns:

      Do not create a closed list or IRC channel for discussing an open standard (sounds obvious but you'd be surprised how many times people keep doing it).
    6. open IRC logs.

      When discussions happen in IRC, sometimes people say useful interesting things that are worth citing. Set up a bot to (auto-)join the channel and log the channel somewhere on the public web with permalinks at least for each day, and preferably for each line of communication. This helps encourage creative thinking in the low-barrier to participation environment of IRC (think/type) knowing that the ideas won't be lost.

      Anti-patterns:

      Avoid requiring a login just to read IRC logs. Avoid blocking search engines from indexing IRC logs.
    7. open list archives.

      Provide open access to mailing list archives, without requiring any login, and indexable by search engines. Ideally provide a user interface to search the archives. Similar to IRC, sometimes ideas originate or issues are resolve on mailing lists, thus it helps to cite those messages as well.

      Anti-patterns:

      Avoid forcing users to login or join a list just to view the archives. Avoid blocking search engines from indexing the archives.
    8. send wiki edits to IRC.

      I learned indirectly from folks active in the Wikipedia community that's it quite useful to have a bot that watches for wiki edits and summarizes them realtime in a community IRC channel. We implemented such a bot fairly early in microformats.org's history. Most recently Aaron Parecki setup the Loqi bot to monitor changes from the microformats wiki and report them to the #microformats IRC channel. It's great for (more) quickly catching spam or other vandalism and reverting it. More importantly the bot provides a nice sense of what wiki pages are receiving more attention, and each such update provides a implicit invitation to participate on the wiki.

      Anti-pattern:

      Avoid using URL shorteners to abbreviate MediaWiki (or other) wiki diff URLs.
    9. open test suites.

      Every time I've seen a test suite published publicly for a standard I've seen both the standard improve, and more importantly the interoperability and completeness of implementations improve. Start with at least one simple test per feature (e.g. element, attribute, property, value type) and then expand combinations, edge cases, and error tests from there. Be sure to publish the test suite just like the specification, with versioned permalinks and open licenses like CC0 and OWFa. You want to encourage people to copy existing test cases, make variants, and publicly share them.

      Anti-patterns:

      Avoid private or payment required test suites. Avoid requiring logins to view test suites. Avoid browser sniffing on test suite tests.
    10. open implementation reports.

      A test suite helps exercise features of a spec but interoperable implementations are what really prove them out. Publish the results of running an implementation thru a test suite so that others can verify it for themselves. It tends to also help motivate other implementers to keep up. Be sure to link from such reports to the specific version of the test suite used, as well as noting the specific product/implementation version (preferably with download URL).

      Anti-patterns:

      Avoid summary-only implementation reports - always link them to the detailed reports from which summaries were derived for verifiability. And similarly to above, avoid private or payment required implementation reports.

    Adopt those ten practices and you'll find that you develop open web standards that are both of higher quality, and often faster as well.

    Despite the "10 Practices..." title of this post, there's one more that's worth taking it to 11.

    1. openly encourage broader community involvement early and often.

      While it may be easier to reach some form of "consensus" by working by yourself, with a couple of friends, or as one of a few large companies, standards efforts which actively encourage community involvement tend to be better, and more open as a result. Reach out early to the folks you think would use your standard, those that would author, develop, debug, and test, especially in related communities. Let them know what you're working on, and how to lurk or contribute to your efforts.

      Anti-patterns:

      Avoid falling for the lone inventor in the garage myth. If you think you can do a better job inventing something privately in your garage, or behind your corporate firewall, these days you're almost certainly wrong. This didn't used to be the case, and thus we have numerous industry origin myths about the one or small number of inventors that went off and did something novel. These days, the open web is evolving and iterating much faster than any one individual, company, or even a small number thereof can do by themselves. This is a new phenomenon since the advent of web search engines of the late 1990s / early 2000s, and the subsequent greatly increased discoverability (and thus faster feedback loops) of innovations occurring in the open, on the open web, and in the past five or so years, in real-time.

    The above practices, patterns (and anti-patterns) are based on personal experiences (both good and bad) with existing open standards communities and organizations such as W3C (whose working groups vary wildly in the implementation of the above), IETF (same), microformats.org, WHATWG, and Activity Streams. In fact, it would be interesting to see a table of various open standards efforts, with columns for each of the above good practices, noting which communities do which things well, and which things they could improve. Good material for perhaps a future blog post.

  20. apparently tonight's plan is Pancho Villa burritos to go and then @PubStandardsSF at Uptown http://plancast.com/p/5vhq

  21. registration open @W2E NYC Oct 10-13 (I'm speaking on #HTML5) http://web2expo.com/webexny2011 25% discount: webny11pc2

  22. asks @jonesabi: "treated differently than other visits?" Declining NDA for yrs. Been treated respectfully and professionally whenever I visit Google. in-reply-to: https://twitter.com/jonesabi/status/80760281139130368

  23. asks @kragen: "ever visited Google?" Just last week. I declined NDA, visitor badge printed with "No NDA". photo: http://images.instagram.com/media/2011/06/06/8c78f1f818eb4a2d8c516839caac011b_7.jpg http://instagr.am/p/FS97W. in-reply-to: https://twitter.com/kragen/status/80737056875233280

  24. #schemaorg @netmag "does schema.org threaten to overshadow open standards?" http://j.mp/scbsos #openweb longURL: http://www.netmagazine.com/news/search-giants-unveil-semantic-vocab

  25. says @bfeld "entrepreneurs: your idea is not special" http://j.mp/idntsp Similarly: always decline visitor badge NDAs.

  26. Argentine scientists engineer cow with human genes for baby-friendly milk: http://j.mp/arghcow #notscifi quotes: Scientist named Germán Kaiser (no joke) claimed “Since the proteins are identical to those in human milk, this cannot be harmful.” Argentina’s agriculture minister says that it fulfils [sic] a “significant social goal”. Ja, I bet. This cannot end well. longlink: http://www.ft.com/cms/s/2/19dea190-9536-11e0-a648-00144feab49a.html

  27. despite appreciating NYC's energy and pace, relieved to find myself feeling happy to be home in SF. not moving yet. :)

  28. wonderful NYC week with @aysan, friends, #pdf11, Skyping into #semtech BOF + #foocamp #schemaorg WTF. made it home ok.

  29. sharecrop = risk your id. was Tumblr @zephoria, now Twitter towerbridge: http://j.mp/twtbr #ownyourdata longURL: http://infovore.org/archives/2011/06/12/wheres-towerbridge/ Do something about it: join the IndieWeb and share what you build at indiewebcamp.com.

  30. on TummelTV I briefly noted G+MS #schemaorg collusion. @JeniT expands on Monopoly: http://bit.ly/monopr longURL: http://www.jenitennison.com/blog/node/157 via @hadleybeeman. See (hear) also Tummelvision audio: http://tummelvision.tv/2011/06/10/tummelvision-67-tantek-celik/

  31. "Our [@microformats] specs have an edit button, theirs don't even have an edit history." - @KevinMarks #schemaorg #foo

  32. 2 years ago yesterday Yahoo et al launched http://commontag.org which went nowhere: blog.commontag.org #schemaorg #foo

  33. weekend smart creatives' tags: #foo #foo11 #foocamp #overlap #overlap11 twttr search: http://j.mp/foovr longURL: https://twitter.com/#!/search/%23foo%20OR%20%23foo11%20OR%20%23foocamp%20OR%20%23overlap%20OR%20%23overlap11

  34. Tummelvision #67 @debs @heathr @kevinmarks @t on Standards as Community: http://j.mp/tmtvst #schemaorg longlink: http://tummelvision.tv/2011/06/10/tummelvision-67-tantek-celik/

  35. @foolip bullies need not ask permission, not make it ok. You're right needs longer text. @hsivonen post is good start.

  36. just picked among dinner options based on web site http://mercatnyc.com is pretty and turns a nav list into a clickable map. Wish it actually used *hyperlinks* though and worked without JS. At least there's no Flash for content. Has anyone published a web design pattern for turning a linear nav link list into a pretty 2D clickable map purely with HTML+CSS?

  37. NYC: I'm going to the cabaret "Canard, Canard, Goose" @ Joe's Pub *tonight* http://plancast.com/p/5roa You should too!

  38. On a more positive note, check out the new pretty (and hopefully more useful) @CSSWG site! http://www.w3.org/Style/CSS

  39. @diveintomark @foolip may be missing key to #schemaorg criticisms. It's WWOWC: Why Wasn't (*any*) #OpenWeb Consulted?

  40. Thanks @joshje @hsivonen. Tip: don't update sites on mifi in NYC Subway. Up: CSS 2.1 and #OpenWeb http://ttk.me/b/4CE1

  41. CSS 2.1 and CSS3 Color become W3C Recommendations – A Few Open Web Standards Practices Learned

    Developing good open web standards is more often than not an arduous, tedious, extremely detail oriented, and quite unglamorous task - it's work that typically induces blank stares when provided as an answer to questions like: "What do you do?" or "What do you work on?".

    The moments of recognition for open web standards are few and far between, and thus it's important to take note when those moments occur. This is one of those moments: Cascading Style Sheets Level 2 Revision 1 (AKA CSS 2.1) and CSS Color Module Level 3 (AKA CSS3 Color) have finally become W3C Recommendations.

    Each and every person who edited, contributed, wrote test suites, ran test suites, wrote implementation reports and perhaps most importantly, diligently interoperably implemented these standards deserves significant kudos for helping advance the open web. And along the way to the CSS 2.1 Recommendation, the CSS Working Group learned, developed, and adopted a number of open standards practices that as a set may prove to be far more valuable to the future of the open web than any one specification.


    I don't think I had any idea what I was getting into, nor how it would shift the course of my professional career when Chris Wilson suggested to me just over 13 years ago that I join the W3C's Cascading Style Sheets Working Group (then actually known as "CSS&FP" - The FP for Formatting Properties) as Microsoft's Alternate Representative. In May of 1998 I attended my first CSSWG meeting (first open standards community meeting of any sort, W3C, etc.) in Paris, France hosted by Daniel Glazman of EDF. It felt like I was participating in some sort of geeky international congress (still kind of does actually).

    Two months earlier, in March of 1998, CSS 2 had become a W3C Proposed Recommendation (PR) which meant that it was considered "done" and was simply awaiting a procedural W3C member review and vote. For all practical purposes, nothing else was going to get fixed in CSS 2. There wasn't a Candidate Recommendation (CR) phase back then, as evidence by the fact that no-one (including my Tasman team as part of Microsoft Internet Explorer 5 for the Macintosh) was able to implement CSS 2 as specified. The problems in CSS 2 were far more severe than mere errata - we had to develop a full revision to fix it.

    It took us, the CSS working group, four years to produce the Last Call Working Draft of CSS 2.1, the publication thereof which was part of my first blog post. And that was merely the first of many so-called "Last Call" working drafts, which served to convince me that the very concept of a "Last Call" was fundamentally flawed - but that's a subject for another post / discussion on pragmatic specification stages.

    The long and exceptionally challenging path to CSS 2.1 interoperability (several cycles of extremely thorough diligent testing, editing, iterating) among other things has taught us some key things. First, that holding a web standard to openly published test suites which are interoperably implemented by web browsers is absolutely essential for practical, pragmatic standards that are usable on the web, rather than hopes and ideals of what could be (what most published "standards" appear to be). However, second, it's also taught us that it can take a long time to be that thorough with something that large.

    From the first CSS 2.1 Last Call Working Draft to Recommendation it took the working group nearly nine years. When Ian Hickson estimated it will take til 2022 for HTML5 to reach Proposed Recommendation, it wasn't unreasonable: that's 10 years from next year (2012), when HTML5 is now expected to reach Candidate Recommendation. And HTML5 is much more complex than CSS 2.1.

    This is also why the CSS Working Group chose to modularize CSS for CSS3 - which also took several iterations of editing, implementing, remodularizing to help figure out where pragmatic boundaries could be drawn. Modularization is one of those things that can seem both reasonable and straightforward in theory, but in practice, be quite challenging. The CSS Working Group has made progress with understanding practical modularity, as evidenced by several CSS3 modules having already reached Candidate Recommendation status, and reasonably well implemented in browsers.


    However I'd like to close this post with what I think is the more important set of lessons, expanding the first learned point above. In particular over the past 10+ years that it took us to make CSS 2.1 real, we've learned the following practices are strongly effective ingredients for open standards development. Some/many/most of these practices are not (or no longer) unique to the CSS working group, but it's one key group at W3C that's implemented them all and did so quite early on.

    Open Web Standards Practices

    • open iteration. The CSS working group was among the first to publish and maintain public interim editor's working drafts. Anyone can browse the raw updates: dev.w3.org/csswg. I don't remember who started this convention at W3C, but I highly approve.
    • open mailing list. The CSS working group decided quite some time ago to switch all CSS spec discussion from the member-only w3c-css-wg mailing list to the already public www-style mailing list. The member-only list is pretty much just used for administrivia now.
    • open irc channel. Since as long as I know, the CSS Working Group has used irc://irc.w3.org:6665/css for teleconferences plus face to face meetings, and anyone can join in to lurk, offer commentary etc.
    • open irc meeting logs. The CSS working group for several years now has published public logs of the IRC channel from meetings (teleconferences, face-to-face). This is one I personally pushed for, based on my experience with the utility of having public IRC logs for microformats.org.
    • open wiki. The CSS working group was among the first at W3C to create an open wiki. It's on its own site wiki.csswg.org, created before wikis had really been adopted inside W3C. Again, something I pushed for (but I believe Elika implemented, got the domain, set it up etc.) based on my experience with wiki-based development on microformats.org.
    • open test suites. Even with CSS 1, the CSS working group produced open, freely usable online test suites. This seemed like an obvious thing to do to me at the time, but apparently was not something to be taken for granted in standards development, e.g. absent from typical IETF work. For example there was no public iCalendar (was RFC 2445, now 5545) test suite. Instead, implementers were expected to pay for and attend in person an Interoperability Test Event run by another consortium (not IETF). This isn't just history, there still is no online, public, free iCalendar test suite. But you're welcome to register for the upcoming October 3-5 2011 CalConnect Interoperability Test Event taking place in Prague, Czech Republic and pay over $2000 to participate. Just want to observe? That'll be $350. No joke.
    • open implementation reports. Anyone is welcome to run an implementation through a CSS test suite and submit/publish an implementation report. After some degree of (minimal) verification it will likely get posted on the W3C's site, openly, viewable by all. Again, not to be taken for granted. Again in contrast, CalConnect Test Event Reports public reports will not identify any participating organization with any particular set of results..

    In my opinion, as of 2011, if you want to develop open standards, especially open web standards, you must at a minimum follow the above practices. I'll expand on why and patterns that have emerged in a subsequent post.

    CSS 2.1 is a tremendous achievement and everyone who worked on it, implemented it etc. should be very proud for this key building block of the open web platform. But we've gotten a lot more than CSS 2.1 in the years it took to develop it - the deliberate open standards practices that have emerged from that effort (among others) are perhaps even more valuable, as they can inform and improve every other open web standards effort that we pursue, as long as we deliberately choose to do so.

  42. "In a closed system, power is domination and control, in an open system it's credibility and influence." -@slaughteram

  43. "Calling something a non-state-actor is like calling an automobile a horse-less carriage." - @slaughteram #pdf11

  44. CSS 2.1 + @CSS3Color W3C RECs! http://w3.org/TR/CSS21 http://w3.org/TR/css3-color Congrats co-editors+@CSSWG! #openweb

  45. #pdf11 day 1 closing talk by @rasiej also ended with the need to break the duopoly of DSL+cable to spur US broadband.

  46. #pdf11 @lessig talk: DSL+cable duopoly = low broadband; Katrina = ignore "losers"; tax credits go to campaign funders.

  47. best thing I read this weekend: Top Five Deathbed Regrets http://j.mp/db5regs via @kcpike @founderb. longlink: http://ohdarling.posterous.com/nurse-reveals-the-top-5-regrets-people-make-o

  48. Dear New York City friends, I am in your fine city for the next week. Let's get lunch, coffee, drinks and catch up!

  49. @hsivonen @asadotzler WebM fights BigCo patent-closed H.264. #schemaorg fights indie free-PD-CC0-open vocabs. #openweb

  50. Dear #fsw2011 attendees: What did you build to advance a Federated Social Web? Tweet code/design/ux URLs with #fsw2011

  51. at 15:16 left my Blade-Runner-esque umbrella in SF Yellow Cab #1180. If you ride that cab, please look for it. Thanks!

  52. #schemaorg problem not about #HTML5 #microformats #RDFa. It's about open standards communities and subversion thereof.

  53. asks @Arlen "duration as itemprop?". See schema.org/EventVenue <time datetime="Tu,Th 16:00-20:00"> cc @al3xandru

  54. @mattmay @jchenry re: forking #HTML5 specs. licenses do not stop it. community strength/outrage, market pressure might

  55. (a serial tweet #schemaorg critique is insufficient but it's important to get a few points out. blog posts to follow.)

  56. Sorry Google, Microsoft and your Yahoo Search puppet, as open standards community advocates, we must reject schema.org

  57. #schemaorg #HTML5 fork smoke: http://schema.org/EventVenue openingHours extends <time> datetime with durations.

  58. #schemaorg much worse than just a Google+MS duopoly reinvention of open vocabularies, they're actually forking #HTML5.

  59. #schemaorg spits in the eyes of every person and company that worked on open vocabularies like vCard, iCalendar, etc.

  60. #schemaorg is not open standards, it's just duopoly driven de-facto; sorry Y! Search, as Bing's bitch you don't count.

  61. The more I dig into #schemaorg the more problems and arrogance to the point of evil I find. Google how could you?

  62. Dear Schema.org Googlers, please read The Official Google Blog: The meaning of open http://j.mp/gmopen longlink: http://googleblog.blogspot.com/2009/12/meaning-of-open.html

  63. Want to hack the news? Join the Knight-Mozilla (MoJo) News Tech Challenge by June 5! http://j.mp/mojohx longURL: https://hacks.mozilla.org/2011/06/want-to-hack-the-news-join-the-knight-mozilla-news-tech-community/

  64. quite a decent essay from @manusporny that debunks a lot about #schemaorg: http://manu.sporny.org/2011/false-choice/

  65. 10 years since @Doctorow's "Metacrap" first draft of 2001-05-15 (trust that date?) http://j.mp/metacrp longlink: http://www.well.com/~doctorow/metacrap.htm

  66. are you a fan of typography? Check out Amp&rsand conference 2011-06-17 in Brighton, birthplace of Eric Gill: http://ampersandconf.com/

  67. want to build+advance the open #indieweb? Join us @IndieWebCamp in 3 weeks! Book your flights to Portland today: http://indiewebcamp.com/

  68. Asks @leepowell: Aren't Google+MS part of #schemaorg? A: G+MS have good open people, and arrogant delayed-open people.

  69. Thanks Google+MS folks who *openly* work on standards and *communities* like #ActivityStreams, #microformats, PortableContacts.net, OAuth.net, OpenWebFoundation.org, W3C.org, and WHATWG.org (I'm sure I'm forgetting some). Thank you for working hard to openly be and do good, in addition to not being evil (unlike the arrogant short-sightedness that is schema.org).

  70. more on #schemaorg: worst Google top-down attempt since Google Base. Remember that? http://j.mp/gogdbs longlink: https://code.google.com/apis/gdata/docs/2.0/elements.html Will try to find and write some positive things about schema.org tomorrow, but for now, really disappointed in it and the folks behind it. They (should) know better.

  71. nice "Follow Button" Twitter! http://j.mp/twfbtn Added to http://tantek.com with rel="me", works great! longlink: http://blog.twitter.com/2011/05/introducing-follow-button.html Note: if you put a Twitter "Follow Button" on your home page, be sure to add rel="me" inside the <a href> code. View source of tantek.com and look for "twitter-follow-button" for an example.

  72. #schemaorg 1st thoughts: good brainstorming for iterating @microformats, bad "delayed-open" tactics http://j.mp/schodo

  73. Twitter launches^1 #photo #search http://j.mp/twsrph, like Technorati tags in 2005 http://flic.kr/p/5qC2q. More: Technorati launched^2 tags pages on 2005-01-17 that showed real-time, tagged posts from blogs across many sites, as well as tagged photos from Flickr and Buzznet. Original UI: flic.kr/p/F1iJ farm1.static.flickr.com/4/7610396_35e12fd072.jpg and updated later in 2005: flic.kr/p/5qC2q farm1.static.flickr.com/26/50069858_22b3ac4d88.jpg Slight difference though: Twitter's photo search shows photos *linked* from (hash)tagged tweets, while Technorati's tags pages showed photos that were *directly* tagged where hosted (instead of showing photos linked from tagged posts). 1^http://blog.twitter.com/2011/06/searchphotos.html 2^http://www.sifry.com/alerts/archives/000270.html

  74. Sign-ups officially open! @OpenWebCamp III http://openwebcamp.org @t:@cassisjs @codepo8:#HTML5 @cindyli:design +more.

  75. got JS-only and JS+PHP code in @cassisjs to pass JSLint+JSHint (global variables gone). next: sanity check unit tests.

  76. theorizing to tipsy designers that both sketching and HTML are essential elements of modern literacy. #sketchcamp

  77. really enjoyed #sketchcamp ballot redesign exercise by @danachis, 6-8-5 with @newhighscore, Sketching 101 with @brynn!

  78. #sketchcamp: @uxcrank is walking us through understanding and exploring "Intent Paths", e.g. http://flic.kr/p/9JqoAE

  79. critiquing: 1 What are we trying to accomplish; 2 Does this get us to where we are trying to go. -@jmspool #sketchcamp

  80. Unlike most BarCamps, #SketchCamp is mostly women. Yet first 5 called on for ideas were men (women raised hands too).

  81. co-organizer @brynn kicked off #sketchcamp; @jmspool's now discussing carpenters, hunkering, and hiding sketch skills.

  82. says @matthewlevine: "flourishing beyond mere happiness" http://j.mp/nytprm. I say "Ads Implant False Memories": http://wired.com/wiredscience/2011/05/ads-implant-false-memories longURL for the New York Times article "A New Gauge to See What’s Beyond Happiness": nytimes.com/2011/05/17/science/17tierney.html

  83. One Year With Mozilla

    Mozilla mascot One year ago today I started contracting with Mozilla to help advance open web standards.

    I'm reasonably happy with what I've accomplished in the past year (e.g.: CSS3 Color to PR, HTML5 improvements, a modern GENDER property in vCard4). I'm thankful for the inspiration and support I have received from the people and culture at Mozilla. There's an incredibly high density of pragmatic positivity as well as the constant background hum of the ongoing fight for a more open web.

    HAXXOR. While I've made progress with specifying details of bits like how 'text-overflow' works in numerous edge cases, there's a lot more to be done at a higher level to advance web application fidelity. Some of my colleagues like Alex Faaborg and Alex Limi have been thinking a lot about how to do so from the user interaction perspective and I'm looking forward to working with them more to capture such details in open web standards specifications.

    I (heart) the Web For anyone who wants to work on "the open web platform", I can hardly think of a better place to be. Have ideas for improving open web application fidelity? Add it to my Mozilla projects inbox and I'll see what I can do.

  84. just gave a straw form annotation proposal @W3C #idbrowser workshop: http://tantek.com/presentations/2011/05/idinputs/

  85. interested in the W3C Identity in the Browser workshop? follow live minutes irc://irc.w3.org:6665/idbrowser #idbrowser

  86. OH: "The username is 'guest' and the password is 'password' if you want to try it out." #idbrowser

  87. wearing my Prisoner @t jacket http://flic.kr/p/9uUn7U to W3C #idbrowser workshop @MozHQ http://w3.org/2011/identity-ws

  88. Wonderful time in Warsaw #FalsyValues, London @OpenTechUK and Brighton with @adactio @wordridden. Back to SF. Spending time on the flight implementing a slew of improvements in @cassisjs thanks to @falsyvalues talks and attendee feedback.

  89. @michuk thanks! big fan of the identi.ca and status.net folks. #falsyvalues. cc: @powczarek @kaaes. in-reply-to: twitter.com/michuk/status/72621942712180736

  90. @powczarek @kaaes @michuk #falsyvalues: url*ca looks like spam. I noted Whistle diffs from other URL shorteners: http://tantek.com/w/Whistle. In short, Whistle is purely *algorithmic* and focuses on *personal-site* URLs, whereas other open source URL shorteners are *database-based* (they create and depend on hashes of ids that must be looked up, and are thus more fragile / break if database dies), and are intended for shortening *any* URL. I've noted the differences at the top of the Whistle wiki page tantek.com/w/Whistle. If you know of other algorithmically based URL shorteners, please let me know so I can cite/reference them as well and perhaps even re-use them. in-reply-to: twitter.com/powczarek/statuses/71584655131934720 twitter.com/michuk/statuses/71585171299774464.

  91. #falsyvalues: thanks for #CASSIS session kind words @varjs @razzededge @marcbaechinger @tmmx @marcoos, feedback: @gotomi @wbednarski @powczarek @michuk @kaaes @zbraniecki @cjno. Appreciated all of it. And thanks for the photos @michuk. Will follow-up on CASSIS issues/feedback from @cassisjs.

  92. Hey #falsyvalues: Green Coffee on Marszałkowska 84/92 near Novotel for @cassisjs follow-ups. Come by til 23:00 CEST!

  93. did first public @CASSISjs presentation @falsyvalues! great questions, ideas, interest, and controversy. #falsyvalues

  94. Thanks #falsyvalues #HTML5+CSS3 workshop participants for great questions and discussions! Please give feedback: http://falsyvalues.ankietka.pl/ and http://spkr8.com/t/7583 - much appreciated!

  95. via @IFTF: smallest 3D printer http://j.mp/3dp2kd. better: open source + self-replicating http://j.mp/3dp5hd ht: @asadotzler. World's smallest 3D printer www.innovationnewsdaily.com/worlds-smallest-3d-printer-1995/ costs $1700, but the open source and (mostly) self-replicating RepRap Mendel 3D printer costs only ~$520 in parts and they're developing it openly on a wiki: http://reprap.org/wiki/Mendel http://reprap.org/mediawiki/images/thumb/1/1f/Mendel.jpg/520px-Mendel.jpg

  96. #b2b100 first-timers: dad slowed his pace for me, I finished in 1:39:47. mom fast-walked in 2:09. finishers photo: http://flic.kr/p/9HLLwu farm6.static.flickr.com/5270/5723565192_20f31f184b_o.jpg

  97. #54991 heading out for #b2b100. track me on @geoloqi: http://loqi.me/kho7UvA get iOS/Android app: geoloqi.com.

  98. #b2b100 #54991 going to try a public @Geoloqi location tracking link from ~7am-11am. Signup and install their iOS app.

  99. #b2b100 #54991 gear: TRON t, runner tights, ziplock iPod4Touch+MiFi+BlackBerry; Blade Runner umbrella if it's raining.

  100. #b2b100 pen G plan: 6am wake, 650am #6 bus to Van Ness + Market, then MUNI T to Folsom, walk to entry at Folsom+Spear.

  101. all set with gear for a minimal Bay to Breakers outfit. #54991 pen G expect start ~830am. who else is running? #b2b100

  102. just taught David @Pescovitz (of @BoingBoing fame) how to sci-five @IFTF co-working session. cc: @adactio

  103. idea: high-end luxury goods (clothing, accessories) brand "FAKE". design a logo with nice type and the ironic attraction will do the rest. The lines write themselves: "... it til you make it.", "why bother pretending?", "authentic superficiality", "wear it on your sleeve, collar, chest, or behind." And the clothing tag copy as well: "Genuine FAKE merchandise. Accept no imitations." Inspiration from @verbal's photo: flic.kr/p/9H59oK farm3.static.flickr.com/2093/5715639159_914fc87d2c_o.jpg

  104. thanks @onesnowclimber @benward! http://tantek.com/relmeauth prototype can now upgrade read perms to write. #devnestsf

  105. #devnestsf Q: Comments on @ev decentralized id post http://j.mp/5epoi @kevinmarks http://j.mp/kmrpev ? longurls: http://evhead.com/2011/04/five-easy-pieces-of-online-identity.html http://epeus.blogspot.com/2011/04/evs-identity-map-ignores-what-we-say.html

  106. #devnestsf: "We used Mechanical Turk to sign-up for 7000 topic-specific Twitter accounts" -@Quora rep [TOS violation?]

  107. #devnestsf: @Klout story is interesting. people are getting free stuff, better service due to @Klout scores, partners.

  108. OH: "The DataMinr presenter would totally fail a Voight-Kampff test." #devnestSF

  109. at Twitter #devnestSF listening talks from @dickc @rsarver. new "TwitterGuest" wifi password = MacOSX wifi fail: http://farm3.static.flickr.com/2203/5714945496_288cefb4b8_o.png flic.kr/p/9H1Ac3 This is the icon you see in the MacOSX menubar when connecting to a secured wifi network that you have saved in your Network Preferences with an older password. No message indicating a problem, no opportunity provided to enter a new password. When is this going to get fixed in MacOSX?

  110. I'd pay $5/mo for Gmail Pro that was fast, no ads, more space. Or give me +100MB per confirmed phishing report #io2011

  111. OH: "Did you get your Gmail Pro beta invite?" #io2011

  112. NYT uses catshopped photo as "it really looked like" http://j.mp/nytcat ultra-orthodox censor women+cat longurl: http://krugman.blogs.nytimes.com/2011/05/09/unpeople/ and photos: http://graphics8.nytimes.com/images/2011/05/09/opinion/050911krugman3/050911krugman3-blog480.jpg http://graphics8.nytimes.com/images/2011/05/09/opinion/050911krugman4/050911krugman4-blog480.jpg

  113. #sfmusictech slides and demos http://tantek.com/presentations/2011/05/sfmusictech http://flic.kr/p/9G4F5a photo: http://farm4.static.flickr.com/3176/5704230757_435acd739e.jpg

  114. 1pm at #sfmusictech (Hotel Kabuki, Sakura room) demo of Firefox 4 #HTML5 Audio and Audio Data API. cc: @pauloppenheim.

  115. birds chirping outside = time for bed. #sfmusictech is 2011-05-09, come see/hear HTML5 audio and Audio Data API demos.

  116. HTMLWG preferred #HTML5 licenses: 31 MIT, 29 CC0, huge lead over W3C options: 6,11,7. http://j.mp/h5mc0 longURL: http://www.w3.org/2002/09/wbs/40318/html5-license-poll-v3/results I believe the support for MIT and/or CC0 licenses is even stronger than it looks as many of the W3C supporting answers stated arguments that have already been refuted. Will follow-up with a point by point blog post. Let's make open standards as open as possible which means using CC0 (the closest to international public domain we have) rather than bespoke licenses.

  117. Fellow HTML WG members: please vote in the #HTML5 license poll: w3.org/2002/09/wbs/40318/html5-license-poll-v3/results

  118. .@cwilso programmers invented multitasking using *one* CPU. Yes, it is *technically* multitasking. in-reply-to: twitter.com/cwilso/status/65828456805568512. The naysayers contort their definitions of multitasking to fit the strawmen they seek to burn (classic detractor methodological error). Per introduction to: https://secure.wikimedia.org/wikipedia/en/wiki/Human_multitasking "the ability of *a* microprocessor to *apparently* process several tasks simultaneously." [*emphasis* added]. The "multi" is about multiple task *completion* in parallel, not focus/attention. I have found that the key to *simple* (what I call level 1) human multitasking is to parallelize one or more high latency I/O bound tasks with at most one cognitively focused task. Multitasking multiple cognitive (often related) tasks is possible, even in realtime, but much more difficult and likely requires specialized training. Example: simultaneous translation.

  119. human #multitasking: the only field where being bad at it makes you an expert, e.g. gets citations on Wikipedia: https://secure.wikimedia.org/wikipedia/en/wiki/Human_multitasking. Are you a successful multitasker? Tired of those who can't do so acting like experts and telling you what you can't do based on methodologically flawed studies? Keep track of and write-up your successes (and current limitations) on a wiki page. Here's mine: http://tantek.com/w/EffectiveMultitasking

  120. almost 4 yr old nephew #2 asked to read "A Fish Out of Water" http://ttk.me/i/a/~32mfP and proceeded to read it to me.

  121. UX anecdote: Half my Caltrain rides someone in the traincar screwed up their Clipper card usage. Examples + FAQ: tagged on but forgot to tag off - I've done this (every extra step = drop-off in task completion success). Or bought a monthly pass and didn't bother tagging on at all (why do you need to track rides if a conductor can tell you have a monthly pass for the current month and you're on the train within range of your pass? because you *might* go out of range?). Also the minimum $1.25 "credit" you have to maintain just to use 8-ride or monthly passes is ridiculous. That's just the start of the confusion - see their FAQ for more: caltrain.com/Fares/howtobuy/clipper/Clipper_on_Caltrain_FAQ.html