FrontPage doesn't work with G0ogle?

C

CJSnet

Hi, I've posted this before here in a different thread ('FrontPage keeps
eating & changing my code') before I realised what was happening. Now it's
time to try and pass the details to MS, who I hope are listening.

Basically, the Google Map JavaScript must not be enclosed in a Table. It
needs to sit ideally just before the /body.

But when using Shared Borders in FP 2003, FP wraps the *whole* page in a
Table. Oh dear.

Worse still, when this is in a DWT Template and you manually move the
/table in the DWT from below the Google JS to above the Google JS, next
time you open one of the DWT child pages, FP gets stuck in a loop with a
window popping up 100s of times saying 'your change [i.e. FP's auto-change]
cannot be made because it is in a non-editable region of the Template' (or
similar message). This effectively locks you out of your files.

Here is the page in question, but any similar one will do the same:
www.superhighstreet.com/streets/George-Street-Richmond

Here are the workarounds I have tried, and why they failed:

1) Manually move the /table in the DWT child pages:
FP puts them back at the end again next time you open them (works temp)

2) Move /table in the DWT itself:
FP gets stuck in a loop when it tries to 'correct' this in the DWT child
pages

3) Put the top .htm file in an iframe in the DWT child page:
Google AdSense cannot use an iframe, so my ads don't see the main body of
the page

4) Make the shared borders into DWT and try to include them in the main
page's DWT:
You can't wrap one Template inside another DWT file

Eventually I used SSI to fetch the top and bottom borders, but the point is
I really shouldn't have had to. Are MS aware of this?
 
T

Thomas A. Rowe

Based on what you wrote, Shared Borders is working the same it has worked since FP98, so the real
issue is how Google wrote their JavaScript code, not how FP handles it.

In general, any code that FP write, if you change it outside of FP, etc. FP will correct it.

--
==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
==============================================
If you feel your current issue is a results of installing
a Service Pack or security update, please contact
Microsoft Product Support Services:
http://support.microsoft.com
If the problem can be shown to have been caused by a
security update, then there is usually no charge for the call.
==============================================
 
C

CJSnet

Fair point Thomas, but I think the FP team perhaps might want to consider
moving with the times, i.e. it's not 1998 any more and Google has taken over
the web to a great extent. Any web page editor software needs to keep that
in mind. Obviously asking Google to change their code for MS is not likely
to be fruitful, however I am not convinced it is a Google issue, and I think
their argument was that it is a JavaScript issue, in that it must not be
wrapped in a Table.

Seems fair, and seems reasonable for FP to end tables before any final JS if
the JS is the last bit of code on the page, no? Not asking the (Google)
Earth exactly ;)
--
Thanks,
CJSnet

I recommend www.Superhighstreet.com/home Finds anything or they pay for it!

[remove 'teeth' to e-mail me]


Thomas A. Rowe said:
Based on what you wrote, Shared Borders is working the same it has worked
since FP98, so the real issue is how Google wrote their JavaScript code,
not how FP handles it.

In general, any code that FP write, if you change it outside of FP, etc.
FP will correct it.

--
==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
==============================================
If you feel your current issue is a results of installing
a Service Pack or security update, please contact
Microsoft Product Support Services:
http://support.microsoft.com
If the problem can be shown to have been caused by a
security update, then there is usually no charge for the call.
==============================================

CJSnet said:
Hi, I've posted this before here in a different thread ('FrontPage keeps
eating & changing my code') before I realised what was happening. Now
it's
time to try and pass the details to MS, who I hope are listening.

Basically, the Google Map JavaScript must not be enclosed in a Table. It
needs to sit ideally just before the /body.

But when using Shared Borders in FP 2003, FP wraps the *whole* page in a
Table. Oh dear.

Worse still, when this is in a DWT Template and you manually move the
/table in the DWT from below the Google JS to above the Google JS, next
time you open one of the DWT child pages, FP gets stuck in a loop with a
window popping up 100s of times saying 'your change [i.e. FP's
auto-change]
cannot be made because it is in a non-editable region of the Template'
(or
similar message). This effectively locks you out of your files.

