Page Preview is in IE6 / Firefox Quirks mode

[cromagnon]

Hi Henri,

I've emailed this to you too, but thought it sensible to post to the forum as well.

--------------------------------------------------------------------------------------------------------------------------

I've stumbled across a small, but significant, bug (I think) that affects one of the sites I've installed SM v. 2 onto. I was finding that the page preview mangled the pages. In particular, padding on the divs in my pure CSS layout at www.bushburyhillprimary.org.uk was wrong.

This is potentially a big problem for me, because the people who will be using the system are teacher and admin staff in schools and I suspect they will panic and believe they are messing up the site. So I did a little digging - copying the source code from the preview page into Dreamweaver and so on - and it appears that because the first item in source for the the preview page is not the doctype (it is the table with "Click here to close this preview window"), IE6 is going into quirks mode instead of standards compliant mode. Copying the table tags directly AFTER the doctype in a test page leads to it rendering correctly. I've confirmed that the preview page is in quirks mode by using Firefox to preview and selecting "View page info" (although firefox' version of quirks mode renders the page correctly anyway!)

I don't know if this is easy to fix from your end . . . I'm hoping it's relatively straightforward.

-------------------------------------------

[admin]

OK, so basically, if I remove the "click this button to close this window", then it will solve the problem?

Let me know if that is the case, because if so... this might trigger me to try and figure out a better way for the preview system.

Currently, I just "add" the "extra" html code you see there at the top of the page.  But obviously, that is messing things up for you.. so it's not going to work. I hate to screw up your hard work and good coding, by adding my own crappy "solution" to get a "click here to close" button.

So here's what I'm thinking...

Frames.

I know they suck, and I hate to use them... but in this situation, it might be a better solution.

Basically, If I create two frame pages. the top would be the "click here to close" from, and the bottom would be your page preview.

Do you think that would work?

If so, let me know and I'll start trying to figure out how to make that happen.   It's a bit tricky, because there has to be a frameset page, which creates the frame.. so I'm not sure how best to do it.

[cromagnon]

Frames is one option, yes, and this case would be a legitimate use of then (one of the very few!)

Another option is some sort of algorithm that picks up the doctype from the document in question and places it above the table with "Click this button" in the source code for the preview. If automatic detection of the doctype isn't easy, then maybe it could be set as an option in the admin area: i.e. What is the doctype of your site: XHTML 1.0 Strict, Transitional etc.

Automatic detection is best though, as I suppose some people may mix doctypes for different parts of their site.

Thanks for the really quick response, Henri. Other than this issue, I'm loving the flexibility of the new version.

[admin]

Automatic detection of the doctype would be extremely difficult, because there are just so many possible values. Everything from legit doctypes to purposely incorrect doctypes.

OK... I think frames would be the best solution here.. but first I want to be 100% sure that it will fix this problem.

