Skip to content
This repository has been archived by the owner. It is now read-only.

Embed-code contains wrong letters #5075

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 6 comments
Closed

Embed-code contains wrong letters #5075

openstreetmap-trac opened this issue Jul 23, 2021 · 6 comments

Comments

@openstreetmap-trac
Copy link

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Reporter: db[at]davidb.at
[Submitted to the original trac issue database at 8.18pm, Monday, 16th December 2013]

Hi!

I want to embed a map with OpenStreetMap on my website. On building with the embed-function, the map is totally zoomed out. With the forum I found out, that there is a & instead of the "&" in the code.

You see it best here: http://www.davidb.at/karte.png

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: pnorman
[Added to the original trac issue at 7.40am, Tuesday, 17th December 2013]

It is correct to encode the & in URLs as &

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: colin.smale[at]xs4all.nl
[Added to the original trac issue at 9.28am, Tuesday, 17th December 2013]

Replying to [comment:1 pnorman]:

It is correct to encode the & in URLs as &

I am not so sure that that is always true ...

It will depend on whether XHTML or legacy HTML is being used, and apparently sometimes on the browser as well according to this article from 2008:
http://stackoverflow.com/questions/275150/xhtml-and-ampersand-encoding

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: Jonathan Bennett
[Added to the original trac issue at 10.32am, Tuesday, 17th December 2013]

Replying to [comment:2 colin.smale@]:

I am not so sure that that is always true ...

Yes, it is, and the very article you reference points this out and explains the most common mistake of pasting an HTML encoded link directly into a browser's address bar:

"The encoding of & as & is required in HTML, not in the link. When the browser sees the & in the HTML source for a link it will interpret it as an ampersand and the link target will be as intended. If you paste a URL into your browser address bar it does not expect it to be HTML and does not try to interpret any HTML encoding that it may contain. This is why your example links that you suggest we should copy/paste into a browser don't work and why we wouldn't expect them to work."

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: TomH
[Added to the original trac issue at 10.39am, Tuesday, 17th December 2013]

Just to add to which, when you select "Link" in the share tab we do not encode the ampersand, but when you select "HTML" to get an HTML fragment we do encode it. All of which sounds correct to me.

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: aseerel4c26
[Added to the original trac issue at 11.03am, Tuesday, 17th December 2013]

this is a duplicate of ticket #4949

@openstreetmap-trac
Copy link
Author

@openstreetmap-trac openstreetmap-trac commented Jul 23, 2021

Author: colin.smale[at]xs4all.nl
[Added to the original trac issue at 11.06am, Tuesday, 17th December 2013]

Replying to [comment:3 Jonathan Bennett]:

Replying to [comment:2 colin.smale@]:

I am not so sure that that is always true ...

Yes, it is, and the very article you reference points this out and explains the most common mistake of pasting an HTML encoded link directly into a browser's address bar:

"The encoding of & as & is required in HTML, not in the link. When the browser sees the & in the HTML source for a link it will interpret it as an ampersand and the link target will be as intended. If you paste a URL into your browser address bar it does not expect it to be HTML and does not try to interpret any HTML encoding that it may contain. This is why your example links that you suggest we should copy/paste into a browser don't work and why we wouldn't expect them to work."

I stand entirely corrected. Having read the standards again it seems that accepting a bare "&" was strictly a non-compliance and everybody should have been using "&" in the first place.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant