- From: Robin Berjon <robin@w3.org>
- Date: Fri, 18 Oct 2013 14:19:42 +0200
- To: "spec-prod@w3.org" <spec-prod@w3.org>
Hi all, if you're a ReSpec user, please pay attention to this message! I am about to release ReSpec 3.2, which is a fairly major change. I've run a fair number of tests (from the test suite and additional ones) and it appears to be behaving well, but you never know. I initially wanted to make an RC at a different URL, but the extent of the changes are such (notably the new UI stuff and how it is lazily loaded) that that's not easily possible. After the release I have a list of specs that I know to be using ReSpec that I will go through to triple check that all is fine. But just in case, I'd appreciate if you could check at your end too. At the first sign of trouble I'll back the changes out. Such major changes are rare (the last one was 3.0, 20 months ago). The next ones in the 3.2 series will be small and incremental as usual. Things that have changed: • The most user-visible change is that there is now a UI in the top right corner. It features a button that when pressed shows a drop-down menu of things that can be done. Right now that list is limited but the modules that implement the functionality in the drop-down are loaded lazily which means that we can add functionality there without worrying about code size (notably linting). Next to the ReSpec button are two pills that appear when there are errors (red) or warnings (orange). Clicking them opens the list of issues that ReSpec has noticed while running. Error detection has been improved a lot in conjunction with this. This ought to help with the many cases of "it isn't working" bug reports when the error messages used to be in the JS console. In addition to saving, which is still accessible as Ctrl-Alt-Shift-S, errors can be opened as Ctrl-Alt-Shift-E and warnings as Ctrl-Alt-Shift-W. Overall the UI can be made prettier — input welcome. I also suspect that it may have some A11Y issues which I want to iron out ASAP. • If the browser supports it, the saving dialog now uses the download attribute on <a> to trigger a real download of the generated output, as "Overview.html". For browsers that don't support that yet, you can nevertheless right click the button and save link as. In both cases this is faster than the previous methods. • Code size is down another 10K, now at 44% of the original. • The legacy module has been completely removed (work that started with 3.0). All of the useful functionality in it is now available in proper new generation modules, most notably a new core/biblio module. • We no longer need to do weird things with JSON-P and <script> elements, all is loaded cleanly as JSON. In theory this means that we should be able to make the biblio parts fully asynchronous (which could have a very positive impact on perceived performance). • The functions that generate snapshots are now exposed on core/utils and can be called at will. • simple-node, a small library I wrote from the days before jQuery, has been almost eliminated. It is now only used by core/webidl-oldschool. I also removed everything from it that wasn't needed for that (e.g. namespace support). • Note that several of the above changes combined completely eliminate the "berjon" (JS) namespace that used to exist. If you have some really dirty hacks that tap straight into the internals that's the first error you're likely to get. • We've upgraded to the latest RequireJS (notably for building). More notable, we now use jQuery 2.0. That drops support for some of the older IEs; I don't think it'll be an issue for this usage. • Testing has been made more correct in several cases. Share and enjoy! -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Friday, 18 October 2013 12:19:51 UTC