- From: Doug Schepers <schepers@w3.org>
- Date: Thu, 20 Jan 2011 16:43:32 -0500
- To: Robin Berjon <robin@berjon.com>
- CC: "spec-prod@w3.org Prod" <spec-prod@w3.org>
Hi, Robin- Thanks for the update. I'm using v1 for the new Web Events drafts, but look forward to v2. May I suggest that you add top links for Editor's Draft and Public Comments, as well? Here's an example (though not using ReSpec): http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html Regards- -Doug Schepers W3C Team Contact, SVG, WebApps, and Web Events WGs Robin Berjon wrote (on 1/20/11 10:39 AM): > Hi all! > > I've been making quite a few changes to ReSpec v2 recently (as those > who get the commit emails will have noticed). The good news is that I > think we're close to a beta. The bad news is that if you had thrown > caution to the wind and were already using v2, these changes will > break your code (sorry, but alpha really means alpha). > > The first change concerns the plugin system, and a new feature called > profiles. ReSpec v2 is essentially a lot of little plugins that > process the document in order, each making its own small changes, > very much like a Unix shell with lots of pipes (which was indeed the > inspiration). Previously you had to list all the plugins you wanted > in order, but that was annoying since for a given document type (say, > a W3C specification) you pretty much always want the same. To extend > the metaphor, profiles are like shell scripts, they capture the list > and order of plugins to run. Right now there's just one — w3c-common > — but there are more on the way. > > That's not all profiles can do. They also alleviate the > loading-from-local-disk problem. As browser tighten up their > security, it becomes decreasingly possible to load resources from > file:. This is an annoyance because we don't want to force users to > have to set up a Web server — ReSpec should just be a vanilla HTML > document into which you add a script — but we wanted to be able to > have dependencies such as templates. Thanks to RequireJS, profiles > can be compiled, a process that not only makes everything neat and > small but also folds in resources in such a way as to make them > readily available. End users won't have to compile anything of > course, that's for ReSpec developers (it also makes it easier for us > to make "releases" so that all the documents in W3C that use ReSpec > don't break at once whenever someone commits something stupid, as is > currently the case with v1). > > The plugins that used external resources have been updated to make > use of this facility. The exception is core/data-include (since its > resources are dynamic). That means that it will probably only be > usable in limited circumstances or when developing from a web server. > That's probably okay though since I don't believe that it is used > much (I've never used it myself, Shane might have a different idea > though :). > > Note that this change means that v2 now works in Firefox, Opera, > Safari, and Chrome (I haven't tested IE yet because I'm too lazy to > watch Windows load in the VM, but I'll get around to it). > > Developers who don't want to waste their time compiling profiles > every time they make a change during development can use a trick > similar to the one in profiles/w3c-common-loader which loads the > compiled profile when your document is from file: and the individual > plugins and resources separately when in http:. Also, look at > build/build-w3c-common.sh for the command that's needed to build a > profile. > > Another breaking change is that I've reverted the configuration to > rely on a global object as in v1. It's simpler, and it works better > with profiles. The test document that shows how it works is in > test-spec/webidl.html. > > The way bibliographical references are done has changed as well. They > are now defined and loaded as RequireJS modules. This is cleaner, > simpler, and works a lot better than the previous approach. It also > opens the door to a more distributed way of handling references (for > details follow the hand-waving). We need to think more about that > though. > > Things to do before beta include: > > - a tiny amount of things to port from v1 (in case you haven't seen > Gregg ported WebIDL which was the big one) - at least some skeletal > documentation, I hope to get on to that next - more tests, even if > not complete - checking that it's not completely broken on IE > > Thoughts, feedback, etc. welcome! > --
Received on Thursday, 20 January 2011 21:43:34 UTC