The change to the URL Standard to use Unicode IDNA Compatibility Processing was made a while back. The reasoning is that it provides an interface compatible with IDNA2003, including almost identical processing, but is based on the IDNA2008 dataset. That means that lowercasing still happens. Mapping code points still happens. URLs will remain cool. The URL Standard has the integration details.
Objects live in Vats. Realms are a legacy accident due to poor browser engineering and do not control the object addressing space. Vats can only communicate through message passing. Messages clone objects, sometimes transfering their underlying data. Ever-so-slowly ECMAScript is growing more powerful to describe the web platform. This kind of modeling is what excites me these days.
Thanks to Allen Wirfs-Brock for correcting my errors in writing this and providing these cool analogies:
A Vat is an address space for objects. An object within a Vat can only reference ("point to") other objects in the same Vat. Realms are just a decoration on some object. Their Realm associations (if any) don’t impact the ability of objects within a Vat to reference each other.
Vat’s are like isolated continents. In theory you can walk from any point to any other point on a continent, but you can’t walk to any other continent. A Realm is like a country with national boundary. Those boundaries don’t actually change the theoretical ability to walk between any two continental points, but parties might use those boundaries as part of a scheme to artificially restrict movement.
(Mark Miller did this long ago in E and the web has a somewhat sloppier version of it, through workers, structured cloning, and having multiple globals, but on the upside is deployed widely.)
I was asked how one contributes to standards. Before anything else, it is worth watching Domenic Denicola’s presentation on making friends and influencing standards bodies. It is awesome and will teach you a great deal.
I think the core thing to understand when considering contributing to web standards is that they are created by communities. Typically there are a few people leading the charge and many people contributing with critique, research, and tests. Usually there is a combination of mailing lists, IRC, and the occasional face-to-face meeting, to keep everyone roughly synchronized.
You want to figure out what community to participate in:
Unfortunately there’s a myriad of other smaller lists for particular APIs. Usually the standard you care about has relevant pointers. If it doesn’t, please file a bug or let someone else know as it definitely should.
Studying the output of the community (the standard and tests) and its ongoing progress (the mailing list) is a good way to get a feel for how things work and what you should pay attention to. It can help to read the WHATWG FAQ too as it documents answers to many common questions. Having familiarized yourself with the material and the environment you should feel more than ready to start participating more actively, in particularly if you see something worthy of improvement.
There appears to be trend where specifications monkey patch a base specification. A monkey patch being a subtle change to an existing algorithm only observable if you have seen both the new and the base specification. Some examples: Custom Elements attempts to redefine the
eval(). (Using dated TR/ URLs here as an exception so these examples remain useful going forward.)
Apparently it is not clear that this is bad design. We should avoid monkey patching (hereafter patching). It has at least these problems:
img element definition it would not be clear for someone reading the adopting algorithm that adopting is actually more involved.
If you encounter patching, please file a bug. If you are writing a specification and temporarily want to patch a base specification to help implementations along, file a bug on the base specification so the community is informed of what you are trying to do.
I love figuring out the web platform and making it better.
I moved to the United Kingdom to work for Mozilla last year and it has been excellent so far. Getting close to a full year now. Since I have listed countries in 2008, 2009, 2010, 2011, and 2012, I thought I would do it again:
To be clear, the fundamental aspects of promises remain unchanged. And we should continue using them for all new features that require asynchronous values.
IDNA2003 consists of two important algorithms: ToASCII and ToUnicode. Both operate on a single domain label (i.e. not a whole domain name). To obtain one or more domain labels from a domain name it needs to be split on dots (U+002E, U+3002, U+FF0E, and U+FF61).
Apart from doing a range check and checks for certain code points, ToASCII encompasses two major algorithms: Nameprep and Punycode (see Wikipedia’s Punycode). Nameprep is a specific profile of Stringprep. Stringprep in turn, does a number of things: mapping code points, Unicode normalization (NFKC — “Die, heretic scum!”), check forbidden code points, check proper use of bidirectional code points, and check unassigned code points (although this last one will not happen in browsers).
ToUnicode does the reverse, with the caveat that it cannot fail. If it fails at any point the original input is returned instead.
The URL Standard standardizes on IDNA2003 as that is what the most widely deployed clients implement. It does override one requirement, namely to use the latest version of Unicode rather than Unicode 3.2.
The IDNA section of the URL Standard references IDNA2003’s ToASCII and ToUnicode and makes appropriate requirements around them. The status quo now has better documentation than before. It seems unlikely clients will update to IDNA2008 as it’s not a straightforward replacement (it has nothing equivalent to ToASCII and ToUnicode) and is not backwards compatible.
Last week was the second reformed TAG meeting, this time with new chairs, and hosted by me at Mozilla in London. I felt that overall it went well, though there was quite a bit of repetition too. Getting a shared understanding takes more time than desired. Takeaways:
provider.comwith WebRTC or will it need a dedicated API for the next twenty years?
Also, the W3C TAG is now on GitHub. It took some arguing internally, but this will make us more approachable to the community. We also plan to have a developer meetup of sorts around our meetings (a little more structured than the first one in London) to talk these things through in person. Feel free to drop me a line if something is unclear.