tantek.com

t

  1. MacBook Air 11" reasonably setup: Adium, BBEdit, Colloquy, FaceTime, Firefox (with sync), Flickr Uploadr, WebKit.

  2. at OpenID Technology Summit hosted by Facebook, talking OpenID Connect, RelMeAuth. prepping USB key for MacBookAir xfer.

  3. answering the door in yoga workout clothes. holding a box with the future inside. a bit anxious about opening it.

  4. lucid dreamt a vague memory of something I'd browsed previously, successfully planted a reminder to search my browsing history when I awoke. Turned out it was a past dream that I was remembering inside the lucid dream. I can tell when I'm dreaming, but while dreaming I can't yet differentiate between recalling memories of real experiences and memories of dream experiences. Perhaps I need an undreamable talisman.

  5. OH: "And they will leave with an elevated sense of self-satisfaction; you can't put a price on that, Ariel."

  6. XHTML Is Dead, Long Live XML-Valid HTML5

    on

    Four years and two days ago, Tim Berners-Lee wrote Reinventing HTML where he infamously admitted:

    "It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn't work."

    and then went on to announce the plan to charter a completely new HTML group and a separate group to work on the XHTML2 work which the old "HTML working group" was working on. with the explicit caveat of independence: There will be no dependency of HTML work on the XHTML2 work.

    Similar words were said about XForms. Both moves (accommodating XHTML2 and XForms) were largely political, doomed from the start but perhaps providing a smoother, but slower, more face-saving termination path.

    Just over three years after Tim's blog post, W3C announced the end of work on XHTML2:

    "...when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed."

    Draconian = FAIL

    What Tim failed to mention, and what was perhaps the biggest nail in the coffin for use of XML (and thus "real" XHTML) on the web, was its draconian error handling. Here's an actual example I screen-captured:

    Foursquare screenshot showing XML error Safari: "This contains the following errors: ... Below is a rendering of the page up to the first error."

    Now, I was actually quite shocked to see this, as in practice nearly nobody (maybe Sam Ruby) serves content as "actual" XML or XHTML (content-type of text/xml, application/xml, or application/xhtml+xml), and this screenshot is exactly why.

    It's too easy for content to subtly break some form of XML-validity, and then have the browser provide an ugly and unfriendly warning message like the above. This happens because XML requires that browsers and anybody else that parses XML handle errors in a very draconian manner, that is, to stop processing at the first error.

    Given a choice, nearly no one wants the browser to stop displaying because of an error, and thus nearly no one serves XML on the Web.

    That's the real reason XML failed. Because a policy of draconian error-handling is a policy of failure.

    XHTML coding practices

    Getting back to Tim's points, I have no problem with including quotes around attribute values and slashes in empty tags and in fact have found that doing so, and validating as such, catches more errors sooner for me and thus I (as many web developers do) find it beneficial to code with such XML strictness.

    In general the practice of coding "compatible XHTML", based on the informative Appendix C. of the XHTML 1.0 spec, has been fairly well accepted by modern web developers as a best practice.

    But there are other aspects of XHTML that have no discernible benefit, for example:

    • xml:lang attributes, in addition to lang attributes
    • xmlns="http://www.w3.org/1999/xhtml" namespace declaration

    I haven't bothered with xml:lang attributes in quite some time. However, I have sometimes (inertia?) still included the xmlns XHTML namespace declaration.

    Prioritizing, minimizing, and losing some xmlns

    When I started coding Falcon (the code that now runs the home page and permalinks of tantek.com), I had to prioritize, minimize, and coded only what I needed.

    I used XML-valid HTML5+hAtom as the data store for Falcon. Natively viewable (HTML5), compatible with well known syndication semantics (hAtom), and easily readable/writeable on the server using built-in PHP DOMDocument interfaces.

    Eventually I noticed that I had omitted the xmlns XHTML namespace declaration and apparently didn't need it. The client (browser) didn't need it. The server (Falcon/CASSIS/DOMDocument) didn't need it.

    The only place I continued to use the xmlns XHTML namespace declaration was in my Atom feed, largely just quickly modeled/copied from my old Atom feed that I used to generate with HyperCard back in the day (only a few years ago, ahem).

    Does xmlns stymie Google?

    I use the xmlns declaration in a few places in my feed. Everywhere I have content, I wrap it in divs with the xmlns:

    • <title type="xhtml"> of the Atom <feed>
    • <title type="xhtml"> of each Atom <entry>
    • <content type="xhtml"> of each Atom <entry>

    If you look at my feed in either Safari or Firefox, you'll see the content as you might expect, with some browser-specific feed styling.

    If however you view my content through Google Reader, or see it syndicated into Google Buzz, you'll see that every entry shows the feed title with visible <div> markup, having errantly overescaped the contents of the feed's <title> element., e.g.

    screenshot comparing Google Buzz display of an hAtom entry and the equivalent tweet on Twitter.

    Nevermind the display of duplicate content from the title and the contents of the entry - Google should know better (either heuristically or due to the use of the Activity Streams note object-type) - but that's a separate bug.

    Google has known about the overescaping problem (failure to parse XHTML in Atom <title> elements) for over 3 months now (since July 13th 2010). They eventually added it to their public bug database last month. This seems like a small quick fix that should be trivial for the Google geniuses, and yet, no progress, no comments, and no estimate for when they might look at it.

    Google is in many ways helping spearhead and accelerate the development of a Federated Social Web, with their work on PubSubHubbub (including a nice easy to use hub), and work on the Salmon notification specification. These are huge complex tasks. But equally important is rapid iteration and fixing annoying little parsing bugs like incorrect double-escaping of nested XML/XHTML.

    To be clear: I'm not asking Google to handle some sort of broken markup for backward compatibility. I'm simply asking Google to parse Atom feeds properly as XML.

    Losing my xmlns

    I have been fairly outspoken about the failure of namespaces for content, XML namespaces in particular. I use xmlns in Atom only to avoid the even worse practice of escaping markup to embed markup inside markup (what RSS makes you do).

    However, remembering four years ago, and my own loss of xmlns in my HTML5 documents, I've decided to drop xmlns from the title of my feed as well - it's not necessary today, and highly doubtful that I'm going to include markup there in the future.

    Towards XML-valid HTML5

    Longterm I don't believe in Atom, nor any other draconianly fragile XML format. I include Atom simply because for now, it's a part of the glue for the Federated Social Web. In the future I can see replacing it with hAtom, parsed from HTML5 documents.

    However, I personally, as a developer and publisher, still see benefits from XML coding practices, not the least of which is being able to maintain HTML5+hAtom data stores (and thus avoid the even worse problem of database maintenance). So for now, I'm going to continue coding my HTML5 with quoted attributes, explicit closing tags, and self-closing empty elements, making them what I call "bi-glot" documents: both HTML5, and valid XML.

    I've given up on "proper" XHTML (by any definition). Long Live XML-valid HTML5.

  7. she suggested an afternoon rendezvous. a date? no not really, more like a brainstorming session. I think. #denial

  8. It's overcast, I have no Halloween costume, and still hate databases "1114: The table 'page' is full (localhost)"

  9. home. annoyed by SF political paper junkmail flyers overflowing my mailbox. is there a DO NOT MAIL list for them?

  10. sometimes those totally open heart to heart conversations do work. even over IM. friendship caring respect trust.

  11. Disable Java NOW / Why does the New York Times Chicken-Little HTML5 When Java Exploits Are Real?

    on

    A couple of weeks ago the New York Times (NYT) published an article with <title> "Web Upgrade HTML 5 May Weaken Privacy" and heading: New Web Code Draws Concern Over Privacy Risks which chicken-littled HTML5 with as far as I can tell, purely theoretical concerns while never having written an article about vulnerabilities from Java which are actually used and for sale.

    Evercookie: the return of Samy

    The NYT article mentions an "Evercookie" proof-of-concept created using new HTML5 features by Samy Kamkar who infamously "went to Chipotle and ordered ... a burrito" after launching his MySpace "Samy is my hero" profile worm which gave him over a million friend requests. Obviously Samy has established his credibility, but nowhere is it explained (not by NYT nor Samy) how his "Evercookie" poses any kind of real threat or exploit. Vague references to "tracking" and "privacy" are made without any actual explanation.

    Thus not an actual exploit (just a proof of concept), nor any documentation of actual potential harm. A prime example of chicken-littling.

    Java vulnerabilities empower exploit kits

    On the other hand, in his post Java: A Gift to Exploit Pack Makers, Brian Krebs lists and specifically documents (emphases mine):

    • Specific commercial (for sale) "exploit kits", like "Blackhole". (i.e. actual exploit implementations)
    • Effectiveness in the wild metrics: on average this kit finds a working exploit that it can use to install malicious software on a visiting host about 10 percent of the time.
    • Java vulnerability ubiquity compared to others: Java vulnerabilities are by far the most useful, comprising more than 90 percent of all successful exploits.
    • Multiple exploit kits' screenshots confirming Java's most vulnerable status: SEO Sploit Pack ... Java vulnerabilities are the most productive, accounting for between 50 and 65 percent of malware installs or "loads"
    • Naming more specific exploit kits that primarily leverage Java vulnerabilities: Crimepack and Eleonore

    Let me make this clear: these exploits allow outside attackers, to take over your machine, and then use it for whatever they want, e.g. extract your passwords and local personal data, or add your machine to a botnet (imagine Skynet but with (supposedly) a human (perhaps highest bidder) issuing the commands) for more nefarious distributed attacks on other machines.

    Theoretical and abstract vs. real and concrete

    Thus on the one hand you have the theoretical and abstract "tracking" danger from new HTML5 features reported by the New York Times, and on the other hand the real world concrete danger of having your machine taken over due to Java vulnerabilities.

    Brian wonders why this is so in the tech press in particular:

    "But for some reason, Java seems to get a pass from the tech and security press, even though Java flaws consistently are found to be the most useful for attackers who wield these automated exploit kits."

    I wonder too.

    New York Times, When Will You Cover Java Vulnerabilities?

    Dear New York Times, are you ignorant on web security, not doing your homework, or deliberately omitting coverage of Java vulnerabilities, perhaps afraid of being sued (as Java corporations have done previously and recently) ?

    Disable Java NOW

    Given the real threats that Java vulnerabilities pose to your machine, and frankly, it's rarely used for anything essential, I highly recommend you disable Java in all your browsers.

    Especially if you use a Macintosh, note that Apple has deprecated Java and will stop shipping it in software updates and software installs. This is especially important because if you check the official Verify Java Version page (noted by Brian Krebs in Java Update Clobbers 29 Security Flaws), you'll see a note for Mac Users:

    Mac Users: Use the Software Update feature (available on the Apple menu) to check that you have the most up-to-date version of Java for your Mac.

    Right, those software updates which have deprecated Java as noted. Time to bail.

    How to turn off Java in browsers

    Here's how you turn off Java in common browsers (these instructions are for Macintosh versions, Windows browsers are likely similar. If someone posts instructions for Windows browsers, I'll link to it.)

    • Camino 2: (thanks to Eric Meyer)
      • From the Camino menu, choose Preferences...
      • Click Web Features (with globe/switch icon) in the top row
      • Uncheck [ ] Enable Java
      • Close the Preferences window (titled Web Features at this point)
    • Chrome:
      • There is no direct UI in Chrome. You have to:
      • Go to about:plugins (if clicking that link doesn't work, copy/paste it into a new tab)
      • Scroll down to Java ...
      • Click the blue underlined Disable text link there
      • Consider disabling Flash and others too
    • Firefox 3:
      • From the Tools menu, choose Add-ons
      • Click Plugins on the top right
      • Scroll down the list til you see Java Embedding ...
      • Click on it to select it
      • Click the ( Disable ) button on the right
      • Scroll down the list til you see Java Plug-In ...
      • Click on it to select it
      • Click the ( Disable ) button on the right
      • Consider disabling Shockwave Flash and others too
      • Close the Add-ons window
    • Firefox 4:
      • From the Tools menu, choose Add-ons
      • Click Plugins on the left
      • Scroll down the list til you see Java Plug-in ...
      • Click the ( Disable ) button on the right
      • Consider disabling Shockwave Flash and others too
      • Close the Add-ons window
    • Opera 10: (thanks to Daniel Bergqvist)
      • Go to opera:config#Java|Enabled (if clicking that link doesn't work, copy/paste it into a new tab)
      • Uncheck the Enabled [ ] checkbox
      • Click [ Save ]
      • Click ( OK ) to dismiss the dropdown sheet
      • Choose Quit Opera from the Opera menu
      • Relaunch Opera
    • Safari and WebKit nightlies:
      • From the Safari menu, choose Preferences...
      • Click the Security (with lock icon) in the top row
      • Uncheck [ ] Enable Java
      • Close the Preferences window (titled Security at this point)

    Disabling Flash, though it has fewer vulnerabilities than Java, will likely cause sites to load faster, since much more network/CPU is wasted by all the Flash ads that sites have these days. I disable Flash everywhere but Safari and run ClickToFlash (the 1.6b9 beta works fine) to selectively run Flash on video sites like Hulu and YouTube.

    Disabling Java will not only increase security (by avoiding all the above-mentioned Java vulnerabilities) but it will increase performance as well because your browser won't waste any network time downloading Java applets, nor will it waste any CPU time running them.

    Increase your browsing security and speed. Disable Java Now.

  12. Apple right to stop shipping Java: http://j.mp/byejava. Made same decision in IE5/Mac 10 years ago. longlink: http://developer.apple.com/library/mac/#releasenotes/Java/JavaSnowLeopardUpdate3LeopardUpdate8RN/NewandNoteworthy/NewandNoteworthy.html More in Macrumors: http://www.macrumors.com/2010/10/21/apple-discontinuing-java-installation-packages-for-mac-os-x/ Java is nothing but dead-end enterprise maintenance at this point. http://ttk.me/t47v1 http://twitter.com/t/status/3249929969 Also, suing (Sun, Oracle) other companies (Microsoft, Google) is not how you make something (Java) succeed as an open standard of any sort, not the least with industry innovators and leaders. See aformentioned @lessig critique of legal system vs. innovation: http://tantek.com/2010/300/t2/sorkin-vs-zuckerberg-random-inefficient-law-tax I wonder when Google will abandon Java in platforms and just use a combination of ever improving Open Web App Platform support and native client interfaces, e.g. like mozilla.com/mobile Firefox 4 beta uses on Android.

  13. looking forward to curry tonight at the London Unity with Brighton friends 18:30/19:00 BST. Feel free to join us!

  14. [#needspost #ux] "It's not meant to be a strife. It's not meant to be a struggle uphill. Undo undo. If you're bleeding, undo. If you're sweating, undo. If you're crying, undo." Good advice for relationships and user experience design. Interfaces shouldn't be a strife, a struggle uphill, nor make you bleed, sweat, or cry. Interfaces should be generous, the kindness kind, quietly ecstatic, and forgiving. Gmail Labs' "Undo Send" extension gets this right (without the cognitive load of previous attempts like scheduled sends). All forms of send/post/tweet verbs should be as forgiving. If you're regretting your sending, undo. See related article on Undo Send: http://gigaom.com/collaboration/google-tweaks-gmails-undo-send-labs-feature/

  15. On a train to Brighton listening to Björk. Next stop: Taylor Street Baristas for coffee and lunch ETA 12:30. Recharging in the bright sun... "All that she said was true. All that she meant was good."

  16. Square Pig closed! @MozPub meetup moved to Ship Tavern, Gate st. Exit Holburn, left Uturn to Gate. Find @han, wearing leather jacket, navy hoodie, scarf, boots, and has very short red hair. I'll be waiting outside Square Pig to redirect folks for a bit.

  17. "Always keep making stuff, it keeps you in that mode of creating and learning" @jina via @birdsoar. I'll add: publish the stuff you make publicly, use it yourself, fix what bugs you, accept feedback, iterate.

  18. 1st good night's sleep in a week. beautiful and sunny in London. braving fractals, reflecting and repairing. after yoga.

  19. heading to Hyatt lobby before "U Szwejka" (#ft2010 after-party). Mission complete, fancying a bit of coding or blogging.

  20. kicking it at Hyatt Warsaw before #ft2010 after-party, with Blade Runner on Samsung via MacBook. "It's a test designed to provoke an emotional response."

  21. The Geolocation API is a @W3C Candidate Recommendation http://j.mp/crgeo "believed to be stable ... encourage implementation by the developer community." longlink: http://www.w3.org/TR/2010/CR-geolocation-API-20100907/ The Geolocation API (often miscategorized by technomarketers as part of "HTML5") is the first of the Open Web App APIs that has reached CR - quite a big deal, given that all the rest of them are still merely Working Drafts (or Editor's Drafts). Even HTML5 itself is still just a working draft. And this is a perfect example of why it's important to be precise about what is "HTML5" and that is one thing: http://www.w3.org/TR/html5. All those other things like CSS3, Javascript, other APIs etc. that we use with HTML5 to build Web Apps are better referred to as "related technologies."

  22. barely resisting temptations to reflect on recent experiences nearly fractal in complexity seeking understanding.

  23. After 5 years, Apple finally ships a laptop smaller than the PowerBook 12", (93.7 vs 89.2 sq in MacBook Air 11").

  24. ok emotions, shutting you down for a while, your distractions + cognitive load almost made me miss my flight. reflecting and repairs will have to wait until after this mission is over.

  25. ~2 mo. ago @BenWard designed a granular @Twitter OAuth UI http://ttk.me/t47J1 and in 2 weeks he starts there! Congratulations to both and looking forward to seeing more ground-breaking OAuth / delegated identity/authentication functionality and user interfaces.

  26. Leaving Las Vegas. Good times and nice meeting everyone at BlogWorld Expo #bwe10. Still learning lots about many things.

  27. Facebook Is Using HTML5 Now And You Can Too

    on

    There's been much consternation recently about the supposed stability and reliability of HTML5 due to the InfoWorld article link-baitingly-titled W3C: Hold off on deploying HTML5 in websites. The article interviews W3C interaction domain leader Philippe Le Hegaret and quotes him saying things like:

    "... it's a little too early to deploy it [HTML5] because we're running into interoperability issues ..."

    and

    "I don't think it's ready for production yet,"

    and

    "The real problem is can we make [HTML5] work across browsers and at the moment, that is not the case."

    I know Philippe, and I have a feeling that the quotes in the InfoWorld article may either be abbreviated versions of what he actually said, somehow taken out of context, or perhaps reflecting a "glass is half empty" perspective.

    Regardless, those quotations, taken on face value, are provably false.

    HTML5 Has Plenty Of Interoperability Today

    First, there is plenty of HTML5 with zero interoperability issues (e.g. DOCTYPE, meta charset, most of the semantics, and many APIs too.) that you can safely use across browsers.

    I know because I've been coding with HTML5 and teaching workshops on practical HTML5 for over a year. I found there was so much that was usable cross-browser that I was inspired to write my first book and video tutorial about it: HTML5 Now - ~46 page booklet, 2.5+ hours of video, ~100 page PDF eBook - the vast majority of which covers HTML5 features that work reliably today.

    And yes, just as there are parts of HTML5 that interoperate very well, there are also some features you can't yet depend on. I choose to focus on the positive here ("glass is half full") and perhaps that's the difference in perspective. Regardless, it's irresponsible to make a general statement stating it's too early to deploy HTML5, because there's plenty of HTML5 you can safely deploy right now.

    But you don't have to take my word for it.

    Using HTML5 Today In Production

    David Recordon wrote a nice post on Facebook titled simply Using HTML5 Today where he listed some features from HTML5 and related technologies that Facebook is using, right now, live, on their production site, including:

    • HTML5 <video> element
    • HTML5 History interface - helps maintain cleaner more robust URLs even when using AJAX to change the state of the page.
    • Geolocation API - which just over a month ago became a W3C Candidate Recommendation, meaning:

      W3C publishes a technical report as a Candidate Recommendation to indicate that the document is believed to be stable, and to encourage implementation by the developer community.

    Facebook is also experimenting with other Web Applications technologies such as:

    Both of which are Working Drafts, the latest public versions of each are almost a year old as of this writing, and should really be updated to the most recent editor's drafts.

    More Support For Using HTML5 Today

    Many have responded to the InfoWorld article and its chicken-littling of HTML5. Here is some additional reading:

    Yes the battle for the Open Web is not over yet, however, the least we can all do is not FUD our own efforts.

    Let's eagerly advocate what works well today, while honestly admitting what is still "in progress". As time goes by and more and more of what's "in progress" becomes "what works well today", web developers will see the consistent trend and get the message.

  28. dropped Chrome as Gmail browser due to bugs: (Send) button NOP, Southwest checkin err. FF4 works. disclosure: Mozilla pays me for web standards work: https://wiki.mozilla.org/Tantek-Mozilla-projects however my tweets, posts, etc. are my own opinion, not theirs. That being said, I encourage you to try the Firefox 4 beta: mozilla.com/firefox/beta and compare it to others in terms of performance/reliability/fidelity. Give feedback using the [Feedback v] button in the top right next to the search box.

  29. 761 is a Nam-shub and is rewiring my brain. Anyone else? I can't be the only programmer affected. #needspost

  30. #openwebfoo memes replicated: 1 "snowflake" = site API vs standard. 2 "761" = xkcd.com/761 DFS vs BFS. #needspost

  31. congratulating @c @k on a beautiful and inspiring wedding. thank you for sharing your joy, happiness and love #101010kcc

  32. #openwebfoo lunchtime ask to @evanpro: I want Salmon PubSubHubbub Hub that accepts slaps on my site's behalf, aggregates all the slaps, and then notifies my site via Salmon slaps, or other notification standards like Pingback, Trackback, perhaps a WebHook, or even allows my site to poll an ActivityStreams feed of comments/tags/likes/faves etc. from the Salmon Hub. Delegating slaps to a Salmon Hub would allow it to handle spam, DoS attacks, etc. rather than placing those burdens on every independent site.

  33. What is the Open Web?

    on

    I just arrived at O'Reilly's Sebastopol Campus where they're holding a *Camp event on the open web, eponymously named "Open Web Foo Camp". A few days ago I was speaking with Jim Dwyer of the New York Times about the Federated Indie Social Web vs. sharecropping and site death (more on that in another post), and he happened to ask me (probably because I mentioned it in passing), what is, or what do I mean by "the open web".

    At the time I didn't have a working definition, but apparently provided an answer good enough for a self-described non-technical journalist to "get" what is the open web. Here's roughly what I told Jim, off the top of my head:

    For me the Open Web is about the ability to openly do three kinds things:

    1. publish content and applications on the web in open standards
    2. code and implement the web standards that that content/apps depend on
    3. access and use content / code / web-apps / implementations

    Each of these merit a bit of expansion.

    Publishing content and applications

    The web has brought with it the biggest revolutionary advance in access to publishing since the printing press. It's quite cheap to buy a domain (a few dollars per year), cheap to buy web hosting service (a few dollars per month), easy to open up a built-in or free text editor on any popular computer to write some HTML and CSS, and use a built-in or free FTP (or other file-transfer program, e.g. scp) to publish your content to the web, at a permalink instantly viewable by millions world-wide.

    Yes, with a few dollars a month and a few hours, you can publish and reach hundreds of millions of people. I call that revolutionary.

    This ability to openly publish depends on a few things:

    • open formats for freely publishing what you write, photograph, video and otherwise create, author, or code (e.g. HTML, CSS, Javascript, JPEG, PNG, Ogg, WebM etc.).
    • domain name registrars and web hosting services that, like phone companies, don't judge your content.
    • cheap internet access that doesn't discriminate based on domains

    A few non-open-web examples:

    All of those are examples of threats to the open web. For more on how H.264 is not open, and neither is Flash, despite all the rhetoric from Apple and Adobe respectively, I highly recommend reading Ben Ward's blog post: Understand The Web.

    Coding and implementing web standards

    The open web is fully dependent on browsers, search engines and other applications and services being able to code and implement all the web standards (formats, protocols) that authors use to publish their creative works. The browsers, search engines and other such "user agents" in turn depend on web standards that are:

    • openly documented, in this day and age, on the web itself.
    • freely accessible. there should be no charge to view a web standards specification.
    • unencumbered by patents, either patent-free, or available under unconditional royalty free licenses.

    Most W3C and IETF standards for example, meet these criteria. So do open public-domain based efforts like microformats.org and other modern "social web" standards (too many to list here, maybe I'll add a few links later :)

    A few non-open-web examples:

    • Numerous ISO standards. E.g. ISO-8601, the standard that web standards have subsetted to represent dates and times on the web. You have to pay to download ISO-8601 and other ISO standards. Not open.
    • Flash. Not anyone can freely implement support for the constantly evolving Flash format. It's Adobe's proprietary code, with who knows how many patents that apply to it (no I haven't checked).

    Thankfully, as the process of how we develop web standards themselves evolves, we get better and better at both providing very openly accessible and implementable standards, as well have become more sensitive to attempts to thwart the opennness of web standards.

    Access to content and applications on the web

    The web, and the internet as a whole, depends on the independence of content and addressing (i.e. domain names) and devices. You must be able to serve and access any kind of content across any domain name on any web device. Obviously not all devices will be capable enough to support all formats, but that should have nothing to do with the nature of the content itself.

    This open access depends on the open ability to browse and use any web page or application (i.e. URL) on your:

    • web browsing device
    • internet service

    And this must be without censorship per domain, URL, content-type, or nature of the content.

    A few non-open-web examples:

    Much of this "open access" requirement for the open web is also known as "net neutrality", and championed by none other than Senator Al Franken as the foremost free speech issue of our time.

    And that's my rough working definiton of what is the open web. In summary:

    • open content and application publishing
    • open ability to code and implement the standards that such content depends on
    • open access to content, web-applications, web standards implementations (browsers), and the internet.

    I think this is a good starting point for a discussion of what is the open web, and look forward to feedback and learning from my colleagues, both online, and in-person this weekend.

    Translations

    Referencing Articles

  34. .ly fail. Libya censors vbly http://j.mp/dzNM6F predicted 1.5yrs ago http://j.mp/Lyfail cc @dotben longurls: http://benmetcalfe.com/blog/2010/10/the-ly-domain-space-to-be-considered-unsafe http://twitter.com/t/status/1433557455 http://twitter.com/t/status/1434708098 http://twitter.com/t/status/1439537858 @dotben @violetblue - I suggest you recreate all vb_ly links on bit.ly and see what happens. How long til bit.ly is censored as well? Even more longurls (from tr.ims in aforemetioned tweets) http://en.wikipedia.org/wiki/.ly http://workbench.cadenhead.org/news/3503/bitly-builds-business-libya-domain

  35. yoga shower pack coffee subway airtrain checkin lunch board fly bart muni home. go.

  36. excellent @scrawford midday-2 #ovc10 keynote on CableCo wired access consolidation threat, @alfranken + more: Franken is one of few voices in the Senate that "gets" technology (net neutrality as the "foremost free speech issue our time"). Susan Crawford encouraged everyone to speak-up and have their voices heard. See: http://blog.alfranken.com/2010/08/05/cnn-senator-franken-op-ed-net-neutrality-is-foremost-free-speech-issue-of-our-time/ and http://www.cnn.com/2010/OPINION/08/05/franken.net.neutrality/

  37. Deconstructing and Reconstructing Part 3: Market, Meetup, Jazz, And Personal Site Improv

    on

    Despite the previous evening's liquid fueled lateness, somehow I woke up refreshed. It was as if some things were resolved that I didn't know needed to be. For the first time since I'd left home, I managed to do a half hour of yoga.

    After a quick grapefruit, coffee, and apricot juice breakfast, Hannah and I went to the local farmer's market and picked up some vegetables, fresh bread, a spinach quiche, and a slice of apple pie.

    The spinach quiche kept us going while we each took care of a few things, bills, various random tasks, and last minute organization of a pub meetup later that night, detailed on Plancast and announced via Twitter naturally.

    The Crown Tavern

    We arrived about 15 minutes early at The Crown Tavern and started sampling their drinks. One or a few at a time, various London friends started showing up, some I'd seen a couple of days ago, some I hadn't seen in over two years.

    As geeks often tend to, we compared and discussed cameras while waiting for our food. Despite the limitations of their Sunday menu, there were several vegetarian choices. I started with the tomato mozzarella basil salad and mini crabcakes, and had the lentil veggie burger for my main. It was all quite delicious, far beyond what I would've expected from a tavern. They even made a proper ristretto espresso with Illy coffee, served in a small eponymously branded cup.

    Canals And Jazz

    We were quite stuffed and the pleasant evening called for a walk. A few folks headed home but the rest of us walked along a long canal where we saw quite the variety of small cafes, street art, new developments, as well as houseboats docked to the sides.

    Eventually we found ourselves in Dalston where Matt, Hannah, RJ, and I would make our stand for the rest of the evening.

    Never before had I seen such a mixed hive of sharp dressers, a spectrum of hipsters, and the oddly out of place chav clusters. Fortunately we arrived early and managed to grab a couple of small tables. As the place filled up it was far too easy (and tempting) to snap over-the-shoulder shots of the amazing array of individuals.

    The band was quite good. As relaxed as the day had started out, a bit of live jazz was the perfect closer.

    Scrambles And Site Updates

    Hannah and Jamie were wonderful hosts and I finally had the opportunity to repay them just a bit for their hospitality. With ingredients we'd picked up from the farmer's market and some fresh eggs, I made a mixed vegetable scramble for brunch that seemed to go over quite well.

    Since I first attended SXSW in 2002, I've noticed that web conferences tend to be a bit like balls, the kind you dress-up for. Especially if you're speaking, but even if you're just attending, you know that lots of new people will be inevitably asking you for your site and taking a look. Conferences provide perhaps the necessary impetus to finally make progress on personal site updates that we've been procrastinating.

    Both Hannah and I were feeling this; she didn't really have much at her own domain, and my site was far too cluttered since I'd started rebuilding it at the beginning of the year. Her challenges were mostly around coding and configuration, and mine were clearly design and layout. It was a perfect opportunity to do some pair web development, on both our personal sites, in parallel.

    No Plan, Just Improv

    We didn't really have a plan, we just knew that together we had the skills to accomplish what each of us wanted to accomplish, and that if we just started riffing on our existing work, together we might each actually get to where we each of us wanted to be.

    As I cleaned up bits and pieces of my markup in preparation for a redesign, Hannah worked on a visual design for her site. Pressed for time, rather than create a brand new site from scratch, or take the time hassling with WordPress install, setup, configuration, theme authoring, she decided to go with using Tumblr for her "content management", though she had concerns about design and layout flexibility. I'd done enough Tumblr theme hacking to assure her that it would be no problem to convert her Photoshop visual designs into Tumblr template HTML + CSS.

    This is something I'm seeing more and more designers do (e.g. Dan Cederholm, Timoni West) - that is, switch from either blogging software like WordPress or their own custom site code, to using Tumblr for their content (served at their own domain names - a nice Tumblr feature), with a hand crafted template to their liking.

    Hannah and I worked late into the night. She gave me a simple grid to implement, then I got stuck on site headers/footers which she quickly addressed. She created the various images for her overall design, and I helped her put them in all the right places with CSS: backgrounds, fixed position elements, little cute affordances.

    Things wouldn't look quite right, so Hannah measured precise pixels in her designs, which I helped translate to CSS rules on the respective elements. Our absence of a precise plan provided just the freedom of expressivity/creativity that we apparently needed, and everything just flowed from one thing to the next.

    We successfully completed client-side bits of our respective redesigns (as much as any web design can be "complete" as opposed to a state of constant iterative improvement).

    Of Domain Names And Propagation Magic

    Just one thing remained, which was setting up the necessary A-record and C-name (yes, exactly, the whats?) for Hannah's personal domain to show her nicely styled Tumblr content, without doing any redirects. We tried following the Tumblr directions and couldn't quite get things working. Likely something to do with DNS propagation, or her hosting provider, or her domain name provider.

    Server configuration is definitely much more of a pain than any front-end work. So many fragile moving parts, where the slightest mistake in any of them can break something, or leave open a security flaw, or both. Not exactly a paragon of usability.

    We decided to call it a night. Over the next 24 hours I read up on some of the more ridiculous details of A-names etc. (which, if you want to understand some of the more arcane aspects of how domain names work at all, you might consider doing), propagation times, timeouts etc., and figured out a series of steps that should help us accomplish our goals.

    That next night, from my hotel in Brighton (more on that transition in part 4), I IM'd with Hannah who was still in London, and we walked through the steps necessary to setup her site to serve her content, and in addition, a way to use her own hosting provider to quickly serve static content such as her style sheets and stylistic images. We got it working as best we could and waited for all the necessary bits to propagate (something nearly any DNS related change requires). By the next morning, with just 24 hours to go til dConstruct, it all worked.

    Site reconstruction, complete.

  38. sinking realization: I was @Technorati when "blogging" was sold as "conversational media", which later mutated into "social media". Dear Darwin what have we done.

  39. just ate the most awesome Turkish food I've had outside mom's kitchen. Istanbul Park, 293 7th ave @ 7th st. Brooklyn NY 11215. Incredibly tasty and underpriced. Lentil soup, shepherd salad, spinach dinner, okra, baklava, Turkish tea. Simply amazing. If you're in NYC you MUST check it out (only a block from F train 7th ave stop) and tell them Tantek or @Aysan sent you.

  40. CSS3 Color Disposition of Comments And Update

    on

    I just participated in the CSS Working Group telcon for the first time in a while (like Hixie, I'm not a huge fan of telcons). We're giving CSS3 Color last call commenters a week to follow-up on our responses, then arranging a "transition telcon" with the W3C Director to move the spec to Proposed Recommendation (PR)!

    Thanks to co-editor Chris Lilley for writing up the email responses to last call commenters and the CSS3 Color Disposition of Comments as well.

    Special thanks to co-editor David Baron for developing the CSS3 Color Test Suite, running the tests, and writing up the implementation reports which demonstrate that we've had interoperability (what you need to transition to PR) for quite some time, with Firefox leading the way with CSS3 Color.

  41. Why Do CSS Spec Improvements Take So Long?

    on

    Recently my blog was added to the Planet Mozilla aggregator thanks to a nomination from Asa Dotzler. So if you're reading this post over there, hello, and thanks for having me. Be forewarned that not all my posts will be about open web standards - you'll likely see a bunch of personal posts as well. It is my personal blog after all and I do tend to write about whatever is on my mind.

    Four months ago I started contracting at Mozilla to work on several standards in the areas of Web Applications UI and Web Identity, as well as reach out to the broader web design and development communities on those same topics.

    Rather than provide a broad but shallow list of things done etc., I thought it would be more interesting to take a moment to explore one particular question that I've heard from the community from time to time, not in these exact words, but in general:

    Why do CSS spec improvements take so long?

    The answer involves quite a few things, but perhaps it is time we start talking about them, maybe even just one or a few at a time.

    First and foremost, editing W3C drafts is a royal pain.

    Nevermind the process (or typical W3C member costs!) for joining a working group, or (re)chartering a working group, or IP battles, or even the frustrations of getting CVS working with W3C's setup (I'm working on making that less painful, see related resource: W3C CVS For Dummies), all of which contribute to an excessively high barrier to materially participating in the evolution and iteration of W3C specs ( = very few people have the time, money, focus, persistence to do so - I for one am fortunate that Mozilla, with their mission of supporting the Open Web, has hired me to do so, and thus I am able to spend a lot more time on them).

    Here are three recent CSS drafts that I've edited as a case study to explore some of the challenges.

    • CSS Style Attributes - a fairly simple draft, documenting how the 'style' attribute in HTML works (and in any other language that has one as well). This draft is largely stable, done, etc. and now just waiting to be officially published as a Candidate Recommendation (CR). What's left?
      • According to the W3C Process Document, numerous specific tasks - most of which reasonably asks for public documentation.
      • In this case, the last remaining step is to schedule a teleconference with the W3C Director, presumably to make sure the aforementioned steps have been taken, and then get a date for publication. Typically the W3C staff contact for the working group arranges the telcon. If they or the Director are particularly busy, this can take potentially weeks.
    • CSS Color Module Level 3 - this draft is more extensive, but has already been through a Candidate Recommendation stage, then taken back to Last Call, and with a test suite and implementation reports demonstrating interoperability, it should be ready for publication as a W3C Proposed Recommendation (PR). Once again, the W3C Process regarding a PR provides the necessary steps, which typically require a teleconference with the Director, again, arranged by the working group's W3C staff contact. Similar challenges to the previous draft, however, more of them, as PR is a higher bar to meet. Because there's more work to do to get CSS3 Color to PR, I've decided to keep a list of the CSS3 Color tasks to PR on the CSSWG wiki.
    • CSS3 Basic User Interface Module - this draft was published as a CR many years ago, and since then, browsers have implemented most of it, as well as a few other CSS UI related features such as the 'pointer-events' property. However, CSS3 UI faces much more difficult obstacles than the other two drafts - it's no longer officially in scope for the working group.

    For the first two drafts, CSS Style Attributes and CSS3 Color, what's taking so long now is essentially a set of bureaucratic checks and balances. I'm fairly confident they'll be taken care of in days or at most a few weeks.

    For CSS3 UI, the problem started because in the previous rechartering of the W3C CSS Working Group, doing work on "user interface" was completely dropped. That means that until the group recharters again, it can't publish any official drafts pertaining to that subject area.

    Fortunately, the W3C CSS Working Group discussed rechartering at the recent meeting in Oslo, and decided to re-include "user interface". With any luck the rechartering process will complete relatively soon, and by sometime in November, the groups will be able to officially publish a new draft of CSS3 UI. Until then, you'll have to just keep up with the above-linked unofficial public editor's draft.

    And these are just three out of numerous CSS3 drafts in development. Each of which requires a diligent editor (or a few!), familiar with W3C's CVS setup, that regularly updates the editor's draft, and keeps up with emails, issues, etc. related to their draft(s), nevermind figuring out what specific next steps need to be taken to advance the draft(s) along in the W3C's process. It's a lot of work for just a few people, no wonder it takes so long for CSS drafts to make progress!

    I hope that sharing some of these details has helped at least provide a better understanding of some of the challenges with pushing standards forward at W3C. I think there's a lot of potential for improvement. For example, the CSS Working Group has been doing a lot to encourage more community participation, e.g. with requests for contributions to test suites to help demonstrate interoperability.

    There's probably more that we could do though, with spec-editing, and perhaps with help simplifiying the overall process as well. If you've got suggestions for the CSS Working Group, or W3C in general (e.g. regarding the W3C's processes), perhaps write up a short blog post, and tweet it, referencing @csswg and @w3c respectively.

  42. worked on CSS3 Color a bit more and now writing a blog post about W3C, CSS, and pushing standards forward.

  43. Ok Monday, I hear you, but it's summertime in SF and I'll be getting to you soon enough, one cafe at a time.

  44. doing 3D trigonometry to map globe clicks to lat-longs with Anton and Stoian (nerds not on Twitter!) @ #ampedweb.

  45. I'm on Twitter since 2006-11-07. My #first5 followers were @ev @missrogue @MJ @Kitta @ifindkarma. feedback @michielb : http://firstfivefollowers.com/ is nice work. 1. Default euro date format, e.g. "07-11-2006" is confusing (July 11 or Nov 7?) - why not use ISO-8601 dates instead and remove ambiguity? More i18n friendly. 2. Could compress sample tweet by changing "first 5" to #first5, and remove commas + "and" from followers list; the "@"s already act as visual list-bullets in a list of Twitter aliases.

  46. Deconstructing and Reconstructing Part 2: London Craziness, Failure, and Dancing

    on

    After wrapping up a successful CSS work week in Oslo it was time for a long weekend in London catching-up both with good friends I mostly hadn't seen in years and a new friend I'd recently met in the states. Flying from Oslo to London, it really struck me how much closure a few days had brought, both personal and professional, as well as getting unstuck on a number of things.

    Slot Machine Connectivity

    It's possible that turning off my mobile data access (due to pricey international data roaming on AT&T, even with a prepaid plan), and thus curtailing nearly reflexive reading of Twitter, Foursquare check-ins, and IM had helped encourage better focus, and thus greater productivity.

    You might think that AT&T's terrible San Francisco reception would provide a similar experience, but it doesn't. There's something very different about predictable rare but good service (e.g. only connecting via wifi, or briefly turning on international data), vs unpredictable spotty service.

    The unreliability of the latter almost encourages more reflexive mobile usage, perhaps not unlike a five column slot machine - you never know how many bars you'll get, and when 1-2 bars turn up, it gives you irrational hopes of maybe scoring 5 bars, so you keep playing.

    The answer then, would be to only hangout places that give you predictable connectivity (cell and/or wifi, none or a lot), so you know what to expect and can plan/use your time respectively. Amazing, or perhaps appropriate, how total lack of connectivity on a flight can inspire insights into the psychology of connectivity.

    last.fm Techmosis

    or, Six Crazy Projects And More

    After a brief delay at Heathrow waiting for the express trains to resume running from an unscheduled shutdown, I headed to last.fm headquarters to meet my host for the long weekend and give an informal talk.

    Tantekmosis

    Hannah had asked me to give a brief Friday afternoon "Techmosis" guest talk to their engineers (a last.fm tradition) on a topic of my choice, and then join them in their regular Friday Halo session. I sent her my list of crazy topics and for some reason she agreed. Armed with nothing but a white board and a web browser, I launched into an exploration of Six Crazy Projects that I'd been working on during the past couple of years. In rough logical temporal topical order:

    • bi-glot programming - creating a language+framework for writing/running code natively simultaneously in Javascript and PHP: CASSIS
    • Babylonian calendaring mistake - what happens when you correct a Babylonian calendaring mistake? You get a NewCalendar
    • base 60 numbers - What do you come up with when you need a print-safe character compression scheme for an algorithmically reversible personal URL shortener? A NewBase60
    • short URLs - How do you make good (or at least harmless) short URLs? With an algorithmically reversible personal URL shortener: Whistle
    • personal publishing - personal publishing software including a server-based Twitter client: Falcon
    • identity and authentication - By learning from the real-world successes of the rel="me" microformat and Twitter Sign-in, and using them as design and architectural foundation, how do you enable using your personal web identity for signing-in and authentication? RelMeAuth

    The last.fm folks asked some great questions, most of which I had reasonably good answers for. Afterwards I asked if they were interested in a couple more crazy projects, and they encouraged me to go on:

    • remapping the planet with octal geo coordinates - an octal-based geo-coordinate system that works well as the basis of base 64 algorithmically reversible geo-shortlinks: OctalGeo
    • print+URL safe base 64 numbers - a base 64 counting system that is print-safe and URL-safe for encapsulating a pair of octal digits in a single character: NewBase64

    And this was when things got really fun (if you're into nerdy topics like algorithmic geo short URLs :).

    Cubespace Debut

    Last.fm's Robin Lisle asked about how would you use OctalGeo to specify not just a location like an address or building, but also a floor or level of a building, giving the example of tall skyscrapers in Japan (or potentially any city).

    At this point I had to go completely off-web and on-whiteboard, because I had thought about the problem of compressing three-dimensional geo-coordinates (even collected some ideas on paper and text files) but had yet to write anything up on my wiki, or frankly, even run the ideas by anyone else.

    I briefly whiteboarded the derivation of Cubespace. Just as OctalGeo subdivided 2D geo-coordinates into ever shrinking 1/64th squares for each digit (3 bits for x and 3 bits for y), I drew a cube, subdividing edges into 4 segments each, faces into 16 squares each, thus a whole cube into 64 subcubes, and announced: this is when we enter Cubespace.

    By encoding 2 rather than 3 bits per coordinate, in 6 bits we can represent 3 dimensions rather than 2. Simple math (or "maths" as the English call it, as Jeremy would teach me two weeks hence).

    By combining the two encodings, it is possible to first use OctalGeo digits to specify a square of area on Earth (WGS84 projection) that is no wider than the twice the desired absolute value altitude, and then switch to CubeSpace to refine that square with a cube of the same size, half above, and half below the surface, with a digit for each 1/64 subcube of additional precision desired.

    And suddenly it was time for drinks, eats, and a movie.

    Scott Pilgrim vs. His Mistakes

    The next 24 hours started simply enough. Drinks with last.fm friends at a local pub, then a burrito (yes, in London, and it was quite good), followed by a viewing of Scott Pilgrim vs The World. With each viewing of Scott Pilgrim, both new lessons found, and old lessons reinforced.

    Pilgrim's character makes plenty of mistakes in the movie, and even more are hinted at in his past. But despite these mistakes, he still "wins" and gets the girl. Why?

    Because it's just a movie, that's why. That being said, many of the film's characters are reasonably well written, and some of the points made resonate with at least my personal experience - video-gamesque fights notwithstanding (though watching the movie repeatedly has made it hard not to see blinking bonus numbers appear and float upwards every time I complete some task or new achievement).

    Despite it being an oft-repeated startup cliché, you can learn a lot from your mistakes. You can learn a lot from others' mistakes too. Everybody makes mistakes. What matters is how you deal with them, what you do next.

    Making The Best Of Failure

    Still exhausted from a week of CSS working group and spec-writing intensity, I slept in, again. And I'd also just run out of laundry. Lucky for me my hosts Hannah and Jamie had a washing machine so I started a load. No matter I thought, the plans I'd made with my other friend were only vaguely scheduled sometime that day/afternoon, and I went ahead and communicated where I was at / up to.

    About 4pm I finally started making my way over to meet up and messaged as such, within minutes I got an angry response about it now being kinda late. And now that sinking feeling: in an ambiguous situation, I had guessed wrong, misinterpreted, probably miscommunicated, screwed up, and made the person I was going to meet angry and upset.

    Oh I tried being flexible, suggesting alternatives, hoping to salvage something, but despite effort and apologies, apparently my implicit scheduling failure had caused too much misunderstanding, thus, shut down again. Sometimes it's good to know when to give up on a bad situation I suppose, and let failure be.

    About that learning from mistakes thing. You can often learn more about someone by how they deal with mistakes than their making (or avoiding) of mistakes in the first place. And when you make a mistake that impacts someone else, and deal with it as best as you can, you can learn a lot about them by how they respond to your making and dealing with a mistake.

    In this case, it became clear that from my perspective, not only was I apparently given a very low margin for error, but no chance of recovery in case of error. I wouldn't figure out the further implications (best to just not hangout with this friend) for a few days hence.

    Pouring Into A Dance

    My hosts graciously dealt with my resultant emo-implosion at having not only screwed something up with an apparent delay, but hurt someone's feelings at that, and my sense of helplessness from being unable to fix it.

    We ended up having a nice late lunch out, and afterwards, Hannah took me out to a couple of pubs. Suffice it to say I sampled plenty of cider, vented most of what I felt at the first pub, and by the second pub was looking forward to what/how could I do better, both eventually and tonight.

    After a swift evening walk, stopping only to pet a kitty on someone's stoop, we arrived at The Lexington, where sampling whiskey is what one does. Hannah introduced me to a friend of hers from out of town, who was supposed to crash with Hannah but couldn't, apparently since I was crashing there.

    Still, we did hit it off a bit, discussing the politics of science, and either Neuromancer or Snow Crash. I'm pretty sure it was Neuromancer, but by this pint, details had become fuzzy.

    Upstairs there was a band or DJ playing, which was apparently sufficient motivation to pay the £10 cover and head on up. I don't remember the name of the whiskey we ordered. No matter, there was a dance floor.

    We must have spent an hour or two talking and dancing, mostly dancing, some dancing with talking. I do appreciate someone who can dance for the fun of it, and enjoy it for what it is. It was simple, it was nice, it was right, and it sure wasn't going anywhere else.

    Sometime in the singleton hours, I met up with Hannah, who was also ready to call it a night. I bid my new friend goodbye with a quick kiss on the cheek. Later I'd find out that she's apparently a popular comic writer and illustrator, and the fact that she'd actually bothered to spend that much time hanging out, talking, and dancing with me may have meant something. Again, I failed to pick-up on subtle (or perhaps not so subtle) cues from a girl. Yet we had nerdy discussions, and we danced, and for that I was happy.

    As I walked off the dance floor and left the club with Hannah, everything slowed down, became heavier, and the evening's energy evaporated. We caught a cab, the framerate dropped to about 5-10 frames per second. Somehow I made it up stairs and under the covers on an air mattress and promptly fell asleep.

  47. Happy 8-Bit Day!

    on

    Today is the 256th day of the year. If you start the year with day 0, today is # 255 = FF hex = 11111111 binary = the highest unsigned integer you can represent in 8 bits = #8bitday.

    I tweeted this last year (created a wiki page), and then discovered Programmer's Day on Wikipedia (I think someone on Twitter pointed it out). Apparently it's an official professional holiday in Russia!

    While I certainly appreciate the recognition (being a programmer myself, and having thought in 8 bits for far too many years), I prefer a broader appeal - hence, "8 Bit Day" in recognition of 8 bit art & culture in general, which anyone can appreciate.

    Scott Pilgrim vs. The World movie cover

    This year the most prominently public celebration of 8 bit culture is no doubt the movie Scott Pilgrim vs. The World (and the graphic novels) which was packed full of 8-bit (and some 16 bit) video game references.

    8-Bit Halo stylized logo graphic

    If you're an 8-bit fan and a Halo fan, you might also enjoy the 8-bit Halo machinima videos on YouTube.

    Finally, if you like 8-bit music, AKA "chiptunes", check out:

    Enjoy 8 bit day. If you have one, dig out your old Atari 2600 (or pick up a new Atari Flashback 2 Plug and Play), and play some classic Combat.

  48. Oslo Addendum: Norwegian Web Interviews

    on

    Almost forgot - during the last day of meetings, Håkon introduced a few of us to some Norwegian press who wanted to interview CSS working group members. I spoke with digi.no (@digi_no) and Computerworld Norway. They both wanted to know about the past, present, and future of web standards and innovation. Innovation in standards has been accelerating the past few years, to the point where even web developers can be surprised, like the recent confusion and fuzziness over what is HTML5.

    Photograph of a whiteboard with an architectural diagram for Open Web Apps, including in the middle HTML5 surrounded by microformats, CSS3, Javascript, Device, Web Storage, Web Workers, Geo API. Also mentioned are ActivityStreams and PubsubHubBub (PuSH). Standing next to the whiteboard is Tantek Çelik, wearing a microformats tshirt under a black jacket.

    The first interview was by Harald Brombach of digi.no: "Legger grunnlaget for vakrere webapps". It's in Norwegian (as you might guess from the title), so here's an English translation via Google Translate: "Paves the way for more beautiful webapps".

    It's impressive how much the quotes survived the round-trip human-computer translation (me speaking English, Harald translating into Norwegian, and Google translating back).

    Photograph of Chris Lilley and Tantek Çelik sitting on a couch behind a coffee table with a laptop in front of Tantek and a hallway stretching backwards behind them in the Opera offices.

    The second interview I did together with Chris Lilley of W3C which was quite fun - it takes some of the pressure off to be interviewed as a pair. What was particularly fun was contrasting our different backgrounds and experiences, Chris at W3C and myself as a developer at Microsoft, Technorati, and as an independent standars advocate. In Norwegian: "HTML5 er sikrere enn Flash", and again, the Google translation: "HTML5 is more secure than Flash."

    I was particularly pleased that Computerworld Norway picked up on the "Open Web Apps" terminology. If the press can get behind a term, especially across languages, perhaps it's something we can get behind to better explain the difference between what is actually HTML5, and the broader open web applications platform that HTML5 is a core component of.

  49. Deconstructing and Reconstructing part 1: Oslo

    on

    Transatlantic flights force an ever rarer disconnect from the digital collective. Even the strongest of focusers can make use of the resultant executive function surplus; the rest of us, even more so. However, this British Airways flight has Iron Man 2 (on demand), which I haven't seen. Let's how that works as background.

    It's been an amazing 20 days. new CSS, boots, London adventures (and mis), the best dConstruct ever, closing with a beautiful week of holiday (mostly) in Brighton, and the first @MozPub.

    I'm looking forward to returning home, seeing those important to me, making necessary changes with renewed energy, and being inspired to create, once again.

    This all started nearly three weeks ago.

    Acclimation

    Despite a badly delayed SFO departure, thanks to Heathrow's amazingly efficient new Terminal 5 (and having carried-on all luggage), I made my connection to Oslo, and a swift train straight into downtown.

    My colleague and fellow CSS Working Group compatriot of many years Daniel met me at the train station. We had dinner and shared our recent trials and tribulations, both professional and personal. Short relationships that were never meant to be, and longer ones, doomed from expectations of entitlements. If your loved one makes you cry, stand-up for yourself and walk away (same thing is true for a job, though you may have more recourse there). Respect starts with self-respect. If they demand ever more entitlements, or act more like a spoiled brat than a courageous partner, leave them. Let them grow-up on their own time, if they ever do.

    CSS Working Group

    Heads and hearts just a bit clearer, we jumped into three solid days of W3C CSS Working Group meetings. The meetings were hosted by Opera Software thanks to Håkon Wium Lie. Our work didn't stop there. Dinners and discussions carried late into the night, thanks to the shared apartment that Tab Atkins rented out for us for a week. All the minutes (day 1, 2, 3) and raw IRC logs (day 1, 2, 3) are publicly available, posted promptly on @CSSWG. A few of the accomplishments that I'm particularly happy with:

    • Better W3C editor source control set-up instructions. Thanks to Elika and David Baron putting up with my bitching about CVS long enough to help walk me through getting it working, I wrote up a much more detailed W3C CVS setup, detailing every dumb idiotic problem I ran into no matter how small, and what the fix was. I give you: W3C CVS For Dummies to enable more CSS working group members and invited experts to directly edit developer drafts and advance more CSS3 more quickly. It's on the CSS Working Group wiki and thus my hope is that others will add more tips and notes where they got stuck and how they got unstuck.
    • All CSS 2.1 issues resolved (again) - the working group has worked very hard over the years sweating insane levels of details. Often in response to public feedback, but more often as a result of browser vendors iteratively implementing CSS 2.1 more and more precisely, and as a result uncovering holes and ambiguities that might affect only the rarest of pages. To be clear, the latest in progress draft of CSS 2.1 is far more accurate than any previous CSS Recommendation (1 or 2).
    • CSS Style Attribute editor's draft - this is a draft I helped edit many years ago, and is one of those critical pieces of documentation that connects HTML and CSS. The group has updated this draft to reflect how browsers work, and nothing more, i.e. what you can depend on. Expect a Candidate Recommendation soon.
    • CSS3 Color editor's draft - having finally gotten W3C CVS working, I've begun putting the finishing touches on the CSS3 Color Module. Thanks to David Baron's previous edits, and Chris Lilley's handling of last call comments and the resultant disposition, we're pretty close on this one. Just the remaining details that only someone with OCD could enjoy cleaning up. Well, maybe mostly enjoy.
    • CSS3 User Interface Editor's Draft - Having submitted a slew of technical fixes for HTML5, after minor CSS3 Color edits, this is now the key W3C draft I'm focusing on as part of my work at Mozilla. Just one problem: when the CSS working group last rechartered they left out working on UI. So for now, all work CSS3 UI will have to be in the form of a live, unofficial editor's draft that reflects the best we know of current implementations. Again, a very pragmatic draft. Once that looks reasonably solid (even as an editor's draft, I'll start drafting a CSS4 UI with next generation Web Apps UI features.

    Not everything went perfectly though. On the last day of the working group meeting, the USB memory stick I'd been using for recent documents (even for my CVS checkout) went bad. I was able to recover some text file fragments, and had recent (days/weeks old) backups, so the loss wasn't too bad, but still disappointing.

    Oslo Day Out

    Turns out if you sleep only 3-4 hours a night for 3-4 nights in a row, you will crash and sleep right through your alarm clock. No matter, I had planned an extra day in Oslo to walk around downtown and do some shopping. I awoke to the sound of Tab Atkins knocking on the apartment door. He barely missed his flight, they rescheduled him for the next day, so he came back the apartment. Good thing I overslept - no one else was around to let him in.

    We went out for coffee, a late brunch, and some shopping. After picking up a few essential items of black clothing at H&M (same prices as in the U.S.), and finding nothing good on sale at G-Star, I checked out a few shoe stores for boots.

    New Boots

    Ladies, this is an area where you're at a significant advantage - there are way more kick-ass women's boots than men's boots. For some reason boot-makers think guys want either douchey low cut dress boots, or overweight cumbersome boots with cheesy buckles / decorations or impractical laces. Or cowboy boots, which are just not my thing.

    Frustrated, I finally asked one store if they knew of any place that sold decent at least calf-height boots for men, and they pointed me to a spot a couple blocks away. We got there minutes before closing time, descended into their basement, where the only people were a couple of bored salespeople.

    Even here though, Tab patiently listened to my rants about bad shoe design, all the things obviously wrong with all of their boots. About to give up and leave, I came across a pair of black calf-high boots hidden on the 2nd shelf of an intermediate (not wall) display. When I picked one up I nearly flung it into the air - it was about 1/4 to 1/3 the weight I'd expected it to be. Super-light.

    Simple solid black styling, nothing fancy. Goretex water proof. Super-grippy sole. I had to try them on. A pair of European size 41s fit my feet like gloves. They felt like the best hiking boots I'd ever worn, but better fitted, black, waterproof, and light as sneakers. Incredible. Something clicked and I remembered where I'd heard the brand before: Ecco, recommended to me by Phoebe the friendly boot salesgirl I'd met a month beforehand in Portland.

    A climber friend of mine had once tweeted about her tradition of buying a new pair of boots after a break-up, break-up boots as it were. Seemed like a good idea in theory, and as I walked out of the boot store wearing my new Eccos, I finally understood what she was talking about.

    Dinner and Departures

    We wrapped up the evening with a nice dinner at Håkon's place, took nearly the last tram home, and after a fruitless search for laundry detergent, called it a night. Packed early the next morning, David Baron, Tab, and I took the train to Oslo airport where we shared one last lunch together before we departed our separate ways. Philadelphia en route to California for them, while the agent at my gate called out: London - all rows boarding for London.