Problem with XHTML parsers with embedded HTML (e.g. firefox et-al)

[Rick]

Hi.. I've got some code I wrote in PHP that will generate a new argument
string for the browser, but the xhtml parser in Firefox and Opera both
complain about my use of &var=value pairs.

Below is my code that generates the string :

function InvokeURL(url_to_forward_to)
{
try
{
var xfamElem = document.getElementById('xFamily');
var mainform = document.getElementById('mainform');
var new_url = url_to_forward_to + "&variable=" + xfamElem.value;

mainform.action = new_url;
mainform.submit();
}
catch(error)
{
alert("InvokeURL encountered an error :" + error.description);
}
}

This works fine with *many* browsers except the new ones.. With IE on
windows (IE6) and Opera, Firefox all complain, Safari and some older
browsers seem to work OK..

If I change the line with the new_url variable setting on it to use a
& instead, it passes the XHTML tests but no longer works at all.. When
using the & it still has that in the URL that shows in the address
bar and hence it seems to cause the script on the other end a lot of
problems as it is unable to properly parse the URL string.

Any ideas on how to portably get around this problem with embedded &
created URL's?

Many thanks in advance!

-- Rick

[2metre]

Rick wrote:

Hi.. I've got some code I wrote in PHP that will generate a new argument
string for the browser, but the xhtml parser in Firefox and Opera both
complain about my use of &var=value pairs.

Below is my code that generates the string :

function InvokeURL(url_to_forward_to)
{
try
{
var xfamElem = document.getElementById('xFamily');
var mainform = document.getElementById('mainform');
var new_url = url_to_forward_to + "&variable=" + xfamElem.value;

mainform.action = new_url;
mainform.submit();
}
catch(error)
{
alert("InvokeURL encountered an error :" + error.description);
}
}

That's javascript. I'd ask in a javascript newsgroup.

[John Dunlop]

It would be more appropriate to consult an (X)HTML group.
These issues have been discussed at length in the past, so
the clues are in the archive. I don't see how any of what
follows relates to PHP though.

Rick wrote:

the xhtml parser in Firefox and Opera both complain about my
use of &var=value pairs.
Rightly so. The content of SCRIPT in HTML is CDATA; in
XHTML, #PCDATA. So in XHTML script elements, entity
references are recognised. Ampersands that should be
treated literally must be escaped. XHTML1.0 sec. 4.8 says:

| In XHTML, the script and style elements are declared as
| having #PCDATA content. As a result, < and & will be
| treated as the start of markup, and entities such as &lt;
| and &amp; will be recognized as entity references by the
| XML processor to < and & respectively. Wrapping the
| content of the script or style element within a CDATA
| marked section avoids the expansion of these entities.

http://www.w3.org/TR/xhtml1/#h-4.8

But in HTML, even though SCRIPTs have CDATA content, entity
references are not recognised; '&' is never the start of an
entity reference. HTML4.01 sec. 6.2 says:

| Although the STYLE and SCRIPT elements use CDATA for their
| data model, for these elements, CDATA must be handled
| differently by user agents. Markup and entities must be
| treated as raw text and passed to the application as is.

http://www.w3.org/TR/html4/types.html#h-6.2
&variable
In XHTML the ampersand must be escaped.
This works fine with *many* browsers except the new ones.
Tag soup slurpers might give it the impression of working,
but it's wrong.
If I change the line with the new_url variable setting on it to use a
&amp; instead,
Then it becomes valid XHTML.
it passes the XHTML tests but no longer works at all.
Because most browsers don't grok XHTML.
Any ideas on how to portably get around this problem with embedded &
created URL's?

In increasing order of preference:

1. Wrap the script's content in a CDATA section (XML1.0
sec. 2.7) and don't encode the ampersands.

2. Stop using inline scripts; move them to a separate
file.

3. Stop sending XHTML to browsers which don't support it.
You might choose to use content negotiation to send XHTML
to browsers which do support it and HTML to ones which
don't. Why bother?

--
Jock