O Sweet Mr Math

wherein is detailed Matt's experiences as he tries to figure out what to do with his life. Right now, that means lots of thinking about math.

Friday, January 31, 2003

1:08 PM

Daily blog layout update: Despite my assertion that layout problems in other browsers were not my responsibility, I went ahead and cleaned them all up anyway. I fixed the positioning of the right corners in IE and Opera by explicitly setting the margins to 0 and the positioning of the left corners in IE by setting the vertical-align to bottom. Mozilla required changing my HTML. The corners were being positioned like this:

<img src="leftcorner.gif" alt="">
<img src="rightcorner.gif" alt="" style="float: right">

According to the CSS layout rules, two images should appear next to each other if the block they are in is wide enough for them both to fit. So leftcorner.gif should appear at the left end of the line and rightcorner.gif should appear at the right end of the line. Mozilla insists on moving rightcorner.gif down so that it does not appear next to leftcorner.gif, despite the fact that there is plenty of space. I reversed the order that the images were listed in, like this:

<img src="rightcorner.gif" alt="" style="float: right">
<img src="leftcorner.gif" alt="">

My reading of the spec, and that of all the other browser developers, is that the two pieces of code should be laid out the same way, and I find it more intuitive to list the images in the order in which they appear, but I have rewritten it for the sake of browser interoperability.

I seem to be getting continuing but inconsistent layout problems with the corners in Mozilla, but since they're inconsistent, I'm having trouble working on them. IE is doing something weird with the layout of the three columns, but that's IE's problem.

Back in Safari, I found what appears to be a problem with a rounding error. The horizontal gap between the three columns is explicitly set to be 10 pixels, but I found that I was getting 12 on the right side. I think this has to do with the fact that the block as a whole is set to be 80% of the window width and then the central column is 60% of the block. After the pair of multiplications, the column ends up too narrow, but Safari wants to keep the overall block width correct and expands the gap. I found that the size of the gap depends on the window size, which supports my thinking. I added a fudge factor to the margin on the center block so it now appears correctly on the default window size on my desktop machine.

I spent way too much time yesterday correcting the vertical spacing of the center column of the blog. I knew that vertical margins "collapse". This means that with a layout like

<p style="margin: 10px">Content 1</p>
<p style="margin: 10px">Content 2</p>

the vertical space between the two paragraphs is the maximum of the two margins, or 10 pixels, instead of 20 pixels which you get by summing the two margins. What I didn't realize is that this holds true for elements inside each other.

<div style="margin: 10px">
  <p style="margin: 10px">Content</p>
</div>

results in a space of 10 pixels between the previous element and the paragraph. However, if anything else, such as padding or borders, separates the two margins, they do not collapse. Adding 1 pixel of padding results in a gap of 21 pixels, like this:

<div style="margin: 10px; padding: 1px">
  <p style="margin: 10px">Content</p>
</div>

To simplify my layout calculations, I set the padding to zero where I could, and I thought I understood which margins would collapse and which would not. When I tested it out, I was quite surprised that everything ended up too close together, and I eventually figured out that I needed to use non-zero paddings. This was quite frustrating and not how I read the CSS spec, but I eventually remembered a diagram demonstrating collapsing nested margins in the spec.

But now everything is set. It only took me a week or so longer than I expected. The next step: change everything again. This time, to my liking. I expect it to go faster this time.

0 comments

Wednesday, January 29, 2003

6:40 PM

W00t! I have updated the layout of the blog. Now that I've actually checked, I've found that it looks nearly the same in Safari, and similar but ugly in every other browser. The annoying thing is that it looks ugly in different ways in every other browser, since each one seems to position some of the elements slightly differently. I'm going to insist that that's not my fault, ignore it, and go on. There are some tiny text positioning differences in Safari, so I'll be cleaning that up shortly. Problems in other browsers are beyond my ability to care.

For those that care, the layout is now controlled entirely by an external stylesheet. There are no tables, breaks, or inline style tags in the entire page. I have validated the stylesheet. Except for the banner ad, which I can't control, I have also validated the HTML. Right now this page presents itself as HTML 4.01 Transitional, but it validates as XHTML 1.0 Strict without too much effort.

