Linkstew

Sending XHTML as text/html Considered Harmful - Huh. Point taken. (Update: Wow, this page is really broken in Safari.)

After spending the last week working on JavaScript craziness at work, I felt inspired to come home and do something on my own site with it. Now don't get me wrong: I still generally dislike the way JavaScript is used on your average site, but I'm beginning to respect that it's capable of adding useful interactive elements to a site while keeping the site entirely accessible for someone who has JavaScript disabled.

So for my first trick, I turned the "8 years of Linkstew" list into a much smaller widget which only displays one year upon loading, and then allows you to view other years as necessary. And if you have JavaScript disabled, you see all of the years expanded out without a problem, because it's the JavaScript that collapses the tables on load in the first place.

Before you oh and ah too much, I should qualify that this functionality was based on a heavily modified version of PPK's Quirksmode site navigation widget.

I wasn't entirely sure of what the best navigation paradigm was, so I made some toggles for you to play with the options. I think I like the "click to select" + "one year selected at a time," but if you have a strong alternate opinion, please let me know:

• Set hover select.
• Set click to select.
• Enable multi year select.
• Disable multi year select

That said, there are also still some known issues to work out:

• A lot of the particulars are hard coded right now. I plan to make it a little more generalized so I can reuse the functionality on other parts of the site. So if you're thinking to yourself "hey, that's cool, I want that!" I'd recommend not stealing it yet.
• It's ugly! I'm still working on the styling, but that's probably going to end up being a part of a bigger project to restyle the whole site.
• In Mozilla (but not Firefox!) each month link is taking up the entire width of the widget, so it makes a straight vertical list of months instead of a 3 x 4 grid. It definitely has something to do with display: block, but that it does the right thing in FireFox really confuses me.
• In IE Mac, the JavaScript fires and collapses the tables, but the CSS stuff doesn't happen right at all, so it looks really weird. I probably need to hide the JavaScript activation from that browser.
• Maybe I'm crazy, but Mar, May and Jun 2004 seem to have a light gray background, but that doesn't render in any other browser and Mozilla's DOM inspector isn't telling me anything different for those cells than Jan, Feb and Apr.
• I haven't actually tested it in Win IE yet, because I don't have it on hand. If there are any problems, let me know?
• Opera 7.5 works fine for once.

So go use it and let me know what you think! Gratuitous? Useful way to save space? Fun to play with it?

Quirksmode.org

This site has been indispensable in the heavy JavaScript work I've sadly found myself doing in the last week. I can't recommend it highly enough.

I spent most of my weekend working on Stew's Poos, a website I made for my mom for Mother's Day about her Cockapoos. They're awfully cute dogs (a cross between cocker spaniels and poodles), and they're adorably cuddly.

Most of the time was spent coming up with a useful extensible css based layout, but I'm pretty happy with the resulting html. It's apparently even xhtml 1.1 compliant, even though I was only shooting for xhtml 1.0 trans. There's still at least one more page to make, and there are some small adjustments I still need to make, but I'm pretty happy with its current state.

Today was a long hot day of trying to work around HTML's shortcomings using JavaScript, only to end up hating JavaScript even more and fixating on how useless HTML's form tag is.

"The form tag!?" you might ask.

Granted, there's an awful lot wrong with HTML, but as a web developer, the form tag (and the input tag) are the only things I really care about at the end of the day -- and unfortunately, the form tag sucks.

So, if I could change one thing about HTML, I'd move the "action" attribute from being an attribute of the form tag to being an attribute of a submit input tag. Then, it wouldn't matter that HTML can't deal with nested form tags, because I could just submit to different actions depending on which button was pressed.

I finished the conversion of Linkstew to use all CSS tonight. With no more ugly tables to worry about, the code is significantly cleaner, it'll be easier to make changes in the future, and hey, it even still validates!

It looks good to go in Safari and Mozilla and IE 5, but there's something kinda weird going on with OmniWeb... But I'm not sure if I'm going to worry about it, because OmniWeb has other problems. Anyway, if you see any problems in any other browsers, let me know?

And now, I feel safe adding another bullet point to my resume.

Next up: convert my resume to LaTeX, to refresh my LaTeX skills so I can feel justified in adding that to my resume.

My original intentions tonight had been to play with my RSS feed. Instead, I got distracted by playing with CSS for parts of my page layout and I never even actually touched the RSS files.

