Doctype use kills some javascripts

[rfr]

When I add a transitional doctype to the weather page on my community
website, I loose certain Js scripts, but not all of them.

This puzzles me.

The main menu is powered by a js script and seems to function even with eh
doctype.

But, the floating menu doesn't function once I put a transitional doctype of
the page. The js script that handles the floating top of page icon on the
right side is problematic.

I have created version of the weather page with new names so that you can
access them w/o interfering with my visitor counts.

The funtioning page without doctype and INTERNAL JS is here and it works:
http://www.wgtn.net/weather/weather_without_doctype.htm

The non-funtioning page with doctype and INTERNAL JS is here:
http://www.wgtn.net/weather/weather_with_doctype.htm

I thought, perhaps that making the js script EXTERNAL would solve the
problem.

But this does not work either. Oh, dang.

The funtioning page without doctype and EXTERNAL JS is here:
http://www.wgtn.net/weather/weather_...externaljs.htm

The non-funtioning page with doctype and EXTERNAL JS is here:
http://www.wgtn.net/weather/weather_...externaljs.htm

I dont want to give up my floating menus.

I would like to be able to use a doctype so that my pages validate. This
helps me feel sure that they are cross-browser as much as I can do.

Has anyone else run up against this conflict with JS scripts and use of
doctype and have a solution or workaround?

[Janwillem Borleffs]

rfr schreef:

I would like to be able to use a doctype so that my pages validate. This
helps me feel sure that they are cross-browser as much as I can do.

Has anyone else run up against this conflict with JS scripts and use of
doctype and have a solution or workaround?

Simply enclose your inline scripts with the following:

// <![CDATA[
... your script ...
// ]]>
JW

[Henry]

On May 27, 11:10 am, Janwillem Borleffs wrote:

rfr schreef:

>I would like to be able to use a doctype so that my pages
validate. This helps me feel sure that they are cross-browser
as much as I can do.

Has anyone else run up against this conflict with JS scripts
and use of doctype and have a solution or workaround?

Simply enclose your inline scripts with the following:

// <![CDATA[
... your script ...
// ]]>

Isn't that particular incantation only relevant for HTML pages that
wish to fool a mark-up validator into thinking that they are XHTML, or
for Appendix C XHTML pages that are served as both HTML and XHTML
following content negotiation (something that almost never happens in
reality and complicates scripting to such a degree that even the W3C
abandon content negotiation and serve pages only as HTML when they
script those pages)?

There is no evidence in the OP that the DOCTYPE being inserted is
anything but an HTML DOCTYPE, and as the browser most likely to suffer
from a change in the CSS compatibility mode is IE, and IE will never
interpret any document it directly renders XHTML the odds are very low
that contents of SCRIPT elements not being interpreted as CDATA is an
issue here at all.

The most likely issues related to the addition of a DOCTYPE is need to
provide CSS unit values when assigning to - style - properties, and
IE's switching of 'root' node from - document.body - without a DOCTYPE
to - document.documentElement - with one.

[Thomas 'PointedEars' Lahn]

Henry wrote:

On May 27, 11:10 am, Janwillem Borleffs wrote:

>rfr schreef:

>>I would like to be able to use a doctype so that my pages
validate. This helps me feel sure that they are cross-browser
as much as I can do.

Has anyone else run up against this conflict with JS scripts
and use of doctype and have a solution or workaround?

Simply enclose your inline scripts with the following:

// <![CDATA[
... your script ...
// ]]>

Isn't that particular incantation only relevant for HTML pages that
wish to fool a mark-up validator into thinking that they are XHTML,

Not at all. It is relevant for all HTML 4.01 documents that don't follow
the recommendation in the HTML 4.01 Specification, Appendix B, section 3.5
and following:

http://www.w3.org/TR/REC-html40/appe...s.html#h-B.3.3

or for Appendix C XHTML pages that are served as both HTML and XHTML