I found that I could work around the bugs I encountered in Safari by adding DIVs. For example, instead of <div style="float: left; width: 20%; margin: 5px">Content</div>, I used <div style="float: left; width: 20%"><div style="margin: 5px">Content</div></div>. I also inserted blank DIVs between sections that were fighting with each other.

The next step will be to rewrite the layout of the blog to make me happy. The left column doesn't need to be there and the center column isn't wide enough. My hope had been that once I converted to stylesheets, I wouldn't need to change the HTML and could change the layout on a whim just by rewriting the CSS, but I had to use so many DIVs that that may not work out. Oh well.

0 comments

1:47 PM

My last update was Thursday, meaning I've fallen somewhat behind on my goal of daily updates. As I said then, this blog is currently being laid out using tables, and I'm converting it to CSS. I have a couple of goals doing this. First, it's a useful learning exercise. Second, the blog needs a redesign anyway, and I figured if I convert everything to CSS, then to change the layout all I will need to change is the CSS.

Since I'm one to take things too far, I decided that I'd duplicate the design on a per pixel basis. This is utter foolishness, because (a) HTML really isn't designed for that, and (b) different browsers display the same page differently anyway. It's my belief that if you want precise layout, you don't want a website, you want a PDF. I wasn't going to let that stop me, and figured that if I got everything to match in Safari, it would be close enough in Mozilla and IE that I wouldn't have to worry about it.

Unfortunately, things haven't been going as planned. As I mentioned Thursday, I had the expectation that a block with a percentage width would calculate its width from its parent, and be fixed based on that. What I have found is that the elements inside the block can affect the width of the block itself. On Friday, I eventually figured out how to work around that, so if it comes out wrong I can add margins and padding to correct it. I don't know if this crops up in all web browsers or just in Safari, but it's certainly (to my mind) nonintuitive. I'm concerned that my workaround may be dependent on the content, and while it looks right in my test case, it won't be right in the live blog, but I'll burn that bridge when I come to it. I've been playing around, but haven't come up with a minimal code demo yet.

Friday night I started working on a rant to post here, but I didn't quite finish it, and although I've been meaning to get back to it, it hasn't happened yet. Perhaps later today.

Monday Cliff was in town. Generally, I want to spend business hours doing business things, but I was willing to "take a day off" to hang out with Cliff and play music at him.

Yesterday, I was back to work on the blog, and I was correct in my expectation that the knowledge I gained Friday would make things go faster yesterday, until I collided with a display bug in Safari. I put together a test case and sent a bug report to Apple, but it stalled out my development work. Basically, I want three blocks floating next to each other that are proportional to the window width, with gaps between them. (That would be the three columns in the blog, with all the posts in the second column.) Things are okay with the floating blocks, but when I add the gaps, things start disappearing. If you are using a browser that displays the test case correctly, you will see the text "Column 1", "Column 2", and "Column 3", all on the same line, spaced out across the window. In Safari, you get nothing, unless you reduce the width of the window enough, in which case "Column 2" appears. That strikes me as totally bizarre.

Today I had an invitation to play video games during the day with Jason, but I pushed that off on the basis that I should be working during the day. I'll see him tonight, so not much is lost on that front, but I blew it on the working front. I've been feeling surprisingly tired lately, and it caught up with me today. I got up briefly at 7:30 or so, but it didn't last and I went back to bed. I ended up sleeping until 11. Now that I think about it, last Wednesday was profoundly unproductive as well. Wonder if it's something about Wednesdays. As it stands, I've been playing too much Animal Crossing in the morning and haven't really been getting the most out of them anyway, but actually sleeping in feels like a significant setback.

And now, work. Step one: find a workaround for the Safari layout bug.

0 comments

RSS

FAQ

What does "rolls a hoover" mean, anyway?

"Roll a hoover" was coined by Christopher Locke, aka RageBoy (not worksafe). He enumerated some Hooverian Principles, but that might not be too helpful. My interpretation is that rolling a hoover means doing something that you know is stupid without any clear sense of what the outcome will be, just to see what will happen. In my case, I quit my job in an uncertain economy to try to start a business. I'm still not sure how that will work out.

Why is the HTML for this page not valid?

BlogSpot adds the advertisement that appears at the top of this page. That advertisement is not valid HTML and is outside of my control. I believe that aside from that ad, this page is valid HTML.