<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en" xml:base="http://annevankesteren.nl/foo">
 <title>Anne’s Blog</title>
 <link rel="self" type="application/atom+xml" href="http://annevankesteren.nl/feeds/weblog"/>
 <link rel="alternate" type="text/html" href="http://annevankesteren.nl/"/>
 <author><name>Anne van Kesteren</name><uri>http://annevankesteren.nl/about</uri></author>
 <rights>Copyright © 2003-2013 Anne van Kesteren. All rights reserved.</rights>
 <updated>2013-05-23T06:27:41Z</updated>
 <id>tag:annevankesteren.nl,2003:/weblog</id>
 <entry>
  <title>Fetching URLs</title>
  <link rel="alternate" type="text/html" href="http://annevankesteren.nl/2013/05/fetching-urls"/>
  <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>There are a ton of features in the web platform that take a URL. (As the platform is build around URLs, that makes a ton of sense, too.) <code>XMLHttpRequest</code>, <code>&lt;img></code>, <code>background-image</code>, <code>&lt;script></code>, <code>@font-face</code>, … The semantics around obtaining a resource from such a URL however are not very well defined. Are redirects followed? What if the server uses HTTP authentication? What if the server returns 700 as status code for the resource? Does a <code>data</code> URL work? Does <code>about:blank</code> work? Is the request synchronous? What if I use a <code>skype</code> URL? Or <code>mailto</code>? Is CORS used? What value will the <code>Referer</code> header have? Can I read data from the resource returned (e.g. via the <code>canvas</code> element)? Can I display it?</p>
<p>For what seems rather trivial, is actually rather complicated.</p>
<p>At the moment Ian Hickson has defined some of this in the HTML Standard. In an algorithm named fetch. Then CORS came about (for sharing cross-origin resources) and the idea was that it would neatly layer on top, but it ended up rather intertwined. And now there is another layer controlling fetching, named CSP. To reduce some of this intertwinedness and simplify defining new features that take a URL, I wrote the <a href="http://fetch.spec.whatwg.org/">Fetch Standard</a>. It supersedes HTML fetch and CORS and should be quite a bit clearer about the actual model as well as fix a number of edge cases.</p>
<p>It is not entirely done, but it is at the point where review would be much appreciated.</p></div></content>
  <id>tag:annevankesteren.nl,2013-05-23:/062741/fetching-urls</id>
  <published>2013-05-23T06:27:41Z</published>
  <updated>2013-05-23T06:27:41Z</updated>
 </entry>
 <entry>
  <title>Making the web platform more suitable for “apps”</title>
  <link rel="alternate" type="text/html" href="http://annevankesteren.nl/2013/05/applifying"/>
  <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>At Mozilla we’re trying to bring the web platform closer to what is taken for granted in the “walled gardens” of our time (Apple’s App Store, Google Play, and friends). A big thing we need to solve is offline. As applications, sites should just work without network connectivity. Some variant of “<a href="https://github.com/slightlyoff/NavigationController/">NavigationController</a>” (the name is bad) will give us that, but we need to iterate on it more. And in particular we need to test it to make sure performance is adequate and the API simple enough.</p>