Here is the page in question, but any similar one will do the same:
www.superhighstreet.com/streets/George-Street-Richmond

Here are the workarounds I have tried, and why they failed:

1) Manually move the /table in the DWT child pages:
FP puts them back at the end again next time you open them (works temp)

2) Move /table in the DWT itself:
FP gets stuck in a loop when it tries to 'correct' this in the DWT child
pages

3) Put the top .htm file in an iframe in the DWT child page:
Google AdSense cannot use an iframe, so my ads don't see the main body of
the page

4) Make the shared borders into DWT and try to include them in the main
page's DWT:
You can't wrap one Template inside another DWT file

Eventually I used SSI to fetch the top and bottom borders, but the point
is
I really shouldn't have had to. Are MS aware of this?
 
T

Thomas A. Rowe

1. Shared Border have been depreciated by the introduction of Dynamic Web Templates in FP2003.

2. The point is that Google wrote the code, they should have check their code with the varies HTML
editors current available. Microsoft, Adobe, etc. should not have to change their application based
on how some company chose to write their JavaScript code.

3. I have worked with JavaScript code that works just fine within a table/cell, so I really see not
reason why a Google can not make their code work from within a table/cell.

Disclaimer: I have not looked at the Google code in question.
--
==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
==============================================
If you feel your current issue is a results of installing
a Service Pack or security update, please contact
Microsoft Product Support Services:
http://support.microsoft.com
If the problem can be shown to have been caused by a
security update, then there is usually no charge for the call.
==============================================

CJSnet said:
Fair point Thomas, but I think the FP team perhaps might want to consider moving with the times,
i.e. it's not 1998 any more and Google has taken over the web to a great extent. Any web page
editor software needs to keep that in mind. Obviously asking Google to change their code for MS
is not likely to be fruitful, however I am not convinced it is a Google issue, and I think their
argument was that it is a JavaScript issue, in that it must not be wrapped in a Table.

Seems fair, and seems reasonable for FP to end tables before any final JS if the JS is the last
bit of code on the page, no? Not asking the (Google) Earth exactly ;)
--
Thanks,
CJSnet

I recommend www.Superhighstreet.com/home Finds anything or they pay for it!

[remove 'teeth' to e-mail me]


Thomas A. Rowe said:
Based on what you wrote, Shared Borders is working the same it has worked since FP98, so the real
issue is how Google wrote their JavaScript code, not how FP handles it.

In general, any code that FP write, if you change it outside of FP, etc. FP will correct it.

--
==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
==============================================
If you feel your current issue is a results of installing
a Service Pack or security update, please contact
Microsoft Product Support Services:
http://support.microsoft.com
If the problem can be shown to have been caused by a
security update, then there is usually no charge for the call.
==============================================

CJSnet said:
Hi, I've posted this before here in a different thread ('FrontPage keeps
eating & changing my code') before I realised what was happening. Now it's
time to try and pass the details to MS, who I hope are listening.

Basically, the Google Map JavaScript must not be enclosed in a Table. It
needs to sit ideally just before the /body.

But when using Shared Borders in FP 2003, FP wraps the *whole* page in a
Table. Oh dear.

Worse still, when this is in a DWT Template and you manually move the
/table in the DWT from below the Google JS to above the Google JS, next
time you open one of the DWT child pages, FP gets stuck in a loop with a
window popping up 100s of times saying 'your change [i.e. FP's auto-change]
cannot be made because it is in a non-editable region of the Template' (or
similar message). This effectively locks you out of your files.

Here is the page in question, but any similar one will do the same:
www.superhighstreet.com/streets/George-Street-Richmond

Here are the workarounds I have tried, and why they failed:

1) Manually move the /table in the DWT child pages:
FP puts them back at the end again next time you open them (works temp)

2) Move /table in the DWT itself:
FP gets stuck in a loop when it tries to 'correct' this in the DWT child
pages

3) Put the top .htm file in an iframe in the DWT child page:
Google AdSense cannot use an iframe, so my ads don't see the main body of
the page

4) Make the shared borders into DWT and try to include them in the main
page's DWT:
You can't wrap one Template inside another DWT file