It is relevant for all XHTML documents that follow the recommendations in
the XHTML 1.0 Specification, section 4.8, but don't follow the last
mentioned alternative there:

http://www.w3.org/TR/2000/REC-xhtml1-20000126/#diffs

following content negotiation

Content negotiation is not necessarily involved here.

(something that almost never happens in reality

Yet it does happen.

and complicates scripting to such a degree that even the W3C
abandon content negotiation and serve pages only as HTML when they
script those pages)?

Could you please provide some proof to back up these statements?

(Full ACK to the rest.)
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[VK]

On May 27, 8:15 am, "rfr" <[e-mail]:

When I add a transitional doctype to the weather page on my community
website, I loose certain Js scripts, but not all of them.

The exact type of DOCTYPE is irrelevant because browsers are not
validating agents. For instance WHATWG HTML 5 doctype is simply
<!DOCTYPE html>. What _is_ crusial is the current compatMode:
BackCompat (a.k.a. "Quirk") or CSS1Compat (a.k.a. intentionally
standard-compliant). A lot of important changes are happening with
switching from one mode to another. The current industry standard
including document.compatMode mode names themselves is based on the
original "CSS Enhancements in Internet Explorer 6"
http://msdn.microsoft.com/en-us/libr...95(VS.85).aspx
This is the document any serious developer has to know by heard and be
ready to quote any part of it on request even at the middle of the
night. ;-) :-|

Now back to your problem. A document without any DOCTYPE or with
DOCTYPE
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
(thus HTML Transitional without DTD URL)
leaves browser in BackCompat ("Quirk") mode
but
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
(thus HTML Transitional with DTD URL)
switches browser into CSS1Compat ("Standard") mode.

In your document you are using HTML Transitional with DTD URL so
switching the browser into CSS1Compat mode. One of changes as spelled
in the linked specs is more strict CSS rules parsing. If in BackCompat
mode missing unit name is automatically assumed to be "px", in
CSS1Compat mode there isn't default unit name so such rule will be
disregarded as invalid.

Respectively:

function wRefresh() {
wMark.left = posX + (navDOM?pageXOffset:document.body.scrollLeft);
wMark.top = posY + (navDOM?pageYOffset:document.body.scrollTop);
}

will work in BackCompat but it will error out in CSS1Compat. To make
it universally usable you have to explicitly indicate the unit:

function wRefresh() {
wMark.left = posX +
(navDOM?pageXOffset:document.body.scrollLeft) + 'px';
wMark.top = posY +
(navDOM?pageYOffset:document.body.scrollTop) + 'px';
}

It is up to you to check if the same error is not presented in another
function(s) beside wRefresh.

[Henry]

On May 27, 12:29 pm, Thomas 'PointedEars' Lahn wrote:

Henry wrote:

>On May 27, 11:10 am, Janwillem Borleffs wrote:

>>rfr schreef:
I would like to be able to use a doctype so that my pages
validate. This helps me feel sure that they are cross-browser
as much as I can do.

>>>Has anyone else run up against this conflict with JS scripts
and use of doctype and have a solution or workaround?
Simply enclose your inline scripts with the following:

>>// <![CDATA[
... your script ...
// ]]>

>Isn't that particular incantation only relevant for HTML pages that
wish to fool a mark-up validator into thinking that they are XHTML,

Not at all. It is relevant for all HTML 4.01 documents that don't
follow the recommendation in the HTML 4.01 Specification,
Appendix B, section 3.5 and following:

http://www.w3.org/TR/REC-html40/appe...s.html#h-B.3.3

What specific point are you trying to make here?

>or for Appendix C XHTML pages that are served as both HTML
and XHTML

It is relevant for all XHTML documents that follow the
recommendations in the XHTML 1.0 Specification, section 4.8, but
don't follow the last mentioned alternative there:

http://www.w3.org/TR/2000/REC-xhtml1-20000126/#diffs