<p>We have an API for <a href="http://notifications.spec.whatwg.org/">end-user notifications</a>, but after the site is closed clicking the notification from the notification center will fail (what should happen?) and if there are multiple browsing contexts with the same site open there is also some ambiguity as to which should receive focus. The permission grant is per-origin, but a single origin can host multiple sites. Push notifications face similar issues. The site is not open, but a push notification for it comes in, where should it be delivered?</p>
<p>The idea we have been toying around with is a worker that could be fired up whenever there is some external event that cannot be directly managed by the site (e.g. when the site is not open). This idea is not new, Google <a href="http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Mar/0050.html" title="Persistent SharedWorkers">suggested it</a> long ago, but it did not take off. A change from their model would be to not make these workers persistent, but rather short-lived so they are not too wasteful. Part of the application logic would move to the server, and push notifications can be used to wake the worker (we have been using “event worker” as a name) to e.g. notify the user or synchronize state for when the user navigates to the relevant site next.</p></div></content>
  <id>tag:annevankesteren.nl,2013-05-13:/230434/applifying</id>
  <published>2013-05-13T23:04:34Z</published>
  <updated>2013-05-13T23:04:34Z</updated>
 </entry>
 <entry>
  <title>Opportunists versus collaborators</title>
  <link rel="alternate" type="text/html" href="http://annevankesteren.nl/2013/05/opportunists-vs-collaborators"/>
  <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><blockquote cite="http://wikileaks.org/Transcript-Meeting-Assange-Schmidt#2045"><p>Well it’s not possible to win this kind of thing. This is a continuous striving that people have done for a long time. Of course, there is many individual battles that we win, but it is the nature of human beings that human beings lie and cheat and deceive and organized groups of people who do not lie and cheat and deceive find each other and get together… and because they have that temperament, are more efficient. Because they are not lying and cheating and deceiving each other. And that is an old, a very old struggle between opportunists and collaborators. And so I don’t see that going away. I think we can make some significant advances and it is perhaps, it is the making of these advances and being involved in that struggle that is good for people. So the process is in part the end game. It’s not just to get somewhere in the end, rather this process of people feeling that it is worthwhile to be involved in that sort of struggle, is in fact worthwhile for people.</p></blockquote></div></content>
  <id>tag:annevankesteren.nl,2013-05-06:/170641/opportunists-vs-collaborators</id>
  <published>2013-05-06T17:06:41Z</published>
  <updated>2013-05-06T17:06:41Z</updated>
 </entry>
 <entry>
  <title>TAG F2F</title>
  <link rel="alternate" type="text/html" href="http://annevankesteren.nl/2013/03/tag-f2f"/>
  <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>The <a href="http://www.w3.org/2001/tag/2013/03/18-agenda.html" title="W3C TAG meeting 18-20 March 2013 in Cambridge, MA, USA">W3C TAG meeting I attended</a> in Boston went better than expected. I got to meet the rest of the group and we discussed a variety of interesting topics without ever getting too far into lalaland (although the Polyglot Markup discussion was pushing it). I did think it was a bit too formal, though fortunately Jeni and Tim supplied a healthy dose of comic relief.</p>
<p>I thought I would outline some of what we discussed here and quickly jot some thoughts down for further reflection later:</p>
<ul>
 <li><a href="http://www.w3.org/2001/tag/doc/mime-respect-20060412">Authoritative Metadata</a>: We know that the most popular user agents out there are not respecting this finding. We know that the HTML Standard is not respecting this finding. We know that developers do have not sufficient control over their server, even now (one of the issues with httprange-14, CORS, CSP, deploying new formats such as WebVTT). While authoritative metadata may be good in principle (and I think that in retrospect for <code>Content-Type</code> file signatures would have worked just as well with a safe fallback), it has not worked out in practice. We should at least indicate in the finding that what it requires is not what is practiced.</li>
 <li><a href="http://f.cl.ly/items/2L0a0B0R130G3u0k0b1y/Layering.pdf">Layering</a>: Yehuda and Alex outlined a vision for a more layered web platform. While the network stack has pretty good layering, it gets messier once you get to the bits that go over the wire, such as HTML and JavaScript. I think this one is pretty non-controversial, though it is a lot of work and we need to watch out along the way to not constrain new implementations architectures (insofar they are not already). If you are interested in this space look at where Web Components is heading.</li>
 <li>API Design: Both Alex and Yehuda are frustrated with W3C/WHATWG APIs. Part of this is due to IDL not encouraging the kind of APIs that are close to JavaScript, part of this is people from a non-JavaScript background exposing low-level functionality to the platform. I personally feel that we have been hearing this problem aired for a while, but it never goes much further than that. I tried to point out that people would be supportive of doing this better, but we are resource constrained and lack the advice. Yehuda and Alex will take this back to TC39 to see if they can bring something to the table.</li>
 <li>Capabilities: Over dinner we discussed URLs to a particular resource where the access rights to that resource were part of the URL itself by means of a token in the path and the various implications of using that over a more traditional access control list model. E.g. whether we should have an HTTP header that indicates part of the URL should be hidden just as we hide passwords today. Jeni is currently sole keeper of these notes, but they should be public soon. (This was part of a larger discussion on Web Intents, Web Activities, and <a href="https://unhosted.org/">unhosted.org</a>.)</li>
 <li>DRM: One contentious bit of standardizing DRM is that it standardizes the API to talk to the black box, but the black box is not standardized and will likely end up being highly proprietary. An argument in favor of standardizing DRM that has been made is that when we standardized the <code>video</code> element we also standardized the API and left the black box (the codec) as an open question for which we eventually found WebM as an acceptable solution. (Of course WebM is not universal so whether this is completely okay is to be seen still unfortunately.) As a corollary, standardizing the API for the DRM black box will bring more content out of plugins and may at some point lead to a standardized black box (presumably then a white box). A counter argument goes that while everyone would be happy with a open codec, not everyone would be with W3C-blessed DRM. And that even while you could envision an “open” black box, nobody would use it because it does not provide the protection deemed necessary.</li>