Eventually I used SSI to fetch the top and bottom borders, but the point is
I really shouldn't have had to. Are MS aware of this?
 
C

CJSnet

Thanks Thomas.

Can you elaborate on how I would/should use a DWT to replace a SB?

For example:
I have a site with 100 pages.
I want 15 of the pages to share a top/bottom border.
1 of those 15 pages is itself a DWT, with 2 child DWT pages.
I want those 2 DWT child-pages to also include the DWT borders.

This, if I understand right, means those 2 pages would be linked to *3*
DWTs:
2 x Border DWT parents
1 x Body DWT parent

Is this possible? I had tried it and the page did not display correct, plus
the template tags got themselves confused.

--
Thanks,
CJSnet

I recommend www.Superhighstreet.com/home Finds anything or they pay for it!

[remove 'teeth' to e-mail me]


Thomas A. Rowe said:
1. Shared Border have been depreciated by the introduction of Dynamic Web
Templates in FP2003.

2. The point is that Google wrote the code, they should have check their
code with the varies HTML editors current available. Microsoft, Adobe,
etc. should not have to change their application based on how some company
chose to write their JavaScript code.

3. I have worked with JavaScript code that works just fine within a
table/cell, so I really see not reason why a Google can not make their
code work from within a table/cell.

Disclaimer: I have not looked at the Google code in question.
--
==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
==============================================
If you feel your current issue is a results of installing
a Service Pack or security update, please contact
Microsoft Product Support Services:
http://support.microsoft.com
If the problem can be shown to have been caused by a
security update, then there is usually no charge for the call.
==============================================

CJSnet said:
Fair point Thomas, but I think the FP team perhaps might want to consider
moving with the times, i.e. it's not 1998 any more and Google has taken
over the web to a great extent. Any web page editor software needs to
keep that in mind. Obviously asking Google to change their code for MS
is not likely to be fruitful, however I am not convinced it is a Google
issue, and I think their argument was that it is a JavaScript issue, in
that it must not be wrapped in a Table.

Seems fair, and seems reasonable for FP to end tables before any final JS
if the JS is the last bit of code on the page, no? Not asking the
(Google) Earth exactly ;)
--
Thanks,
CJSnet

I recommend www.Superhighstreet.com/home Finds anything or they pay for
it!

[remove 'teeth' to e-mail me]


Thomas A. Rowe said:
Based on what you wrote, Shared Borders is working the same it has
worked since FP98, so the real issue is how Google wrote their
JavaScript code, not how FP handles it.

In general, any code that FP write, if you change it outside of FP, etc.
FP will correct it.

--
==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
==============================================
If you feel your current issue is a results of installing
a Service Pack or security update, please contact
Microsoft Product Support Services:
http://support.microsoft.com
If the problem can be shown to have been caused by a
security update, then there is usually no charge for the call.
==============================================

Hi, I've posted this before here in a different thread ('FrontPage
keeps
eating & changing my code') before I realised what was happening. Now
it's
time to try and pass the details to MS, who I hope are listening.

Basically, the Google Map JavaScript must not be enclosed in a Table.
It
needs to sit ideally just before the /body.

But when using Shared Borders in FP 2003, FP wraps the *whole* page in
a
Table. Oh dear.

Worse still, when this is in a DWT Template and you manually move the
/table in the DWT from below the Google JS to above the Google JS, next
time you open one of the DWT child pages, FP gets stuck in a loop with
a
window popping up 100s of times saying 'your change [i.e. FP's
auto-change]
cannot be made because it is in a non-editable region of the Template'
(or
similar message). This effectively locks you out of your files.

Here is the page in question, but any similar one will do the same:
www.superhighstreet.com/streets/George-Street-Richmond

Here are the workarounds I have tried, and why they failed:

1) Manually move the /table in the DWT child pages:
FP puts them back at the end again next time you open them (works temp)

2) Move /table in the DWT itself:
FP gets stuck in a loop when it tries to 'correct' this in the DWT
child
pages

3) Put the top .htm file in an iframe in the DWT child page:
Google AdSense cannot use an iframe, so my ads don't see the main body
of
the page

