Big mistake.

It’s now 1:35am, and I finally have my solution. The trick is to use the evdev X.org input driver, as for some reason the mouse driver can’t handle all of my buttons. I followed sections 1 and 2 of this howto for the general idea of setting up evdev.

The problem is, none of the howtos I dug up really worked. Things sort of worked, but there seemed to be confusion about the number of buttons (xmodmap reported 9, while xev dumped events from up to #12). Also, the tilt wheel mapping seemed to be reversed. At this point, I began to suspect something was going awry, so I started looking over /var/log/Xorg.0.log. Here’s what I found:

For some reason, X seemed to be adding a new <default mouse> InputDevice with the message “No default mouse found, adding one.” This mouse used the standard mouse input driver, and somehow was jumping in front of my configured mouse settings as the default mouse. Oddly, running xinput list showed that my properly configured evdev device was loaded perfectly (with 20 buttons!), but apparently wasn’t being used as the primary mouse.

I persisted twiddling with X config settings and checking the logs, but for some reason, this default mouse would always be created. At this point I started googling this strange “no default mouse found” message. The only apropos result, and my solution, was in this blog post. It seems that someone decided to write a failsafe hack in 7.2 where if no InputDevice using the mouse driver exists in xorg.conf, the server adds one.

As Zaitcev writes, as apparent from the code, this hack has one exception, in which if some InputDevice invokes the driver void, it assumes that the user (as the code states) “probably wants to run footless”, and no default mouse is instantiated. Thus, the solution:

Section "InputDevice"
Identifier    "Configured Mouse"
	Driver        "evdev"
	Option        "CorePointer"
	Option        "Device"        "/dev/input/event2"
EndSection

Section "InputDevice"
	Identifier  "IHATEKLUDGERS"
	Driver      "void"
EndSection

[...]

Section "ServerLayout"
	[...]
	InputDevice    "Configured Mouse"
	InputDevice    "IHATEKLUDGERS"
EndSection

Unbelievable.

Apparently, this will be fixed in 7.3.

Late friday afternoon I was checking on the rear tire. I’d pumped it up a few weeks ago, only to find the next day that it was flat. So I pumped it up to 55 psi — the normal pressure I keep it at — and waited. I figured there was a leak somewhere, and thought I could feel a small amount of air coming out around the valve. So I leaned close to the valve and listened. Stupid idea. After a second of listening and with no warning, the tire blew. PAFF! Right in my face. Thankfully all it did was leave my ears ringing for about a half hour, and things were fine…

However, the tire wasn’t. The inner tube had a nice patch of tears where it exploded. My father and I checked the tread for anything sharp that could have punctured the tube… nothing. So we figured that after three years of owning the bike and storing it, the tube had a defect and had worn out.

The next day, we went to GI Joe’s and and bought a new tube. The only ones they had with the right valve were these “SLiME” leak resistant inner tubes with a liquid sealant agent inside. After the experience I had with the last tube, it didn’t seem like a bad idea. So we brought the new tube and put it on, fit it back into the frame, and pumped it up to 50 psi.

Everything looked good, so I took it up a hill to see how it felt. I stopped at the top and checked the wheel. The frame was a bit out of alignment, and rubbing against the brake pads, so I started riding back home to give it a quick adjust. I was watching the speedometer hit 17mph as I rolled down, letting go of the brakes and seeing what it felt like to be going fast again. PAMMFF. Yes, the tire blew again right there at 17 mph on the road. Luckily stopping the bike was really mild, and I had really good control. However, this time, I stopped to find the entire of back of my bike splattered with green goo, dripping green onto the road.

It was beautiful. I truly wonder what someone would have thought, observing this explosion. It kind of adds to the humor that I believe the first thing I said was “not again.” Detached from it all, it was really quite funny, carrying my bike, with it’s trashed back wheel, dripping this ridiculous green liquid all over the place.

I got to spend that afternoon wiping plastic goop out of the frame, the gears, the chain, and everything else. Before cleaning we compared the old tire with this new one, and found that they both popped in the same place. However, another check of the frame and tread found no obvious sharp spots — though the inner belt between the spokes and the tube looked a little compressed and thin. Needless to say if there was a pointy spot before, there now are many more, as the wheel frame was what dissipated most of the force of my 17 mph up down the hill.

I think this is one of those cases where it’s a better idea to wait until I can have someone look at the wheel in a shop. At this point, the frame pretty is damaged and might need replacement anyway. Long story short, it doesn’t look like I’ll be riding so much this summer…

Yesterday I was treated to this lovely deviantART subscription nag screen, which would not retreat from the site until I clicked the little “no thanks” button at the bottom. How very lame. My feeling is, if I wanted to continue using their service I would care enough to notice and renew it. As it stands, their bargain price of 8 cents a day is about twice what I pay for hosting here at NFS. I’ve been on the fence for a while about leaving the website all together, and this is pretty much the end. If I were Fella, I’d be crying at how dissapointing his site has become.

Be it centering objects, making layouts use the maximum amount of space, or simply trying to use floats properly, I am always amazed by how seemingly obvious code does not work the way I should think it does. It seems rather silly to me that such a language would be designed such that web designers must resort to specialized recipes to deal with seemingly simple and common page layout designs. While powerful, CSS seems to become more and more a search for hacks and snippets to make many designs possible. Browser support is also an elusive and secretive gem; unless explicitly stated, what works in one browser will probably at some point fail mysteriously in another.

Tonight, my appreciation for the language fell to a new low. In the mid-day, thinking about my page layout, I decided that I wanted thumbnails posted from my gallery to be aligned to the right of the post, so that post text can wrap around them on the left. I figured this would be a relatively simple fix; I just needed to float the image class to the right and see what happened.

Well, not so fast. I had failed to remember that images when floated will (without a clear property set on a following element) essentially make the following layout flow through and under the image, leaving the image on top of the footer and the title of the following post. After a little searching and reading, I realized this mistake and added the appropriate clear: right; to the .post-footer class. The footer should now make appropriate space for the image in the post. Simple, right?

Again, not so fast. After putting in this little tweak, I found the first post on my page (without any image) being followed by a long swath of whitespace, assumedly caused somehow by my float: right‘d sidebar. Why was the browser making a whole bunch of space for something that wasn’t there? I may never know. Well, debugging this would prove to be a nightmare, so I soon got tired and decided I needed to do some research. I googled CSS float clearing techniques, searching for some trick to make space for the image without involving other floats. Well, I ended up finding this quirksmode.org article describing a trick for making float space work without needing the clear property.

Well, how about that? Reading it worked on most browsers, I quickly tried this new overflow: hidden trick on my .post-content div, and looked to see if it would work. Well, at first attempt, it didn’t. But it was close. This time, space was being made between posts for the image to fit in. However, the footer was still flowing through, underneath the image. This was relatively easy to fix, after I added back the clear: right; line to the footer div, this worked too. The blank space following the top post (which is why I seached for this trick in the first place) disappeared. At this point I really didn’t care why, and was glad that it did.

Then I noticed some mysterious padding being added under the titles of posts. This was directly associated with the existence of the overflow: hidden statement. About a line of space was being added under the titles for reasons unknown to me. I tried hard setting any margins and padding I could think of to 0 (most were already), yet still, this mysterious and unexpected space was being made. After fiddling with it for a while, disappointed that the trick might not work, I tried moving overflow: hidden to the parent div, .post. This worked like a charm. Everything was working as it should have been: space was being made for right-aligned images, text was flowing around them, and there was no longer any weird quirkiness being wreaked upon my page layout. Finally!

This experience I had tonight illustrates my primary frustration with CSS: it makes no sense for achieving simple design tasks. Certain assumptions about the purpose and performance of properties never seem to work out entirely as planned. My attempts at putting an image on the right required an understanding of the float layout system, the subtleties of clear usage, and even an arcane trick barely documented and not well-known – at least not very accessible to me.

Further, this impacts the sanity of CSS as a programming language: as a designer and a programmer, I expect that properties and directives will just work, in a way not so far off from the way they are documented to. In my experience with CSS, and in this example, the subtlety and lack of documentation in getting things to work as intended required so much more fiddling, guesswork, and raw googling than I ever expected to do. Also, pages become so big and complex that when dealing with many layout bugs, there is usually not an obivous quick fix.And I am simply using CSS like a programming language. I don’t even want to imagine the ways one would try to create a GUI for representing these difficulties in a WYSIWYG environment.

When attempting to represent a graphical layout using programming directives, I understand that it is very hard to craft a language that is both simple to use and powerful in it’s creative offerings. CSS really achieved a lot in terms of power in crafting web designs, and especially in controlling the typography used. However, the current state of utilizing CSS in web design is both an exercise in frustration and confusion, as the subtlety of the effects of CSS directives make it (at best) difficult to debug, and the arcaneness of the techniques used takes the considerable learning curve of CSS and shoots it through the roof.

After dealing with CSS a reasonable amount, I can only wonder at the hoops professional web designers must leap through in negotiating between the limitations of their environment and the needs/desires of their customers. As an open source and Linux enthusiast, I make minimum effort to accomodate poorly compliant browsers. I’d rather not think about the far more trouble one has to go to to ensure such compatibility. Heck, it would take so much time to really get fluid with the medium that suddenly, the role of the professional web designer makes so much more sense to me!