Doing my Part for Daily Bleatage

« An Endorsement for Iraqi Stability | Main | (Another) First Look at Vista »

Doing my Part for Daily Bleatage

By Brian | August 10, 2005 | Share on Facebook

Back home; checked my mail, discovered to my horror that the Bleat looked like crap in Windows, fixed it…

I sent him a mail yesterday afternoon, so I can only assume he’s referring to me. Just goes to show ya – behind every cyber-celebrity, there stands an army of unseen amateurs keeping the lights on. Such is life.

He also unwittingly enters into a debate that Jeff Porten and I have been having for as long as I can remember:

For reasons I cannot understand the HTML program – GoLive, or StayDead, depending on your experience – refused to accept 550 pixels as the value for the table’s width. I’d type 550; it would revert to 74. I redid it cell by cell; no good. Until eventually it worked. Sorry about that. Monday and Tuesday have been redone, so they should work. All I can say is this: it looked fine in Safari and IE for Mac. Go figure.

Now, clearly there’s a problem with GoLive. But here’s the more interesting question: is the fact that it looked fine on the Mac a problem with the Mac or a problem with Windows? I would argue that if the HTML says WIDTH=74, the page should display with a width of 74. Even if he originally typed in 550. If GoLive changed the HTML back to 74, he should see it on his screen as 74. Two reasons: first, the browser should do what it’s told and nothing more; and second, by “fixing” it for him, the Mac browsers obscured the problem until someone (ahem!) brought it to his attention…

This site, incidentally, has a similar problem. Most of the rollover buttons at the top (which are still Java apps and not Javascripts – I know, I know – I’ll change them as soon as I have some free time. Maybe this weekend. Really. I swear) are in a cell with WIDTH=442, and have widths that total 424. In Windows/Internet Explorer, they appear in one, neat horizontal row, which is what I’d expect, given that 424 < 442. In Mac/Safari and Mac/Firefox, the "Cool Links" button on the right wraps down to the next line. Jeff has argued that if my HTML were clean, it would work on all browsers. I say that if I do a good job adding up my column widths, I should have a reasonable expectation that any browser would follow the rules and display them on a single line. If my HTML is clean, then it's a bug in Safari and Firefox. If I'm missing something in my HTML, and IE is doing something to "help" me, then I say it's a bug in IE. On the one hand, I hope the move to Javascripts makes the problem go away. On the other hand, if it goes away, then it just means this problem is inconsistent and difficult to reproduce, suggesting it will never get solved...

Topics: Tech Talk | 6 Comments »

6 Responses to “Doing my Part for Daily Bleatage”

Michael Weinmayr says at August 10th, 2005 at 4:28 pm :

In Windows/Firefox, it looks correct. I’d love for you to say farewell to those Java buttons, however; each time I follow the RSS link to your page, I wince as the systems hangs to load Java.
Brian says at August 11th, 2005 at 12:03 am :

OK, well that’s one more piece of the puzzle. I wonder how it looks in Mac/IE. That would narrow it down to the software or the OS (maybe Firefox’s two versions have two different code versions with noticable differences?)
Michael Weinmayr says at August 11th, 2005 at 7:37 am :

I should probably mention that I’m actually using Deer Park, which is the nightly development build of Firefox 1.5, which has many many fixes compared to Fx 1.0.x. So, it also looks good in DeerPark/Mac, which I’m looking at now.

And IE/Mac looks good as well.

(Sorry ’bout the doublepost yesterday.)
Brian says at August 11th, 2005 at 1:10 pm :

Not a problem. Clearly, the comment traffic around here is not such that I don’t have time for a little maintenance.

As to the browsers, thanks for all the testing. It seems as though my HTML is OK, and Jeff and I were just looking at two, similar software bugs.

The question about browsers that “fix” your HTML for you still remains open, though…
Jeff Porten says at August 12th, 2005 at 1:52 am :

You’re conflating two issues here — all browsers render HTML, and in the course of rendering they usually add some cosmetic changes to deal with the many many web authors who think a closing tag is something they stopped doing in kindergarten. (As opposed to what it really is, something the trumpets do when someone does something silly.)

That doesn’t “fix” your HTML, since the HTML stays the same. The core of part of our argument is over whether it’s better to rely on a codewhopping monstrosity like GoLive to do your pages for you in the first place, or whether knowing enough HTML to not run into Lilek’s problems in the first place is a good idea.

in any case, it’s a safe bet GoLive is going to go away shortly anyway, so Jim will have his hands full learning his new monstrosity and won’t have time to worry about table widths.
Brian says at August 12th, 2005 at 11:09 am :

Fair enough – two issues:

Taking the second one first, I think we’re all in agreement that page generators shouldn’t change your HTML for you. I’ve never used GoLive, so I don’t know the specifics there. The current MSFrontPage gives me a GUI environment where I can drag & drop to create pages, as well as a “pure” HTML environment where I can manually edit the code, as if I were in a text editor. Lilek’s comment that he “typed in 550 and it changed it to 74″ suggests that GoLive doesn’t have that distinction. If I type 550 into my HTML, MSFrontPage isn’t going to change that in the code.

Your comment seems to suggest that anyone who uses GoLive or FrontPage doesn’t know enough about HTML to do it themselves. That certainly isn’t true in my case, and the very fact that Lileks is talking about table widths suggests it’s not true in his case either.

The other issue is what the browser does with the code once it’s written. Lileks’ browser apparently took that “74″ that GoLive forced upon him, and displayed it as if it were 550. This is a much bigger issue in my opinion. You seem OK with having the browser imply a closing tag where there isn’t one because developers “stopping using them in kindergarten.” I think that’s a slippery slope, since there’s no guarantee that every browser is going to imply the same tag in the same place. Since the developer can’t test on every browser, the only sure way to be consistent is to faithfully interpret the code. If the close tag weren’t implied (or if the table widths were faithfully followed), developers would “go back to school” and learn to do it right. Then everybody would be happy.