4) Make the shared borders into DWT and try to include them in the
main
page's DWT:
You can't wrap one Template inside another DWT file

Eventually I used SSI to fetch the top and bottom borders, but the
point is
I really shouldn't have had to. Are MS aware of this?
 
N

Nicholas Savalas - http://savalas.tv

Dear CJSnet,

I take the time to write this because I really like your web concept.
Bravo. I mean it. That is a very unique and ingenious business model. I
wish you much luck with it - the point of writing difficult code IS TO
MAKE THE VISITOR'S EXPERIENCE EASY AND INTERESTING, and you are well on
your way there. Other self-appointed expert coders in this forum could
learn much from you.

Before reading my comments, please first take a look at the HTML
validation check for your page. It will give you an idea of what is to
follow. Validation check is at:

http://validator.w3.org/check?uri=http://www.superhighstreet.com/George-Street-Richmond/index.shtml

OK. I get "Failed validation, 111 errors". The first 4 are important;
they prove my first statement:

1) DO NOT USE DYNAMIC WEB TEMPLATES...

....unless you understand that they are for coders who don't care about
good work, or don't know any better. The Microsoft FrontPage DWT
concept foists illegal HTML attributes on DWT users. I couldn't care
less how helpful the FP-MVP's say DWT's are. They are the evil spawn of
helpful, well-meaning developers at MS. These developers have helped
you into a nightmare. Save your page content, and then destroy all of
your DWT's before they learn how to reproduce.

2) DO NOT USE SHARED BORDERS...

....they are more MS good intentions gone bad. Look at error 27:

Line 19 column 212: value of attribute "NAME" must be a single token.
<meta name="Microsoft Border" content="blablabla">
This attribute can not take a space-separated list of words as a value,
but only one word ("token"). This may also be caused by the use of a
space for the value of an attribute which does not permit it.

But, wait... The Microsoft Border attribute can only work with a space
in the name. Proprietary evil. Destroy it.

3) DO NOT USE FP TABLE LAYOUTS...

....without being pre-warned that they use code that is totally illegal
- which means that other browsers will not display the page the way
Internet Explorer will. Go download Opera and FireFox and see what I
mean. As an example, there is no such thing as <table width="931"
height="137"> - if you want to declare those things, do it in CSS -
make a page (e.g. style.css) that includes, say:

..table_top
{
font-family: Arial, Helvetica, sans-serif;
color: #00000;
font-size: 9pt;
vertical-align: top;
width: 931px;
height: 137 px;
text-align: left;
padding-right: 2px;
border: 0px solid #000000;
background-color: #ffffff;
}

and, after calling the style.css file in your <head> section (<link
rel="stylesheet" href="http://www.superhighstreet.com/style.css"
type="text/css" media="screen" title="Super High Street stylesheet"
/>), you can just write:

<table class="table_top">

and it will do the same thing. Much less work for you. Looks the same
to all visitors.

4) IF YOU USE FRONTPAGE, LEARN TO CHECK WITH NOTEPAD.

I hate writing out code over and over, so I wrote and include page
'inc_head.asp' which carried all of my meta tags, CSS references, Java
links, etc. etc, in one page, and then just use like:

<!--#include virtual="blablabla/inc_head.asp" -->

to call it. FP threw a hissy-fit when I wanted to save just the tags,
and insisted on adding <head> & </head> tags, which I did not want. God
bless notepad.

As another example, FP writes for its' rollover buttons:
<script language="JavaScript">
when the proper code is:
<script type="text/javascript">

In folder view at left, right-click a page and 'Open With...' notepad,
examine, and save before publishing. FP can sometimes be too helpful.

After you purge the disease from your website, and your site validates
at http://validator.w3.org/check?uri=http://www.superhighstreet.com/ -
with whatever DOCTYPE you decide to use (presently, none: avoid HTML
4.01 and its' subsets, and try to move toward XHTML 1.0 Strict or even
XHTML 1.1 Strict - the future is coming very fast, my friend), you can
attack your original problems: Google content.

