Fix link to EWMH spec

1 files changed, 1 insertions, 1 deletions

diff --git a/usingxcb.mdwn b/usingxcb.mdwn
index de08cc7..f44b485 100644
--- a/usingxcb.mdwn
+++ b/usingxcb.mdwn
@@ -2,7 +2,7 @@
 
 Now that we have this XCB library and it pretty much just works, what can we do with it? I'd like to make it easier to build new window managers. (For an example of a window manager, see fellow freedesktop.org project Waimea.) I've picked this goal partly because I want to see more experimentation in user-interface design through window managers, and partly because most of the needed pieces are more broadly applicable.
 
-To build a window manager, you need to be able to interact with all of the other X applications on the same display without stomping on shared resources, and while allowing the applications to inform you of how they wish to be treated (e.g., don't resize me, and here's my icon). We have [standards](http://freedesktop.org/wiki/Standards) specifying how to do that, with the [Extended Window Manager Hints](http://freedesktop.org/wiki/Standards_2fwm_2dspec) (EWMH) being the current state-of-the-art. It would be nice to encapsulate those standards into APIs for C apps. That's not just useful for window managers, however, as all the other applications have to implement these standards too.
+To build a window manager, you need to be able to interact with all of the other X applications on the same display without stomping on shared resources, and while allowing the applications to inform you of how they wish to be treated (e.g., don't resize me, and here's my icon). We have [standards](http://freedesktop.org/wiki/Standards) specifying how to do that, with the [Extended Window Manager Hints](http://standards.freedesktop.org/wm-spec/wm-spec-latest.html) (EWMH) being the current state-of-the-art. It would be nice to encapsulate those standards into APIs for C apps. That's not just useful for window managers, however, as all the other applications have to implement these standards too.
 
 EWMH and its elder sibling, ICCCM, depend on X events for certain communications between clients. Xlib's interface for handling events is low-level enough to be awkward; XCB's interface is a little more low-level than that. A layer on top of XCB that provides a convenient interface would be valuable, and since it's very hard to write a useful X app that doesn't recieve events, such a layer would be very broadly applicable.