</ul>
<p>You can find the raw minutes here: <a href="http://www.w3.org/2013/03/18-tagmem-minutes.html">March 18</a>, <a href="http://www.w3.org/2013/03/19-tagmem-minutes.html">March 19</a>, and <a href="http://www.w3.org/2013/03/20-tagmem-minutes.html">March 20</a>. Time to get back to London.</p></div></content>
  <id>tag:annevankesteren.nl,2013-03-21:/202456/tag-f2f</id>
  <published>2013-03-21T20:24:56Z</published>
  <updated>2013-03-21T20:31:13Z</updated>
 </entry>
 <entry>
  <title>CC0</title>
  <link rel="alternate" type="text/html" href="http://annevankesteren.nl/2013/03/zero"/>
  <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p><a href="http://www.whatwg.org/specs/">Standards developed by the WHATWG</a> are licensed under <a href="http://creativecommons.org/publicdomain/zero/1.0/">CC0</a> (variant of Public Domain that works globally). The HTML Standard is licensed under <a href="http://opensource.org/licenses/MIT">MIT</a> for historical reasons. This is important for these reasons:</p>
<ul>
 <li>Standards should be reusable everywhere without there being a legal grey area. The IDL code will end up in software, examples and text will end up in articles and books, either literally or modified as required. This and all that which we cannot foresee must be possible without copyright getting in the way.</li>
 <li>If the person or entity maintaining the standard takes it in the wrong direction or ceased maintenance it is paramount for the community depending on the standard to work on an alternative without copyright getting in their way.</li>
</ul>
<p>The W3 Project at CERN had the <a href="http://www.w3.org/Policy.html">same policy as the WHATWG</a>: <q>The definition of protocols such as HTTP and data formats such as HTML are in the public domain and may be freely used by anyone. Tim BL</q> Nowadays the W3C employes a more restrictive <a href="http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231">W3C document license</a> that does not allow for derivative works and requires attribution.</p></div></content>
  <id>tag:annevankesteren.nl,2013-03-14:/111610/zero</id>
  <published>2013-03-14T11:16:10Z</published>
  <updated>2013-03-14T11:59:51Z</updated>
 </entry>
 <entry>
  <title>New bank</title>
  <link rel="alternate" type="text/html" href="http://annevankesteren.nl/2013/02/new-bank"/>
  <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Received an introductory email from my bank today. “Dear Customer,” it starts and it goes on to explain how online statements work. For instance, how can I be sure these emails are from my bank? “[W]e will always greet you personally using your name[.]”</p></div></content>
  <id>tag:annevankesteren.nl,2013-02-20:/110044/new-bank</id>
  <published>2013-02-20T11:00:44Z</published>
  <updated>2013-02-20T11:00:44Z</updated>
 </entry>
 <entry>
  <title>Mozillian</title>
  <link rel="alternate" type="text/html" href="http://annevankesteren.nl/2013/02/mozillian"/>
  <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>I have been quite busy preparing for this and all the while I felt uninspired as to how to write about it. And now I am here and the words still won’t come, though the place is awesome and full of excitement. I live in London now and Monday I start working at <a href="http://www.mozilla.org/">Mozilla</a>.</p></div></content>
  <id>tag:annevankesteren.nl,2013-02-02:/094811/mozillian</id>
  <published>2013-02-02T09:48:11Z</published>
  <updated>2013-02-02T09:48:11Z</updated>
 </entry>
 <entry>
  <title>Minimal setup</title>
  <link rel="alternate" type="text/html" href="http://annevankesteren.nl/2013/01/minimal-setup"/>
  <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>My MacBook Pro crashes every hour. Considering I did not need most of things that were on it anyway, I made a quick backup of the essentials, erased the hard drive, and started anew. That it crashed again while installing Mac OS X was not that promising and unfortunately a fresh install did nothing but remove the non-essentials from my system. So presumably it is a hardware failure of sorts.</p>
<p>Anyway, what does it take to make a commit again?</p>
<ol>
 <li>Install XCode and its Command Line Tools.</li>
 <li>Install TextWrangler and its Command-Line Tools (<code>edit</code> is so useful).</li>
 <li>Install html5lib, lxml, cssselect, and <a href="http://wiki.whatwg.org/wiki/Anolis">Anolis</a>.</li>
 <li>Install GitHub.</li>
