On Mar 5, 12:39 pm, Fairy <[email protected]> wrote:
> The API is like a "black box" for me, so I cannot judge who is
> "more" responsible. I just tested my script on Opera 11.01 build
> 1190, Safari 5.0.3 (7533.19.14), Firefox 3.6.13 and all three of
> them replaced '&lt=' to '&<' in the info window. So I blamed this
> on the only common denominator I know of: the API.

Which doesn't mean it is true.

>
> Lesson learnt: I will keep on properly escaping my ampersands. But
> still: it would not hurt to have a standards compliant parser in
> the API. :-)

The API isn't parsing that the browsers are.  Nice that they all
behave the same... (I notice you didn't test IE, as that usually
behaves differently from any other browser, you should include it in
your sample)

-- Larry


>
> On márc. 5, 09:44, Andrew Leach <[email protected]> wrote:
>
>
>
>
>
>
>
> > On Mar 5, 3:32 am, Fairy <[email protected]> wrote about browsers
> > replacing &lt with <:
>
> > While you are right about the standard (a semi-colon is necessary),
> > you can't assume that browsers will always follow the HTML standard
> > within urls. This isn't an API thing, it's a browser thing.
>
> > However, while one could argue that the browser is at fault, you're
> > not helping. When including an ampersand in a url, you should encode
> > that. Urls should never have an unencoded ampersand in them, because
> > an ampersand should always be treated as starting an entity. Using
> > &amp;lt is *not* a workaround: it's what you should use.
>
> > The workaround would be to use a variable name which is not an entity.
> > &lat= would be interpreted in the way you want it to be.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Maps API V2" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-maps-api?hl=en.

Reply via email to