Can you definately confirm that NOT having the "click here to close" html above your html *will* fix this problem?  If the problem is caused by something else, then I will try to figure that out.. I don't want to spend time fixing something that isn't broken... (even if it doesn't make the program better), because right now I'm trying to prioritize the needed fixes/problems, etc.



Let me know and I'll start cracking on this.

[cromagnon]

What I've just done is this. I've viewed the source for the preview page and have copied this into a text file which I've then saved as an html file. Opening this in IE6 shows the version in Quirks mode - i.e. where padding is rendered incorrectly. Copying the doctype to above the <table> tags and reviewing the page again shows that it renders correctly.

The doctype needs to be first in the previewed page (whether in a frame or not). This means that it also need to be before these lines:

-------------------------------------------------------------------
<script language="JavaScript"> document.focus(); </script>
<base href="http://www.bushburyhillprimary.org.uk/index.php" />
-----------------------------------------------------------------------

So it's not just enough to move the table into a top frame. There's an issue here with the <base href> line as this wil have to be in the lower frame (i.e. the one with the page preview in) but will have to be after the doctype in that page.

The other possible issue is that there is a separate doctype for frameset pages anyway. I don't use frames, so I'm not sure what the effect of having a (for example) xhtml transitional doctype in a page inside a frameset would be; can anyone else help here? I suspect it won't really matter (the preview page wouldn't validate, but that's not important at all).

The easiest way to check what rendering mode is being used ina page is to use "view page info" in Firefox.

Hope this helps . . . . .

Automatic detection of the doctype would be extremely difficult, because there are just so many possible values. Everything from legit doctypes to purposely incorrect doctypes.

OK... I think frames would be the best solution here.. but first I want to be 100% sure that it will fix this problem.

Can you definately confirm that NOT having the "click here to close" html above your html *will* fix this problem?  If the problem is caused by something else, then I will try to figure that out.. I don't want to spend time fixing something that isn't broken... (even if it doesn't make the program better), because right now I'm trying to prioritize the needed fixes/problems, etc.



Let me know and I'll start cracking on this.

 

[cromagnon]

Another option is to have a text box in the admin page into which admins can paste the doctype definition they are using for the site (if applicable). This doctype would then be automatically inserted into the code at the start of the preview page. For sites where doctype wasn't used, or where quirks mode made no difference to site layout anyway, this option could then simply be ignored. Conveniently, if site admins don't understand what the doctype is all about, then it's not going to make a difference, because if they are not using one, then browsers will use Quirks mode to render their pages anyway!

This idea means that you, Henri, don't need to sniff out the doctype using your SM code or keep up with the latest doctypes as they appear in the future.

[Jenkinhill]

Just found another problem with preview. Using the latest beta of IE7 the base href is ignored. It may be because it is incorrectly located - ie not within head elements. I'll play some more.

Later: IE7 b2 will not display the preview page correctly because the base href needs to be in the head element and the "Click to close" table must be within the body of the page. Without the correct XHTML structure the page shows with no CSS applied and no images. IE7 is far more W3C standards compliant than IE6.

Henri, you mentioned using frames for the preview page? I suspect that an iframe might work, but the base href will still need to be inserted into the head element of the framed page.

[cromagnon]

I've had a bit more of a play, using IE6, IE7 Beta 2 and Firefox (can't confirm this for other browsers e.g. Safari) and it appears that it is ok to have two sets of head tags as far as rendering in these browsers is concerned (obviously, it wouldn't validate). So this order in the page preview code should be OK:

DOCTYPE (maybe pulled from a text box in the admin page)
TABLE (with "click here to close")
<head>
<script language="JavaScript"> document.focus(); </script>
<base href="http://www.example.com" />
</head>

.... then the actual page itself (which would contain another set of head tags)

It's a bit of a hack, but at least it means that all of the additional stuff is parsed at the top of the code without having to sniff out the head tags and paste the <base> tags inside them.

[cromagnon]

Hi Henri,

I just wondered what your thoughts were on this issue, now? Have you selected an approach to deal with it?

Regards.

[admin]

Yes, I am just working on this now. 

I will be doing the following:

1) Using a frame page to display the preview.
2) Inserting the "<base href...." tag INSIDE your html code, immediately after the opening "<head" tag.

The frameset page will create two frames.  One for the "click here to close" button, and the other for the preview page contents.

I think that should do the trick.

It's very complicated to create, but I should get this done for today... hopefully.   

Thoughts?

[admin]

Ok, this is done now. 

Be sure to test it out and let me know if it's working properly for you. 

(It will be included in the new release later today or (more likely) tomorrow afternoon.)

[cromagnon]

Sorry, this isn't working for me in the new version. The base href tag isn't being inserted into the HTML at all in the lower frame for my two sites, so now I have completely unstyled previews.

Here is the HTML from the start of one of the pages, so that you may be able to spot while your code isn't managing to insert the base tags:

------------------------------------------------------------------------------

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<!-- InstanceBegin template="Templates/template.dwt.php" codeOutsideHTMLIsLocked="false" -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="keywords" content="bushbury hill, bushbury, primary school, wolverhampton, education, school, primary" />
<meta name="description" content="Bushbury Hill Primary School, Wolverhampton." />

--------------------

P.S. Huge congratulations on the upgrade procedure - incredibly simple and effective.

[Jenkinhill]

Yes, I can confirm that preview now does not pick up the style sheet in FireFox and IE7. There is a workaround, though. Instead of using a relative href for the css file use a full url, like <link rel="stylesheet" href="http://www.domain.co.uk/stylesheet.css" type="text/css" />

I believe the preview is not correct because the base href is inserted after the lnk to the style sheet. I am testing this at the moment.

Test results:: Moving the base href inserted by the editor preview script to a position immediately below the <head> tag  instead of immediately above the </head> tag (as at present) fixes the problem.

Henri, is this easily fixable in Snippetmaster? In the meantime I'm happy to use full urls for css on those pages that may need editing.

[cromagnon]

Well spotted! I didn't even look down the document to find the base tag.

Your work-around will work fine, I'm sure. The issue with it is that when we're developing the pages and previewing them locally (e.g. from Dreamweaver) the stylesheet being used would be the remote copy not the local copy. This makes developing and modifying sites for the designer more awkward.

Henri, can you change the code so that the base href tag goes just after the open <head> tag, not just before the </head> close tag?

[cromagnon]

This is working great in 2.2.1. Thanks, Henri for resolving this issue.

[admin]

Henri, can you change the code so that the base href tag goes just after the open <head> tag, not just before the </head> close tag?

Done.  Included in version 2.2.1.  The preview page now has the base href tag inserted immediately after and before the <head> tag in the HTML.

Let me know if you run into any more issues with the preview system.