So, I moved a few things around, and the entire header and center column of posts is now completely laid out using CSS and is table free. It even validates as XHTML 1.0 Transitional right now...

I've only really tested it in Safari and Mozilla, but that means that there's at least one browser on every platform that it'll look acceptable in... Regardless, since I'm leaning towards rebuilding everything with CSS, let me know if you have other layout suggestions for me to play with while I'm at it.

Still todo:

• Make the sidebars layout using all CSS, and get rid of tables completely (probably with the exception of the calendar tables).
• Make my posting engine smartly handle ampersands, escaping them into html entities if I enter any unescaped &s.
• Clean up my rendering code once the all CSS version is in place.
• Actually play with the RSS feeds.
• And then I can start adding some features that I've been meaning to add.

I've been using OmniWeb daily for as long as I've been using Mac OS X. Now, I'll be the first to admit that OmniWeb just can't render some pages, and that its CSS support sucks, and more. In fact, I've got a huge list of complaints about OmniWeb. I have so many problems with it, in fact, that I'm unwilling to register it until some of the problems get fixed. And remember, I like to pay for reasonably priced software (which I consider OmniWeb to be), so that I'm stubbornly refusing to register it after a year should tell you something.

So that raises the question: Why on earth are you using it if you have so many problems with it that you won't even register it? And I've got four reasons for you:

1. Integrated OS X spell checking. By using system text widgets, text fields in OmniWeb are hooked into the system-wide spell checking library, so the library of custom spellings that I've added all over the place is accessible when I'm writing comments (for example) in OmniWeb.
2. Emacs based Control keys. Again, by using system text widgets, emacs based keyboard shortcuts like control-a for beginning of line, control-e for end of line, control-n for next line, control-p for previous line, control-k for cut line, and control-y for yank cut buffer all "just work." I use emacs for 100% of my programming, so these keyboard shortcuts are pretty well ingrained in my head, so the ability to just use them makes me happy. When I try to write text in IE, I go insane without these shortcuts.
3. Open Link Behind This Window In IE, you can command click on a link to open that link in a new window, or control-click the link and select "Open Link in New Window." This is useful. In OmniWeb, I can configure the behavior of command click, so that when I command click a link, it opens that link behind this window. And of course, the context menu offers both options. With this feature, I just command click links I want to read when I come across them, and when I finish reading the current page, I close the window and read what's in the next window. (And if the next window isn't what I want, Command-~ to cycle through the open OmniWeb windows quickly comes to my rescue.)
4. The text is anti-aliased Finally, all of the text OmniWeb displays is anti-aliased, as opposed to the horribly jaggy text displayed by IE.

So, that's all it takes to get me to use OmniWeb. Basically, I take my text editing very seriously, and if you toss in a few other niceties, I can't refuse, no matter how badly it mangles lots of html. And I'd be lying if I didn't admit that I keep IE right next to OmniWeb on my dock.

I really don't like html. There are a lot of things not to like, but the thing that most frequently drives me up a wall is trying to have multiple submit buttons for a single form that do different things. Because a form action is associated with the FORM tag, and not a SUBMIT input, you can't have one form that submits to two different scripts. Having two forms isn't really an option, because then you'd have to have a ton of redundant information on the page. So what you end up having to do is check the value of the submit variable that comes into your cgi, and dispatch based on that. This works, but I hate it, because it makes for big messy if blocks. Also, it becomes a maintenance issue, because you have to make sure the name is the same in both the html printer and in the if cases, so then you have to go define a bunch of constants for your submit names, and it's all just very ridiculous.

Basically, I wish the form action were associated with the SUBMIT instead of with the FORM.

But while I was lying around delirious last night, it occurred to me that you could probably use a javascript onClick to dynamically alter the action of the form. I'm not sure that that works...

But then I realized that the potential "solution" was worse than the problem, and put it out of my mind. For that matter, I realized that I didn't actually want to know if it would work, because if it did work it would only make me dislike html even more.