</ol>
<p>Time well spent!</p>
<p>(Not sure why Apple and Bare Bones Software spell command-line tools differently.)</p></div></content>
  <id>tag:annevankesteren.nl,2013-01-14:/135238/minimal-setup</id>
  <published>2013-01-14T13:52:38Z</published>
  <updated>2013-01-14T13:52:38Z</updated>
 </entry>
 <entry>
  <title>NLnet</title>
  <link rel="alternate" type="text/html" href="http://annevankesteren.nl/2013/01/nlnet"/>
  <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Quite quickly after the summer vacation period I figured out I was not that passionate about building a new product. What I wanted to be working on was a much smaller territory: URLs. So I started writing the <a href="http://url.spec.whatwg.org/">URL Standard</a>. Some time in I learned about the <a href="http://nlnet.nl/">NLnet Foundation</a> and wondered whether they might be able to help me out in this endeavor, as being independent for a while felt nice. It would also ensure I could finish the first 80% of the URL Standard, leaving the remaining 80% (no typo) for when implementations start to align and feedback starts coming in, which for standards work about already implemented technology is usually much later (e.g. the HTML parser was first defined in 2006 and it took until 2012 for it to be mostly implemented across the board).</p>
<p>NLnet is one of the few organisations in the world that funds independent people who contribute to the internet. The projects they have funded range from software running on root servers of the internet to popular security browser plugins such as NoScript, from TOR Hidden Services to Unhosted, from real time kernel updates (KSplice) to finding the security holes in GSM telephony (and then rebuilding it with open source GSM/LTE). All open source and out in the open.</p>
<p>So I made a proposal to work on WHATWG standards budgeted for three months and after handing over a more <a href="/projects/whatwg/nlnet.txt">detailed proposal</a> it was accepted. Putting the work in the <a href="http://creativecommons.org/publicdomain/zero/1.0/">public domain</a> and in <a href="https://github.com/whatwg" title="whatwg on GitHub">repositories on GitHub</a> as I had been doing was encouraged. I can heartily recommend them either if you’re looking for an organisation to support this kind of work or if you’re looking to sponsor such an organisation.</p></div></content>
  <id>tag:annevankesteren.nl,2013-01-02:/183703/nlnet</id>
  <published>2013-01-02T18:37:03Z</published>
  <updated>2013-01-03T12:55:08Z</updated>
 </entry>
 <entry>
  <title>Countries in 2012</title>
  <link rel="alternate" type="text/html" href="http://annevankesteren.nl/2012/12/countries"/>
  <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>In rough chronological order (see also <a href="/2008/12/year-in-cities">2008</a>, <a href="/2009/12/year-in-places">2009</a>, <a href="/2010/12/visited">2010</a>, and <a href="/2011/12/visited-11">2011</a>), omitting any duplicates, and lacking in detail and praise:</p>
<ul>
 <li>Colombia; got my PADI Rescue Diver and did some hiking through the jungle.</li>
 <li>Czech Republic; <a href="/presentations/xmlprague.html">pitched XML5</a> one last time and had loads of fun with Robbert and Yolijn exploring Prague.</li>
 <li>Norway; awesome ski trip with work, also just work, and a <a href="/2012/07/leaving-opera" title="Leaving Opera">goodbye</a>. I still catch myself saying “we”, but meaning Opera.</li>
 <li>United States; interviewed twice this year in Mountain View (more about that later), went to a W3C WebApps and HTML meeting at Microsoft in Mountain View, and visited San Francisco during those trips whenever possible.</li>
 <li>United Kingdom; visited Peter and Stefanie once again!</li>
 <li>Portugal; visited Marcos and Barbara in Lisbon. Anna joined later for extensive port tasting in Porto. In can now tell a ruby from a tawny.</li>
 <li>Romania; went there with Peter, Koen, Bas, and Inge because we found some cheap tickets to Bucharest. Ended up sleeping on the beach one day and thanks to a nice fire and some homemade whisky I did not freeze (accommodation was unavailable). Went back later to see Rada again. Definitely good times all around.</li>
 <li>Spain; explored Madrid with my two brothers and said hi to Charles while I was there.</li>
 <li>Germany; went to my first Oktoberfest in Munich with some friends I met in Romania. Learned to pace the larger glasses the second day. Visited Hamburg and Bremen later as Remy was performing there.</li>
 <li>France; W3C had a big meetup going on in Lyon. Thanks to Mozilla and the W3C I got to go and ended up writing about <a href="/2012/11/copyright">copyright</a> and <a href="/2012/11/process">process</a>.</li>
</ul></div></content>
  <id>tag:annevankesteren.nl,2012-12-31:/145316/countries</id>
  <published>2012-12-31T14:53:16Z</published>
  <updated>2012-12-31T14:55:33Z</updated>
 </entry>
</feed>