Google AdSense DOES work in I-Frames, but according to it's own rules.
It parses the content of the page it is on, and puts ads up there
corresponding to the content it reads. Want it to work in an I-Frame?
Add the content to the framed page of the ad you'd like to see. Google
could care less. They just want exposure for their advertisers and
clicks and sales. Google AdSense IS ITSELF an I-Frame. Don't believe
me? Open up this in notepad:

http://pagead2.googlesyndication.com/pagead/show_ads.js

Surprise! I-Frames. Don't hate the player; hate the game.

Next, stick the Google Java baloney in the <head> section, where it
belongs:

<head>
................blablabla.....................
<script
src="http://maps.google.com/maps?file=api&amp;v=2&amp;key=blablabla"
type="text/javascript"></script>
<script type="text/javascript">
//<![CDATA[
function load() {
if (GBrowserIsCompatible()) {
var icon = new GIcon();
icon.image = "http://labs.google.com/ridefinder/images/mm_20_red.png";
icon.shadow =
"http://labs.google.com/ridefinder/images/mm_20_shadow.png";
icon.iconSize = new GSize(12, 20);
icon.shadowSize = new GSize(22, 20);
icon.iconAnchor = new GPoint(6, 20);
icon.infoWindowAnchor = new GPoint(5, 1);
var map = new GMap2(document.getElementById("map"));
map.setCenter(new GLatLng(blablabla, blablabla), 7);
map.addControl(new GSmallMapControl());
map.addControl(new GMapTypeControl());
map.setMapType(G_HYBRID_TYPE);

// Our info window content
var infoTabs = [
new GInfoWindowTab("blablabla", "blablabla"),
new GInfoWindowTab("blablabla", "blablabla"),
new GInfoWindowTab("blablabla", "blablabla")
];

// Place a marker in the center of the map and open the info window
// automatically
var marker = new GMarker(map.getCenter());
GEvent.addListener(marker, "click", function() {
marker.openInfoWindowTabsHtml(infoTabs);
});
map.addOverlay(marker);
marker.openInfoWindowTabsHtml(infoTabs);
}
}
//]]>
</script>
</head>

as I did at http://savalas.tv/about/ieraxmap.asp - go check it out.
Then, all the Google Map stuff happens inside the <body> and <div>
tags:

<body onload="load()" onunload="GUnload()">
<div id="map" style="width: 468px; height: 360px"></div>

(I used style="width: blablabla..." because I was too lazy to add to my
CSS file for that one lonely line.)

You get your fundamentals worked out, CJSnet, and you could be one of
the scariest webmasters on the planet - one with that extremely rare
quality: originality. I wish you the very best of luck.

Nicholas Savalas - http://savalas.tv

-----------------------------------------------------------------
Hi, I've posted this before here in a different thread ('FrontPage keeps
eating & changing my code') before I realised what was happening. Now it's
time to try and pass the details to MS, who I hope are listening.

Basically, the Google Map JavaScript must not be enclosed in a Table. It
needs to sit ideally just before the /body.

But when using Shared Borders in FP 2003, FP wraps the *whole* page in a
Table. Oh dear.

Worse still, when this is in a DWT Template and you manually move the
/table in the DWT from below the Google JS to above the Google JS, next
time you open one of the DWT child pages, FP gets stuck in a loop with a
window popping up 100s of times saying 'your change [i.e. FP's auto-change]
cannot be made because it is in a non-editable region of the Template' (or
similar message). This effectively locks you out of your files.

Here is the page in question, but any similar one will do the same:
www.superhighstreet.com/streets/George-Street-Richmond

Here are the workarounds I have tried, and why they failed:

1) Manually move the /table in the DWT child pages:
FP puts them back at the end again next time you open them (works temp)

2) Move /table in the DWT itself:
FP gets stuck in a loop when it tries to 'correct' this in the DWT child
pages

3) Put the top .htm file in an iframe in the DWT child page:
Google AdSense cannot use an iframe, so my ads don't see the main body of
the page

4) Make the shared borders into DWT and try to include them in the main
page's DWT:
You can't wrap one Template inside another DWT file

Eventually I used SSI to fetch the top and bottom borders, but the point is
I really shouldn't have had to. Are MS aware of this?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top