Computing desk
< June 16	<< May \| June \| Jul >>	June 18 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

June 17

♪ versus 🎵 in Unicode

Why was the emoji 🎵 assigned a separate Unicode point, rather than being simply considered an emoji presentation of ♪ (and thus represented as ♪ followed by Variant Selector 16)? Neon Merlin 01:53, 17 June 2017 (UTC)[reply]

Assuming this is the emoji 266A ♪ eighth note meaning two eighth note symbols connected together by a beam (it does not display in my browser), its history is that it was part of the proprietary / non-standardized emoji set first introduced by Japanese carriers like Softbank. These emojis became part of the Apple iPhone starting in iOS 2.2 as an unlockable feature on handsets sold in English speaking countries. In iOS 5 / OSX 10.7, the underlying code that the Apple OS generates for this emoji was changed. The artwork varies. Blooteuth (talk) 13:36, 17 June 2017 (UTC)[reply]

For me, 266A ♪ appears as a single eighth note. —Tamfang (talk) 19:28, 17 June 2017 (UTC)[reply]

In my opinion the unicode consortium should have done what you say, use the existing symbol with the emoji variant selector. I guess they just didn't think of it at the time. -- Q Chris (talk) 14:18, 20 June 2017 (UTC)[reply]

Help me, Obi-Wan Kenobi! You're my only hope!! (Referrer policy)

At Wikipedia:Village pump (policy)#A solution that satisfies privacy and GLAM requirements? (which is a section of Wikipedia:Village pump (policy)#RfC: Wikimedia referrer policy), I have an editor who claimed without evidence that a particular feature is supported only by the chrome browser. my research suggests that it is supported by all major browsers, but the ref I am basing that on is is to searchengineland, and I really am hoping to find a better source. I could really use some technical help here.

In particular, if Wikipedia puts the following in the head of the HTML...

<meta name="referrer" content="same-origin">

...thus sending no referrer information when a user clicks on a link to a non-Wikipedia page, and then Wikipedia adds the following to selected links...

<a href="http://example.com" referrerpolicy="always">

..to override the meta tag in the head, what browsers support this?

