| I'm trying to be good, I really am. I installed the Mozilla Firefox browser today because I keep reading that using IE is going to destroy my computer. Two problems right out of the gate:
My Norton Internet Security prompts me that "firefox.exe is attempting to access the internet" every new page I go to. I have to write a rule allowing that for each page. Some pages cause 6-7 prompts, so forget that. If I turn off the firewall, I'm vulnerable to outsiders trying to access the computer even if firefox is blocking malicious pop-ups. So I'm back to IE.
Another thing I noticed is Firefox reads Tree pages in the "one column" format inconstistently. E.G., when I first go to Jim's page it fills the entire screen left to right, but if I hit "older posts," it returns to the correct width (the width of the clouds picture). As I page back through my and Sally's pages, the width changes from correct to screen-filling to correct, almost at random. I can't figure out anything from my own html that would make one /pageback page different from another. The same thing happens when I view groups of posts by date from the archive--there, almost all the pages are screen-filling; in Sally's archive it's a mix. Again, back to IE.
Also, now I have this "Java Console" thingy on my status bar that wasn't there before. What the hell is that? (Oh, it goes off when you turn off Firefox. Never mind.)
Well, one distinct advantage to the Firefox browser is that it shows animated GIFs at their proper speed. All the extra junk loaded into IE by Microsoft, I guess, really slows them down, sometimes almost to a crawl. I think I'll use FF for Tree stuff more, because it's generally faster. Sure wish I knew why it renders page widths inconsistently, though. It almost seems like random behavior, but I know there's a reason for it.
More likely it's the out of spec HTML code on this site. Firefox is amazingly standards compliant. Our HTML is not. I wish this wasn't the case, but I've just never been that interested in dealing with that problem. I'll try to take a look though.
Your other problem with Norton sounds like a Norton / OS problem as well. I don't really know enough about windows, but my guess is that it considers IE to be your default browser, so when this other program "firefox" tries to access the internet over port 80 (the http port) Norton sees this as a security situation. Probably (and this is what I don't know) there is a way to tell Windows that firefox is your default web browser, and then this would probably make norton not freak out when it tried to connect over that port.
Ulp. Firefox has been asking me if I want it to be my default browser, and since I've been in test mode, I've said no. I'll try switching (I'm just always afraid to commit myself to something I can't undo, with Windows involved.)
If it's any help, the page-width rendering issue may have something to do with some combination of text and pictures on the page. My Animation Log page, which is mostly just gifs, keeps the same margins as I page back through it.
No big deal, though, that's good to know that FF is picky. Since the main browsers people use aren't that picky, it doesn't matter so much.
Okay, I think I figured out what's happening with Firefox loading DMTree pages (this only applies to the one-column format pages). This is all intuitive. It all has to do with how big the page requested is. The browser loads the pages really, really fast, and the more html (text and tags) are on the page, the greater the likelihood the browser will "miss" the instruction telling it how wide to make the page. I know this because (1) small pages always load properly, (2) semi-big pages load properly on refresh (its 50/50 whether they get it right the first time), and (3) really big pages never load properly. Thus, tommoody/date/2001/12, which only has four posts, loads correctly, while tommoody/date/2004/05/, which has over 30, never does.
Jim, I guess my only thought is, is there some way to beef up, or make more "noticeable," the instruction in one-column format pages telling the browser how wide to make the page?
I think I licked the Norton problem. The only thing I don't like is, under IE I had the machine prompt for cookies, and under Firefox, I get about 30 times more prompts, so I had to change it to "accept all" the damn things.
No doubt you are onto something here with large content vs. small content pages, but there isn't any way the browser could be missing any HTML nor for some HTML elements to be more clear than others. It's either there or it's not.
The HTML doesn't specify a width in pixels. It just tells the browser to make the column a certain percentage of the total width of the browser window (since the server can't know how wide you have made your browser window.) If an image (or long unbroken string of text) is wider than the column width, the browser will push the column out further than the specified percentage.
Is it possible that on pages you see rendered (incorrectly) at 100% of the browsers width contain an image (or long text string) that is forcing it out? To me it doesn't seem like this is the problem, but it's the only thing I can think of.
I have looked at the pages you mention in Mac firefox 0.8 and they all render the same (correctly.) So this is going to be hard for me to debug. I will download 0.9 later and try it in that, maybe they introduced a bug. You are using 0.9, right?
Yes, although I just uninstalled it and am about to reinstall it because I did something (ate a bad popup?) that caused all sites to refuse it. I'm having second (third) thoughts about it if it's that delicate.
As for the page width issue, no, it's definitely not some big-image-(or combination of images)-pushing-the-text-outside-the-margins type thing. If it were that, I doubt it would fix itself on refresh.
I'll let you know if/when I'm back on FF and if I'm gonna use it. There are a lot of things I like about it, but it has to be reliable. Thanks for looking into this!
What do you mean "caused all sites to refuse it"?
I get a popup "alert" that says "the connection was refused when attempting to contact www.digitalmediatree.com". The screen is blank. Uggh--I just realized it's a Norton issue again. I turned off internet security and the page loaded right up. Guess my "rule" didn't work. God, this is frustrating.
Firefox is extremely stable. I'm not surprised Norton is the problem. Why microsoft does not include a decent firewall with their OS is a bit of a mystery.
OK, I think I figured it out. I'll spare you the details. I'm back on Firefox and Norton is on, too.
Not really OT, but there is yet another massive security hole in IE on windows. Very nasty indeed. Changing the way you work is always a bit of a pain, but I really think it is worth it in this case.
Supposedly I was protected from that one by a prior update (that was the official word), but I've done about a dozen MS Updates to plug security holes, and I'm sick of it. What do you know about Thunderbird for email?
I haven't used it. Would be interested in your thoughts if you try it.
Regarding the columns thing, tables are tricky. Could be something in the dmt html that triggers something in the browser.
I'm just starting to learn about nested tables and CSS, but it's clear that there are differences in how browsers interpret the html.
Did you know Firefox, and Mozilla on which it is based, have a handy plug in architecture that allows you to download extensions which add features to the browser? Wired takes a look at the most popular. The complete list is at mozilla.org. BugMeNot looks especially cool.
Thanks for those. I've effectively switched and am not looking back. IE cooking handling was terrible--I always had to use Netscape to buy tickets, etc. Streaming from a URL was just impossible--I had to save everything to hear or see it. And IE never met a pop-up it didn't like. There are many other things that IE did worse, but I'm trying to banish the "IE years" from my memory.
I've just downloaded firefox, and I like. The fine granularity on cookie control is nice. The fact that it has an integrated pop-up blocker is most excellent. And the fact that it logs javascript errors rather than putting an error message on the screen is great. (I think our new firewall is screwing up javascript (which is mostly just annoying anyway.))
Anyway, which pages were giving the layout problems? I can take a look to see if there are any coding errors.
I have a guess about what's going on. It's common for pages with an external CSS file to load and then "flash" as the CSS takes over the formating. There may be a bug in Firefox in how it deals with the dynamic re-layout. On some slow-to-load DKos pages, if I scroll around before the "flash", some of the blog ads end up in funny places. But if I just let the page load complete, the layout looks normal.
My page loads correctly on a seemingly random basis. The only problem is margin width, not image placement or anything like that. I'll do screen shots to show how it looks loaded "correctly" and "incorrectly." It does have something to do with the amount of material on the page, because the pages with very little text are never a problem and the pages with a lot of text always are. My page appears to be right on the cusp--I could probably solve the problem by setting the number of posts on the page from 8 to 4. If you're not seeing this behavior on your screen with a Windows/Firefox combo it may be other factors--CPU size? screen size? I dunno.
My "quick fix" for the margins is to resize the text; if I hit "Ctrl -1" the margin snaps to its correct position. No guarantee that will hold on the next load, though.
Here's how my page looks when loaded correctly Here's how my page looks when loaded incorrectly (50-75% of the time).
That's exactly what I see. I looked at the source and my "CSS flash" theory isn't a factor here. You have CSS in the header, not in a linked file, and even then, the CSS doesn't have anything to do with this layout issue. However, I don't think the table syntax in the body of the page is clean.
In psuedo-code, it's some thing like this ...
table (set explicitly to two columns)
......table row (only one column)
............nested table (most of the page is here)
......end row
......table row (column span of 3)
............(page footer)
......end row
end table
The syntax problem is the inconsistent number of columns. The table is set up with two, but the first row has only one, and the last row says it's spanning three.
I can postulate what's going wrong with Firefox. It may sometimes start laying out the page before it sees the footer, to give the marginless look. If it sees the footer before it starts the layout, it centers the body with margins.
The solution is to clean up the page template so that the table syntax is clean. I'm guessing that's a Jim thing.
Well, here's the 2 column table page template if anyone wants to take a crack at fixing it. There is a little PHP in there, but not too much, and it doesn't really matter. The HTML is the problem. (Obviously the heavy lifting PHP stuff is in the included files, especially $page_engine.)
I'll try when I get a chance.
Whoa, page engine has a lot of stuff. I didn't look at it, because I can see the problem in the 2 column table page template. Is Tom using a modified version? Because what's in your html doesn't match what I'm seeing in the source. The differences are highlighted in red
table (set explicitly to two columns)
......table row
............table data
..................(left text inserted with php script)
............end table data
...........table data
..................nested table (most of the page is here)
...........end table data
...........table data
..................(very narrow column with nothing in it)
...........end table data
......end table row
......table row (column span of 3)
............(page footer)
......end table row
end table
The stuff in bold is just gone from Tom's source, and from looking at the html it shouldn't be. Even if the php script doesn't add in the "left text", it doesn't make sense that the tags would just dissappear. And the last column on that row doesn't even have any php near it. My best guess is that Tom's template is non-standard.
Whoops. Tom is using the one column table. That probably explains why he gets different results from most others.
Probably it's the cols=2 in the big table. Should only be 1, right? I'll try to change it.
Also changed the colspan=3 in the td for the navigation links at the bottom (I must have just copied and pasted that in from the 2 column table without changing it.)
Anyway, did that work?
Hmmm ... the one column template doesn't seem to match either. It has cols=1, whereas tom's source shows cols=2. And the footer doesn 't have the colspan=3 that I see in tom's source.
we're commenting out of sync ... I'll go look at the tom's page ...
Okay, the table syntax looks clean now, but I'm still seering erratic behavior in how the margin width is handled in firefox. My guess is there's a bug in firefox's handling of embedded tables. If you move the width=73% from the embedded table to a location higher up in the hiearchy (e.g. the td that contains the embedded table) that might make the problem go away. But I'm just speculating at this point.
this validator complains about an illegal character on the line containing the start of the nested table
validation output
That's a character encoding issue. I am supposed to declare a character encoding in the header, but to me it is a dark art and I have no idea what to declare. A lot of amateur sites forgo this, and it's not really too much of a problem in terms of browser rendering, at least if you stick to english.
The problem on Tom's page is an 'ä' in his post. Again, this isn't really a problem in terms of rendering, but the validator chokes on it because we didn't declare a character encoding in which ä is a valid character.
If you go one page back and put that through the validator you get rid of the illegal character issue and can see the real problems. They are numerous, but again, all sort of picky. These were built when a lot of us were using Navigator 4.0, and much has been deprecated since then. But it all still works. Very invalid though.
I'd love to have validating pages, but god it seems like such drudgery to me.
I'm at a loss at this point as to why the margin problem happens. I've loaded the source onto my drive, and never see the problem.
I added the web developer tool bar, and have been playing around with the outline functions. I'm guessing here, but the p tags may have something to do with it. In general the div tags seem clean, but the p tags may or may not have closures. Perhaps the block processing and the table processing get catywompus.
I'm a lazy br tag kinda coder, so the only p tags on my page are generated by the php. Taking a quick look at my page, I see pairs of p and slash p, so I'm assuming the php is clean. Perhaps Tom has some one-sided p tags in his text entry that should be cleaned up.
Wha--? There's a problem with not closing p (paragraph) tags??? Seriously, I've been using ps without /ps since day one. Is this bad? I've just been treating it as a lazy way of not using br-br for a double hard return. I tried adding /ps to my first couple of pages of posts to see if it's making a difference on this margin problem, but I'm still getting inconsistent behavior. But I'm curious, in the basic textbook html sense, when should you, or why you would you ever, use p instead of br-br (especially if using p means you always have to close with /p)? Does anyone know?
Well, cracking open my recently acquired text book ...
"Block-level elements define structural content blocks such as paragraphs (p) or headings (h1). Block-level elements generally introduce line breaks visually. Special forms of blocks such as unordered lists (ul) can be used to create lists of information. Inline elements such as bold (b), strong (strong), and numerous others occur within blocks. These elements (usually) do not introduce any returns."
Typically inline elements such as (span), (em), (i) are used for styling only. Block-level elements, such as (div), (p) are used for creating document structure, and also for styling. However, there seems to be a bit of a fuzzy line between the two types of elements.
I've almost exclusively used inline elements, with the exception of lists. But as I'm getting to know CSS, I'm working more with block elements and tables.
I found an online primer that said yes, p tags don't have to close but don't trust that because it could change in the next version. I did find a page of Sally's with a margin problem by paging back, and she doesn't use p tags. I just changed my page back to the 2-column format as an easy way of dealing with this.
Yeah, p's used to be one of the few tags that didn't need a closure. And all browsers still understand unclosed p's. But technically, now that they are trying to transition to xhtml (which would have any html document be a valid xml document) every tag has to be closed. I think there is even some new thing where you are supposed to have a weird space inside the closing tag: </p > . But honestly I don't keep up with these things. We're not even valid 4.0 html, so we are certainly not valid xhtml.
Still, it would be nice if pages rendered the same, in the same browser, which evidently they aren't even doing.
The wierd thing you're thinking of is the br tag. In xhtml, all tags must have closures, so br becomes a self-closing tag ... <br />
|
My Norton Internet Security prompts me that "firefox.exe is attempting to access the internet" every new page I go to. I have to write a rule allowing that for each page. Some pages cause 6-7 prompts, so forget that. If I turn off the firewall, I'm vulnerable to outsiders trying to access the computer even if firefox is blocking malicious pop-ups. So I'm back to IE.
Another thing I noticed is Firefox reads Tree pages in the "one column" format inconstistently. E.G., when I first go to Jim's page it fills the entire screen left to right, but if I hit "older posts," it returns to the correct width (the width of the clouds picture). As I page back through my and Sally's pages, the width changes from correct to screen-filling to correct, almost at random. I can't figure out anything from my own html that would make one /pageback page different from another. The same thing happens when I view groups of posts by date from the archive--there, almost all the pages are screen-filling; in Sally's archive it's a mix. Again, back to IE.
Also, now I have this "Java Console" thingy on my status bar that wasn't there before. What the hell is that? (Oh, it goes off when you turn off Firefox. Never mind.)
- tom moody 6-26-2004 7:52 pm
Well, one distinct advantage to the Firefox browser is that it shows animated GIFs at their proper speed. All the extra junk loaded into IE by Microsoft, I guess, really slows them down, sometimes almost to a crawl. I think I'll use FF for Tree stuff more, because it's generally faster. Sure wish I knew why it renders page widths inconsistently, though. It almost seems like random behavior, but I know there's a reason for it.
- tom moody 6-27-2004 4:55 pm [add a comment]
More likely it's the out of spec HTML code on this site. Firefox is amazingly standards compliant. Our HTML is not. I wish this wasn't the case, but I've just never been that interested in dealing with that problem. I'll try to take a look though.
Your other problem with Norton sounds like a Norton / OS problem as well. I don't really know enough about windows, but my guess is that it considers IE to be your default browser, so when this other program "firefox" tries to access the internet over port 80 (the http port) Norton sees this as a security situation. Probably (and this is what I don't know) there is a way to tell Windows that firefox is your default web browser, and then this would probably make norton not freak out when it tried to connect over that port.
- jim 6-27-2004 6:03 pm [add a comment]
Ulp. Firefox has been asking me if I want it to be my default browser, and since I've been in test mode, I've said no. I'll try switching (I'm just always afraid to commit myself to something I can't undo, with Windows involved.)
If it's any help, the page-width rendering issue may have something to do with some combination of text and pictures on the page. My Animation Log page, which is mostly just gifs, keeps the same margins as I page back through it.
No big deal, though, that's good to know that FF is picky. Since the main browsers people use aren't that picky, it doesn't matter so much.
- tom moody 6-27-2004 6:30 pm [add a comment]
Okay, I think I figured out what's happening with Firefox loading DMTree pages (this only applies to the one-column format pages). This is all intuitive. It all has to do with how big the page requested is. The browser loads the pages really, really fast, and the more html (text and tags) are on the page, the greater the likelihood the browser will "miss" the instruction telling it how wide to make the page. I know this because (1) small pages always load properly, (2) semi-big pages load properly on refresh (its 50/50 whether they get it right the first time), and (3) really big pages never load properly. Thus, tommoody/date/2001/12, which only has four posts, loads correctly, while tommoody/date/2004/05/, which has over 30, never does.
Jim, I guess my only thought is, is there some way to beef up, or make more "noticeable," the instruction in one-column format pages telling the browser how wide to make the page?
I think I licked the Norton problem. The only thing I don't like is, under IE I had the machine prompt for cookies, and under Firefox, I get about 30 times more prompts, so I had to change it to "accept all" the damn things.
- tom moody 6-28-2004 6:17 pm [add a comment]
No doubt you are onto something here with large content vs. small content pages, but there isn't any way the browser could be missing any HTML nor for some HTML elements to be more clear than others. It's either there or it's not.
The HTML doesn't specify a width in pixels. It just tells the browser to make the column a certain percentage of the total width of the browser window (since the server can't know how wide you have made your browser window.) If an image (or long unbroken string of text) is wider than the column width, the browser will push the column out further than the specified percentage.
Is it possible that on pages you see rendered (incorrectly) at 100% of the browsers width contain an image (or long text string) that is forcing it out? To me it doesn't seem like this is the problem, but it's the only thing I can think of.
I have looked at the pages you mention in Mac firefox 0.8 and they all render the same (correctly.) So this is going to be hard for me to debug. I will download 0.9 later and try it in that, maybe they introduced a bug. You are using 0.9, right?
- jim 6-28-2004 7:37 pm [add a comment]
Yes, although I just uninstalled it and am about to reinstall it because I did something (ate a bad popup?) that caused all sites to refuse it. I'm having second (third) thoughts about it if it's that delicate.
As for the page width issue, no, it's definitely not some big-image-(or combination of images)-pushing-the-text-outside-the-margins type thing. If it were that, I doubt it would fix itself on refresh.
I'll let you know if/when I'm back on FF and if I'm gonna use it. There are a lot of things I like about it, but it has to be reliable.
Thanks for looking into this!
- tom moody 6-28-2004 7:52 pm [add a comment]
What do you mean "caused all sites to refuse it"?
- jim 6-28-2004 7:55 pm [add a comment]
I get a popup "alert" that says "the connection was refused when attempting to contact www.digitalmediatree.com". The screen is blank. Uggh--I just realized it's a Norton issue again. I turned off internet security and the page loaded right up. Guess my "rule" didn't work. God, this is frustrating.
- tom moody 6-28-2004 8:12 pm [add a comment]
Firefox is extremely stable. I'm not surprised Norton is the problem. Why microsoft does not include a decent firewall with their OS is a bit of a mystery.
- jim 6-28-2004 8:19 pm [add a comment]
OK, I think I figured it out. I'll spare you the details. I'm back on Firefox and Norton is on, too.
- tom moody 6-28-2004 8:30 pm [add a comment]
Not really OT, but there is yet another massive security hole in IE on windows. Very nasty indeed. Changing the way you work is always a bit of a pain, but I really think it is worth it in this case.
- jim 6-28-2004 8:36 pm [add a comment]
Supposedly I was protected from that one by a prior update (that was the official word), but I've done about a dozen MS Updates to plug security holes, and I'm sick of it. What do you know about Thunderbird for email?
- tom moody 6-28-2004 8:43 pm [add a comment]
I haven't used it. Would be interested in your thoughts if you try it.
- jim 6-28-2004 8:47 pm [add a comment]
Regarding the columns thing, tables are tricky. Could be something in the dmt html that triggers something in the browser.
I'm just starting to learn about nested tables and CSS, but it's clear that there are differences in how browsers interpret the html.
- mark 6-29-2004 2:11 am [add a comment]
Did you know Firefox, and Mozilla on which it is based, have a handy plug in architecture that allows you to download extensions which add features to the browser? Wired takes a look at the most popular. The complete list is at mozilla.org. BugMeNot looks especially cool.
- jim 7-08-2004 6:23 pm [add a comment]
Thanks for those. I've effectively switched and am not looking back. IE cooking handling was terrible--I always had to use Netscape to buy tickets, etc. Streaming from a URL was just impossible--I had to save everything to hear or see it. And IE never met a pop-up it didn't like. There are many other things that IE did worse, but I'm trying to banish the "IE years" from my memory.
- tom moody 7-08-2004 6:44 pm [add a comment]
I've just downloaded firefox, and I like. The fine granularity on cookie control is nice. The fact that it has an integrated pop-up blocker is most excellent. And the fact that it logs javascript errors rather than putting an error message on the screen is great. (I think our new firewall is screwing up javascript (which is mostly just annoying anyway.))
Anyway, which pages were giving the layout problems? I can take a look to see if there are any coding errors.
- mark 7-29-2004 6:06 am [add a comment]
I have a guess about what's going on. It's common for pages with an external CSS file to load and then "flash" as the CSS takes over the formating. There may be a bug in Firefox in how it deals with the dynamic re-layout. On some slow-to-load DKos pages, if I scroll around before the "flash", some of the blog ads end up in funny places. But if I just let the page load complete, the layout looks normal.
- mark 7-29-2004 10:09 pm [add a comment]
My page loads correctly on a seemingly random basis. The only problem is margin width, not image placement or anything like that. I'll do screen shots to show how it looks loaded "correctly" and "incorrectly." It does have something to do with the amount of material on the page, because the pages with very little text are never a problem and the pages with a lot of text always are. My page appears to be right on the cusp--I could probably solve the problem by setting the number of posts on the page from 8 to 4. If you're not seeing this behavior on your screen with a Windows/Firefox combo it may be other factors--CPU size? screen size? I dunno.
- tom moody 7-29-2004 10:23 pm [add a comment]
My "quick fix" for the margins is to resize the text; if I hit "Ctrl -1" the margin snaps to its correct position. No guarantee that will hold on the next load, though.
- tom moody 7-29-2004 10:27 pm [add a comment]
Here's how my page looks when loaded correctly
Here's how my page looks when loaded incorrectly (50-75% of the time).
- tom moody 7-29-2004 10:36 pm [add a comment]
That's exactly what I see. I looked at the source and my "CSS flash" theory isn't a factor here. You have CSS in the header, not in a linked file, and even then, the CSS doesn't have anything to do with this layout issue. However, I don't think the table syntax in the body of the page is clean.
In psuedo-code, it's some thing like this ...
table (set explicitly to two columns)
......table row (only one column)
............nested table (most of the page is here)
......end row
......table row (column span of 3)
............(page footer)
......end row
end table
The syntax problem is the inconsistent number of columns. The table is set up with two, but the first row has only one, and the last row says it's spanning three.
I can postulate what's going wrong with Firefox. It may sometimes start laying out the page before it sees the footer, to give the marginless look. If it sees the footer before it starts the layout, it centers the body with margins.
The solution is to clean up the page template so that the table syntax is clean. I'm guessing that's a Jim thing.
- mark 7-30-2004 12:12 am [add a comment]
Well, here's the 2 column table page template if anyone wants to take a crack at fixing it. There is a little PHP in there, but not too much, and it doesn't really matter. The HTML is the problem. (Obviously the heavy lifting PHP stuff is in the included files, especially $page_engine.)
I'll try when I get a chance.
- jim 7-30-2004 1:11 am [add a comment]
Whoa, page engine has a lot of stuff. I didn't look at it, because I can see the problem in the 2 column table page template. Is Tom using a modified version? Because what's in your html doesn't match what I'm seeing in the source. The differences are highlighted in red
table (set explicitly to two columns)
......table row
............table data
..................(left text inserted with php script)
............end table data
...........table data
..................nested table (most of the page is here)
...........end table data
...........table data
..................(very narrow column with nothing in it)
...........end table data
......end table row
......table row (column span of 3)
............(page footer)
......end table row
end table
The stuff in bold is just gone from Tom's source, and from looking at the html it shouldn't be. Even if the php script doesn't add in the "left text", it doesn't make sense that the tags would just dissappear. And the last column on that row doesn't even have any php near it. My best guess is that Tom's template is non-standard.
- mark 7-30-2004 1:33 am [add a comment]
Whoops. Tom is using the one column table. That probably explains why he gets different results from most others.
- jim 7-30-2004 1:36 am [add a comment]
Probably it's the cols=2 in the big table. Should only be 1, right? I'll try to change it.
- jim 7-30-2004 1:39 am [add a comment]
Also changed the colspan=3 in the td for the navigation links at the bottom (I must have just copied and pasted that in from the 2 column table without changing it.)
Anyway, did that work?
- jim 7-30-2004 1:42 am [add a comment]
Hmmm ... the one column template doesn't seem to match either. It has cols=1, whereas tom's source shows cols=2. And the footer doesn 't have the colspan=3 that I see in tom's source.
- mark 7-30-2004 1:44 am [add a comment]
we're commenting out of sync ... I'll go look at the tom's page ...
- mark 7-30-2004 1:45 am [add a comment]
Okay, the table syntax looks clean now, but I'm still seering erratic behavior in how the margin width is handled in firefox. My guess is there's a bug in firefox's handling of embedded tables. If you move the width=73% from the embedded table to a location higher up in the hiearchy (e.g. the td that contains the embedded table) that might make the problem go away. But I'm just speculating at this point.
- mark 7-30-2004 1:55 am [add a comment]
this validator complains about an illegal character on the line containing the start of the nested table validation output
- mark 7-30-2004 2:41 am [add a comment]
That's a character encoding issue. I am supposed to declare a character encoding in the header, but to me it is a dark art and I have no idea what to declare. A lot of amateur sites forgo this, and it's not really too much of a problem in terms of browser rendering, at least if you stick to english.
The problem on Tom's page is an 'ä' in his post. Again, this isn't really a problem in terms of rendering, but the validator chokes on it because we didn't declare a character encoding in which ä is a valid character.
If you go one page back and put that through the validator you get rid of the illegal character issue and can see the real problems. They are numerous, but again, all sort of picky. These were built when a lot of us were using Navigator 4.0, and much has been deprecated since then. But it all still works. Very invalid though.
I'd love to have validating pages, but god it seems like such drudgery to me.
- jim 7-30-2004 2:54 am [add a comment]
I'm at a loss at this point as to why the margin problem happens. I've loaded the source onto my drive, and never see the problem.
I added the web developer tool bar, and have been playing around with the outline functions. I'm guessing here, but the p tags may have something to do with it. In general the div tags seem clean, but the p tags may or may not have closures. Perhaps the block processing and the table processing get catywompus.
I'm a lazy br tag kinda coder, so the only p tags on my page are generated by the php. Taking a quick look at my page, I see pairs of p and slash p, so I'm assuming the php is clean. Perhaps Tom has some one-sided p tags in his text entry that should be cleaned up.
- mark 7-30-2004 5:54 am [add a comment]
Wha--? There's a problem with not closing p (paragraph) tags??? Seriously, I've been using ps without /ps since day one. Is this bad? I've just been treating it as a lazy way of not using br-br for a double hard return. I tried adding /ps to my first couple of pages of posts to see if it's making a difference on this margin problem, but I'm still getting inconsistent behavior. But I'm curious, in the basic textbook html sense, when should you, or why you would you ever, use p instead of br-br (especially if using p means you always have to close with /p)? Does anyone know?
- tom moody 7-30-2004 7:41 am [add a comment]
Well, cracking open my recently acquired text book ...
Typically inline elements such as (span), (em), (i) are used for styling only. Block-level elements, such as (div), (p) are used for creating document structure, and also for styling. However, there seems to be a bit of a fuzzy line between the two types of elements.I've almost exclusively used inline elements, with the exception of lists. But as I'm getting to know CSS, I'm working more with block elements and tables.
- mark 7-30-2004 11:50 am [add a comment]
I found an online primer that said yes, p tags don't have to close but don't trust that because it could change in the next version. I did find a page of Sally's with a margin problem by paging back, and she doesn't use p tags. I just changed my page back to the 2-column format as an easy way of dealing with this.
- tom moody 7-30-2004 11:58 am [add a comment]
Yeah, p's used to be one of the few tags that didn't need a closure. And all browsers still understand unclosed p's. But technically, now that they are trying to transition to xhtml (which would have any html document be a valid xml document) every tag has to be closed. I think there is even some new thing where you are supposed to have a weird space inside the closing tag: </p > . But honestly I don't keep up with these things. We're not even valid 4.0 html, so we are certainly not valid xhtml.
Still, it would be nice if pages rendered the same, in the same browser, which evidently they aren't even doing.
- jim 7-30-2004 5:54 pm [add a comment]
The wierd thing you're thinking of is the br tag. In xhtml, all tags must have closures, so br becomes a self-closing tag ... <br />
- mark 7-30-2004 8:19 pm [add a comment]