Problems validating page: xhtml, asp and css combi

[Mark]

Hi there

On this page i get some errors when validating:

http://www.keyone.nl/lab/beeldlijn/nl/collection.asp

The problem is caused by the use of ASP in my pages. This is the code:

<a
href="winkelwagen.asp?artikelId=<%=artikelId%>&tit el=titel%>&prijs=<%=prijs%>"
title="bestel deze DVD">bestel deze DVD</a>

everything from the & is seen as wrong (cannot generate system
identifier for general entity "titel" etc).

So i do not know what to do now. Somebody seen this before?

Mark

[Danny]

"Mark" <sc*****@xs4all.nl> wrote in message
news:43**************@xs4all.nl...

Hi there

On this page i get some errors when validating:

http://www.keyone.nl/lab/beeldlijn/nl/collection.asp

The problem is caused by the use of ASP in my pages. This is the code:
You mean, the code generated by ASP. If the validator can see the ASP source
code then something is very wrong.
<a
href="winkelwagen.asp?artikelId=<%=artikelId%>&tit el=titel%>&prijs=<%=prijs%>"
title="bestel deze DVD">bestel deze DVD</a>

everything from the & is seen as wrong (cannot generate system identifier
for general entity "titel" etc).

So i do not know what to do now. Somebody seen this before?

Try changing all & to &amp;

Did that work?

[Arne]

Once upon a time *Mark* wrote:

Hi there

On this page i get some errors when validating:

http://www.keyone.nl/lab/beeldlijn/nl/collection.asp

The problem is caused by the use of ASP in my pages. This is the code:

<a
href="winkelwagen.asp?artikelId=<%=artikelId%>&tit el=titel%>&prijs=<%=prijs%>"
title="bestel deze DVD">bestel deze DVD</a>

everything from the & is seen as wrong (cannot generate system
identifier for general entity "titel" etc).

So i do not know what to do now. Somebody seen this before?

Don't you read what the validator tells you about that error, just
below the error lines? Maybe you read it here then :)

<quote from W3C output>
An entity reference was found in the document, but there is no
reference by that name defined. Often this is caused by misspelling
the reference name, *unencoded ampersands*, or by leaving off the
trailing semicolon (;). The *most common* cause of this error is
unencoded ampersands in URLs as described by the WDG in "Ampersands in
URLs".

Entity references start with an ampersand (&) and end with a semicolon
(;). If you want to use a literal ampersand in your document you must
*encode it as "&amp;"* (even inside URLs!). Be careful to end entity
references with a semicolon or your entity reference may get
interpreted in connection with the following text. Also keep in mind
that named entity references are case-sensitive; &Aelig; and &aelig;
are different characters.

If this error appears in some markup generated by PHP's session
handling code, this article* has explanations and solutions to your
problem.

Note that in most documents, errors related to entity references will
trigger up to 5 separate messages from the Validator. Usually these
will all disappear when the original problem is fixed.
</quote>

* See the link on the W3C output page.

So, the conclusion is to replace "&" with "&amp;" and the error is gone!

--
/Arne
My "widget" site: http://hem.bredband.net/arnel/
Top posters will be ignored. Quote the part you
are replying to, and don't quote signatures!

[David Dorward]

Mark wrote:

everything from the & is seen as wrong (cannot generate system
identifier for general entity "titel" etc).

So i do not know what to do now.

To quote the error message from the validator: "If you want to use a literal
ampersand in your document you must encode it as "&amp;" (even inside
URLs!)."
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Mark]

David Dorward wrote:

Mark wrote:

everything from the & is seen as wrong (cannot generate system
identifier for general entity "titel" etc).

So i do not know what to do now.

To quote the error message from the validator: "If you want to use a literal
ampersand in your document you must encode it as "&amp;" (even inside
URLs!)."

Shame on me...

Thanks all :0)

[Martin Geisler]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDDvmF6nfwy35F3TgRAqtMAJ4/RYjrbJ4qHj51PBgso38fu1AYMQCbBr5s
QtQ0CmtU0spUUpHQSDP+e/Y=
=dZ2r
-----END PGP SIGNATURE-----

[Alan J. Flavell]

On Fri, 26 Aug 2005, Arne wrote:

So, the conclusion is to replace "&" with "&amp;" and the error is gone!

*If* the server-side process follows the recommendation that has been
in all versions of HTML from RFC1866/HTML2.0 onwards - see e.g
http://www.w3.org/TR/html401/appendi...s.html#h-B.2.2 - then the
ampersand in pre-composed query URLs can be replaced with a semi-colon
for a more compact solution of the problem. (Of course, /real/ form
submissions will continue to use ampersand as their separator - the
use of semicolon is specifically intended for precomposed URLs, in
order to avoid this problem).