This all started because I was getting violently sick of my old background color (#ffffcc, for those of you playing along at home), and I figured I could change it to white (#ffffff =p) without disrupting things too much.

But when I made the background white, everything started to blur together, because the backgrounds on my posts were white to contrast against the formerly creamy color of the page... So I decided I needed a vertical stripe to separate the posts from the sidebar.

Now, I've always been a big fan of vertical stripes, but with html it's easier said than done. So I grabbed the first site I could think of with a vertical stripe (which happened to have been AJ's) and pulled the code and images straight from there, which explains the dotted line as opposed to a solid line.

But then I felt off balance, and I've been toying with the idea of adding another column for a long time anyway (because that damn date navigation is *really* long), so I added it, and now the whole thing is nice and symmetrical, and for the moment, I like it.

I actually really like the dotted lines, and assuming AJ doesn't object, I'm going to leave them there for now. However, I'm also thinking about changing the green soon, because I don't even know how old that color is or why I have that green.

Later: So I decided that with the symmetry the lines provided, I wanted the green bars to come closer to being evenly spaced on each side, which meant I had to alter the comment links some. And that got into issues of having the colored dot load on a background the future color of which I'm not certain...

So I just made the comment widget text yellow and extended the green background, but changed the permalink/recency indicator to be a colored arrow at the beginning of the text. I like the way it looks, but I'm not entirely happy with the implementation at the moment. First of all, I was having some CSS issues so I had to give up and wrap the arrows in colored font tags. And the second problem is that posts that don't start with a <P> tag at the beginning (Of which there are 58, according to a quick check via SQL) won't get arrows put in correctly. But aside from those implementational issues, and the still standing puke green issue, I like it.

Oh, I also made the title bar truncate seconds from the post date, since they're useless. Hopefully the dates will be a little easier to read now that there are two fewer numbers there in that bar.

I was thinking about using XML and XSL to abstract content from layout tonight, and in particular how I could apply it to linkstew. The model I've been using at work is to have the code generate XML which XSL transforms at run time. From what I've seen, this is also the model which everyone else uses for XSL, which is probably where I got the idea in the first place.

But tonight in the shower, I said "Wait a second! Why not have XSL and XML tagged PHP produce the code to run and generate my page?" In other words, instead of transforming XML with XSL every time, why not transform some carefully marked up php once to generate a script which will produce the layed out page. To change my layout, I just change the xsl and rerun the script...

• Current method: Script -> XML + XSL -> HTML Output
• New Idea: XMLized PHP + XSL -> Script -> HTML Output

I'm still fuzzy on exactly how this is going to work, but it's a new twist which I really want to explore. As the idea bounces around more, I'll let y'all know if this actually seems feasible...

When I make a page, I always leave my links and visited links the default colors. Classic Netscape Blue and Purple. I don't change those, because familiarity allows a user to quickly see what they have and have not visited, without having to figure out that I used, say, black for everything so that my links just look like underlined text. I also never manually turn off underlining for the same reason. If the user wants to, of course, they can override any of these things in their browser, but what I give them by default is guarenteed to be familiar to them.

One little personalization I used to make amidst my boring style was to change the active link color be the color of the background, so that when a link was clicked on (and held down), the link would disappear. Then, one day, I got an email telling me it was confusing because he couldn't read the links that way. "Huh?" I thought. "Why the hell are you clicking on the links before you've read them?" But I figured that if it bothered one person, it probably bothered many, and I returned the active link to it's default color, too. So much for a cry of individuality amidst my conformity.

I normally use Netscape 4.7 or so, and that browser doesn't support all the fancy "hover" css specifications, so I've never really thought much about them or used them. Lately, however, I've been using browsers (Mac IE 5 and Mozilla 0.8) which support a lot more css than I'm used to, and I've noticed just how prevalant the use of the hover attribute really is. Now, if a link italicized when I held my mouse over it, that'd be fine. If it bolds, that's fine. In general, if it becomes more readable and emphasized in a way that's distinguishable from an active link, that's fine. However, tonight I stumbled across a site which turned links I was hovering over the color the background, making them invisible when I was hovering over them. Yes, much like I used to make my active links invisible, only this was much worse, because things disappeared when I was just moving my mouse around, as opposed to a visable reaction to some action I took. And then, when I clicked on a link, it didn't have a different active state than hover state -- that page had an active link whose appearance was the same as the hover link. Bad bad bad.

The moral? Use standard link colors. If you have to use hover, make sure that the hovering makes the text more readable and isn't the same as the active link style or the visited link style. And if you're going to play with the active link, do whatever you want to it so long as you don't make it disappear (because apparently that bothers people) or make it look unchanged (because that makes people think their browser has stopped responding).