According to [ https://caniuse.com/#feat=referrer-policy ] Referrer Policy is supported by Firefox, Chrome, Safari, Opera, iOS Safari, Android Browser, and Chrome for Android and (maybe) Microsoft Edge. (It is not supported by Internet Explorer, but because Internet Explorer doesn't support the referrer meta tag or referrerpolicy on the link, IE will always have the default HTTP/HTTPS behavior no matter what we do with our meta tags and links.)

According to [ http://searchengineland.com/need-know-referrer-policy-276185 ], There are many ways you can deliver the referrer policy:

Via the Referrer-Policy HTTP header
Via a meta element with a name of referrer
Via a referrerpolicy content attribute on an a, area, img, iframe, or link element (emphasis added)
Via the noreferrer link relation (rel=) on an a, area, or link element
Implicitly, via inheritance

I have searched and searched and cannot find a shred of evidence that this is only supported by chrome, but I am also lacking good, strong evidence that it is supported by other browsers.

Help me, Obi-Wan Kenobi! You're my only hope!! :) --Guy Macon (talk) 13:45, 17 June 2017 (UTC) [reply]

[1] claims it's supported by Firefox since version 36.0 or 39 depending on the situation and Chrome since 17 but not supported by Microsoft Edge. IE, Safari and Opera are unknown. Nil Einne (talk) 11:13, 18 June 2017 (UTC)[reply]

[2] seems to be the Mozilla Bugzilla entry for implementation. There is someone there from Facebook implying it was supported in Safari since version 6 onwards. Nil Einne (talk) 11:18, 18 June 2017 (UTC)[reply]

Reading more carefully, I think Firefox possibly only supports no-referrer, origin, no-referrer-when-downgrade, origin-when-crossorigin and unsafe-URL. Nil Einne (talk) 11:31, 18 June 2017 (UTC)[reply]

[3] from Microsoft seems to suggest it's supported in Edge although no idea what version. Nil Einne (talk) 11:19, 18 June 2017 (UTC)[reply]

[4] suggests Edge may possibly still only support "default, never, origin, always". [5] is example code test for Edge. Nil Einne (talk) 11:25, 18 June 2017 (UTC)[reply]

[6] on the webkit bug tracker and [7] on the Wikimedia bugtracker suggests Safari possibly still only supports 'no-referrer', 'origin', 'no-referrer-when-downgrade', or 'unsafe-url'. Nil Einne (talk) 11:34, 18 June 2017 (UTC)[reply]

[8] on the wikimedia bug tracker suggests some older browsers still use origin-when-crossorigin and newer ones use origin-when-cross-origin. OT but [9] goes into detail on various things Facebook does to try and handle various issues. Nil Einne (talk) 11:39, 18 June 2017 (UTC)[reply]

Whops I just noticed you were asking about referrer-policy not meta "referrer". The earlier link [10] suggests it's probably not supported on Edge at least circa January of this year. Nil Einne (talk) 11:42, 18 June 2017 (UTC)[reply]

BTW, link that's part of the comment implies it's referring to the a attribute. Nil Einne (talk) 11:57, 18 June 2017 (UTC)[reply]

[11] from Mozilla claims the a element referrerpolicy is supported by Firefox since version 50 (and Chrome since version 46.0 implemented behind a flag) probably with the attributes 'no-referrer', 'no-referrer-when-downgrade', 'origin', 'origin-when-cross-origin' and 'unsafe-url'; but not IE, Edge, Safari or Opera. Note that [12] and I think some of the earlier links suggest that 'always' is deprecated and instead 'unsafe-url' should be used. BTW if you're interested in the referrer-policy HTTP header, [[13] from Mozilla claims it's supported in Firefox with various attributes since 52.0 but Chrome only has basic support as of 56.0 and Safari, Opera, Edge and IE don't support it. Nil Einne (talk) 11:57, 18 June 2017 (UTC)[reply]

[14] has more info on implementation of the HTTP header on Chrome if you're interested. It also suggests there is no signals from Safari or Edge that they will support it. It also links to the Mozilla bugzilla [15] for it. Incidentally, the lack of support for meta referrer 'origin-when-cross-origin' on Safari seems to be a common issue handled either via custom per browser policies or via choosing some other option [16] [17] Nil Einne (talk) 12:02, 18 June 2017 (UTC)[reply]

P.S. Is there a good reason the HTTP header is referrer-policy but the A/content attribute is referrerpolicy? I can understand abandoning the misspelling of referrer, but having one being referrer-policy and one being referrerpolicy just seems a recipe for disaster. Nil Einne (talk) 12:09, 18 June 2017 (UTC)[reply]

Oh [18] seems to be the Mozilla Bugzilla for the element referrerpolicy attribute. It seems it was initially implemented but not enabled by default if I'm understanding correctly. Nil Einne (talk) 12:12, 18 June 2017 (UTC)[reply]

[19] claims support for referrerpolicy on a and other attributes on Chrome Desktop, Chrome Android, Android Webview since 51, Opera 38 and Opera for Android 38. Interesting it suggests no public signals from either Edge, Safari, Firefox and also no signals from web developers. Nil Einne (talk) 12:09, 18 June 2017 (UTC)[reply]

Sorry I can't find further info (like from Safari or Apple) about support for referrerpolicy attribute on a elements such as a bug/feature request (e.g. on webkit.org not helped by the fact that referrerpolicy seems to refer to several things including I think webkit's own internal referrer policy. Maybe Nimur can help. I get the feeling though that it isn't supported yet. [20] is a feature request for Edge. I'm lazy to investigate much for Opera especially since I get the feeling this is a feature of Blink (web engine) where they just went with the flow. Getting fairly OT here but it seems Opera, Chrome and I think Safari [21] [22] support referrerpolicy in some fashion as part of the Fetch API. Nil Einne (talk) 12:37, 18 June 2017 (UTC)[reply]

Thanks! That was a huge help. I may have more questions after I carefully study all of the linked material.

I do have a question about the comment "I think some of the earlier links suggest that 'always' is deprecated and instead 'unsafe-url' should be used."

Given that some sources[23] say things like "Supports an older draft of the specification with never, always, origin & default values", would "unsafe-url" or "always" on the a link be the best choice for achieving the the desired effect (overriding the "same-origin" in the head and sending full referrer information for that link) on as many browsers as possible? Or would something like <a href="http://example.com" referrerpolicy="always, unsafe-url"> work? --Guy Macon (talk) 14:22, 18 June 2017 (UTC)[reply]