(Unfortunately, there's far too many homespun form decoders around
which disregard the recommendation, so if the server-side process
isn't under your control, you'd have to try it first, it might or
might not be supported; but anyone who has the sense to use a
respectable well-supported library or module, such as CGI.pm in Perl,
should be OK with this.)

I've discussed this in more detail at
http://ppewww.ph.gla.ac.uk/~flavell/...mgetbyurl.html

The amusing thing is that the use of naked ampersands usually gives an
impression of working *when* the validator says there's an error. The
only cases where I've seen it go wrong is where the validator says
there *isn't* an error. In HTML (as opposed to XHTML) consider, for
example, a URL which contains ?request=print&copy=2 (more details at
the cited page).

good luck

[Tim]

On Fri, 26 Aug 2005 12:42:49 +0100, Alan J. Flavell sent:

(Of course, /real/ form submissions will continue to use ampersand as
their separator - the use of semicolon is specifically intended for
precomposed URLs, in order to avoid this problem).

Which shouldn't be a problem, shouldn't it? The submitted data isn't
HTML, but character data, so the HTML ampersand composition issues
wouldn't apply. If I've worked that out correctly.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

[Alan J. Flavell]

On Sat, 27 Aug 2005, Tim wrote:

On Fri, 26 Aug 2005 12:42:49 +0100, Alan J. Flavell sent:

(Of course, /real/ form submissions will continue to use ampersand as
their separator - the use of semicolon is specifically intended for
precomposed URLs, in order to avoid this problem).
Which shouldn't be a problem, shouldn't it?

I'm not sure what potential problem you're meaning to rule out here,
but no, technically there isn't a problem at all - the only problem is
incomprehension by some HTML authors. :-}
The submitted data isn't HTML,

The submitted data isn't HTML at all, right; but if a *precomposed*
URL is used, then the way to use it in the source HTML is as the value
of an attribute (href="..." for a link, src="..." for an image, etc.).

And in forming the value of that attribute, if there's a "&" in the
URL, then it has to be expressed in &-notation (&amp; or & - or
&#x26; if you feel you must) in the HTML attribute value.

When HTML parses that &amp; in the attribute value in the HTML source,
it'll leave just the "&" character itself to be used in the target
URL. But you'd understood that already, right?

Nothing special, in other words - the same rule that applies to /all/
HTML attribute values which happen to have an ampersand in them (an
image whose alt text was coded as alt="Mom&Pop" would trigger just
such a validation error, too, and would need to be corrected to
alt="Mom&amp;Pop" or equivalent).

Whereas, if the alternative semicolon is used for precomposed URLs, as
recommended in the HTML specifications, no such fiddling and bloat is
necessary.

It's perfectly OK to implement the server-side process to treat both
the "&" and the ";" as delimiters, since, if either or both of these
characters are meant to be interpreted as data rather than as
delimiters, the rules call for them to be sent in %xx-encoded format,
not as bare characters. So the same server-side parser can be used,
regardless of which kind of submission is being sent.

As I said, the respected Perl module CGI.pm parses both variants:
there's a switch to determine whether its *generated HTML* will use
semicolon (the default) or ampersand (on request), but that switch
changes only its generated HTML: it doesn't change CGI.pm's parsing of
submitted forms data at all - that code respects both of them as
delimiters, all the time.

h t h

[Tim]

Alan J. Flavell sent:

(Of course, /real/ form submissions will continue to use ampersand as
their separator - the use of semicolon is specifically intended for
precomposed URLs, in order to avoid this problem).

Tim:
Which shouldn't be a problem, shouldn't it?

Alan J. Flavell:

I'm not sure what potential problem you're meaning to rule out here,
but no, technically there isn't a problem at all - the only problem is
incomprehension by some HTML authors. :-}
Basically, URIs can have ampersands, for their proper purpose. It's just
a problem when you write URIs somewhere *in* your HTML.
The submitted data isn't HTML,

The submitted data isn't HTML at all, right; but if a *precomposed*
URL is used, then the way to use it in the source HTML is as the value
of an attribute (href="..." for a link, src="..." for an image, etc.).

And in forming the value of that attribute, if there's a "&" in the
URL, then it has to be expressed in &-notation (&amp; or & - or
&#x26; if you feel you must) in the HTML attribute value.

When HTML parses that &amp; in the attribute value in the HTML source,
it'll leave just the "&" character itself to be used in the target
URL. But you'd understood that already, right?
Yes, I did.
Nothing special, in other words - the same rule that applies to /all/
HTML attribute values which happen to have an ampersand in them (an
image whose alt text was coded as alt="Mom&Pop" would trigger just
such a validation error, too, and would need to be corrected to
alt="Mom&amp;Pop" or equivalent).

I'd say that still has a typing error. ;-) "Mom & Pop" would be how you
ought to type it, and that ought to be okay for HTML, too. ;-)

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.