No, that is the CDATA section mark-up without the javascript end-of-
line comments. It is the end of line comments that make it clear that
this 'mark-up' is intended for use with HTML, where the CDATA section
mark-up would otherwise be interpreted as javascript syntax errors.

>following content negotiation

Content negotiation is not necessarily involved here.

What is the alternative? Randomly serving pages as HTML sometimes, and
as XHTML at other times?

>(something that almost never happens in reality

Yet it does happen.

It does happen, but not that often, and vary rarely when the pages are
scripted (which is quite an important detail where this group is
concerned).

>and complicates scripting to such a degree that even the
W3C abandon content negotiation and serve pages only as
HTML when they script those pages)?

Could you please provide some proof to back up these statements?

<snip>

When IE (which does not understand XHTML at all) requests <URL:
http://www.w3.org/ the content type of the response is:-

Content-Type: text/html; charset=utf-8

- so the page is served as HTML (and so will be interpreted by IE as
HTML)

When Firefox request the same page the content type of the response
is:-

Content-Type: application/xhtml+xml; charset=utf-8
- the page is served as XHTML. The mark-up received is identical
(approximately Appendix C XHTML). This is the case for the vast
majority of W3C pages.

Yet when it comes to <URL: http://validator.w3.org/ the mark-up is
still Appendix C XHTML but both IE and Firefox receive the content
type:-

Content-Type: text/html; charset=utf-8

- in the response, and so they both interpret that page as error
filled tag soup HTML. The only reasonable justification for that
difference is that the validator page is scripted in a way that will
break in the event that the mark-up ever be interpreted as XHTML by a
browser (because the script cannot cope with the differences between
an HTML DOM and an XHTML DOM).

In the end it seems that the effort necessary to write cross-DOM
scripts exceeds the value of the principle that XHTML should be served
to user agents that recognise it even for the organisation best
motivated to promote the use of XHTML.

[rf]

"rfr" <rf******@iw.netwrote in
news:td******************************@prairiewave. com:

The main menu is powered by a js script and seems to function even
with eh doctype.

You are relying on javasript for something so mission critical as you main
menu?

[rfr]

Yes, the main menu is an XFX DHTML Menu Builder created menu system.

It works well.
"rf" <[e-mail] in message
news:TG*****************@news-server.bigpond.net.au...

"rfr" <rf******@iw.netwrote in
news:td******************************@prairiewave. com:

>The main menu is powered by a js script and seems to function even
with eh doctype.

You are relying on javasript for something so mission critical as you main
menu?

[rfr]

Thanks!

It is good to know that it is likely the absence of the units designation
that is interfering with the browser handling of this when the doctype is
changed. That makes sense.

However, I am a cut-n-paste guy, not a Javascripter. I don't understand
them. I just use them. Thus, I have no idea on how the change the JS
scripts I have, and if I do attempt to make changes, have no way to
troubleshoot the script when it does not function because of some syntax
error, or simple omission I made.

Who might I enlist to update the scripts I use to make them functional with
the Transitional Doctype?

"VK" <sc**********@yahoo.comwrote in message
news:fd**********************************@s50g2000 hsb.googlegroups.com...

On May 27, 8:15 am, "rfr" <[e-mail]:

>When I add a transitional doctype to the weather page on my community
website, I loose certain Js scripts, but not all of them.

The exact type of DOCTYPE is irrelevant because browsers are not
validating agents. For instance WHATWG HTML 5 doctype is simply
<!DOCTYPE html>. What _is_ crusial is the current compatMode:
BackCompat (a.k.a. "Quirk") or CSS1Compat (a.k.a. intentionally
standard-compliant). A lot of important changes are happening with
switching from one mode to another. The current industry standard
including document.compatMode mode names themselves is based on the
original "CSS Enhancements in Internet Explorer 6"
http://msdn.microsoft.com/en-us/libr...95(VS.85).aspx
This is the document any serious developer has to know by heard and be
ready to quote any part of it on request even at the middle of the
night. ;-) :-|

Now back to your problem. A document without any DOCTYPE or with
DOCTYPE
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
(thus HTML Transitional without DTD URL)
leaves browser in BackCompat ("Quirk") mode
but
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
(thus HTML Transitional with DTD URL)
switches browser into CSS1Compat ("Standard") mode.

In your document you are using HTML Transitional with DTD URL so
switching the browser into CSS1Compat mode. One of changes as spelled
in the linked specs is more strict CSS rules parsing. If in BackCompat
mode missing unit name is automatically assumed to be "px", in
CSS1Compat mode there isn't default unit name so such rule will be
disregarded as invalid.

Respectively:

function wRefresh() {
wMark.left = posX + (navDOM?pageXOffset:document.body.scrollLeft);
wMark.top = posY + (navDOM?pageYOffset:document.body.scrollTop);
}

will work in BackCompat but it will error out in CSS1Compat. To make
it universally usable you have to explicitly indicate the unit:

function wRefresh() {
wMark.left = posX +
(navDOM?pageXOffset:document.body.scrollLeft) + 'px';
wMark.top = posY +
(navDOM?pageYOffset:document.body.scrollTop) + 'px';
}

It is up to you to check if the same error is not presented in another
function(s) beside wRefresh.

[rf]

"rfr" <rf******@iw.netwrote in
news:e5******************************@prairiewave. com:

[top posting fixed]

"rf" <[e-mail] in message
news:TG*****************@news-server.bigpond.net.au...

>"rfr" <rf******@iw.netwrote in
news:td******************************@prairiewave .com:

>>The main menu is powered by a js script and seems to function even
with eh doctype.

You are relying on javasript for something so mission critical as you
main menu?

Yes, the main menu is an XFX DHTML Menu Builder created menu system.

You miss the point.

It works well.

No it does not.

Anybody with javascript disabled/unavailable will not be able to use the
site.

Most importantly the search engine bots don't do javascript so will not
index any of your pages because they simply cannot find them.

--
Richard
Killing all google groups posts
The Usenet Improvement Project: http://improve-usenet.org

[rfr]

I know the standard PC correctness line is that JS menus will hurt the
search engine status.

That is not the experience I have had with this. Quite the opposite has been
true for me using XFX DHTML Menu Builder.

My pages rank at, or near the top, on nearly all the search words I have
used that have to do with apsects of Worthington MN.

Therefore, I am not concerned about that potential aspect of JS menus.

The concern of JS being shut off is left to be dealt with. I choose to let
the menuing decay to minial use for those people. I tend to see those people
in the same way that I look at people who drive vehicles without lights:
they don't belong on the road. If they choose to drive, they need to accept
their limitations.

"rf" <[e-mail] in message
news:JD*****************@news-server.bigpond.net.au...

"rfr" <rf******@iw.netwrote in
news:e5******************************@prairiewave. com:

[top posting fixed]

>"rf" <[e-mail] in message
news:TG*****************@news-server.bigpond.net.au...

>>"rfr" <rf******@iw.netwrote in
news:td******************************@prairiewav e.com:

The main menu is powered by a js script and seems to function even
with eh doctype.

You are relying on javasript for something so mission critical as you
main menu?

>Yes, the main menu is an XFX DHTML Menu Builder created menu system.

You miss the point.

>It works well.

No it does not.

Anybody with javascript disabled/unavailable will not be able to use the
site.

Most importantly the search engine bots don't do javascript so will not
index any of your pages because they simply cannot find them.

--
Richard
Killing all google groups posts
The Usenet Improvement Project: http://improve-usenet.org

[Gregor Kofler]

rfr meinte:

The concern of JS being shut off is left to be dealt with. I choose to let
the menuing decay to minial use for those people. I tend to see those people
in the same way that I look at people who drive vehicles without lights:
they don't belong on the road. If they choose to drive, they need to accept
their limitations.

A very professional attitude. Well... perhaps you should recommend
enabling Java*Script*, not Java, on your webpage.

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum